用户访问集群需要认证、授权、准入三个步骤。apiserver是整个集群访问控制的唯一入口。
认证
认证是对用户的身份认证,通常包括用户名密码认证,但是也包括对service account的认证。
限制不同用户访问集群
生成ssl密钥
在/etc/kubernetes/pki/ 目录中,生成用户访问的密钥,首先生成一个集群上的私钥,用以下命令:
(umask 077; openssl genrsa -out lucky.key 2048)
这是生成一个私钥,并保存到lucky.key中,但是相应的公钥也可以从私钥中获取
openssl rsa -in lucky.key -pubout -out lucky.pub
然后生成一个rsa请求,这个请求可以向ca机构请求一个ca证书,从而加密自己的私钥。用以下命令:这里是生成一个针对私钥lucky.key的ca证书的请求,然后把它保存为lucky.csr,并且指定csr的主题信息为通用名称(common name)=lucky
openssl req -new -key lucky.key -out lucky.csr -subj "/CN=lucky"
然后使用在集群中有的ca证书(ca.crt,ca.key)来生成ca签名过的包含公钥的文件。
openssl x509 -req -in lucky.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out lucky.crt -days 3650
[root@master pki]# ls
apiserver.crt apiserver-etcd-client.key apiserver-kubelet-client.crt ca.crt ca.srl front-proxy-ca.crt front-proxy-client.crt lucky.crt lucky.key sa.pub
apiserver-etcd-client.crt apiserver.key apiserver-kubelet-client.key ca.key etcd front-proxy-ca.key front-proxy-client.key lucky.csr sa.key
加入用户
将lucky用户加入集群用户里面,在此目录下运行:
kubectl config set-credentials lucky --client-certificate=./lucky.crt --client-key=./lucky.key --embed-certs=true
然后查看/etc/.kube/config文件,可以看到lucky的用户被添加到config文件中
[root@master .kube]# cat config
apiVersion: v1
clusters:
- cluster:...
- name: luckyuser:client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNvVENDQVlrQ0NRRFNTZ3Fyam51R1pqQU5CZ2txaGtpRzl3MEJBUXNGQURBVk1STXdFUVlEVlFRREV3cHIKZFdKbGNtNWxkR1Z6TUI0WERUSTBNRGN3TWpBME16STBPVm9YRFRNME1EWXpNREEwTXpJME9Wb3dFREVPTUF3RwpBMVVFQXd3RmJIVmphM2t3Z2dFaU1BMEdDU3FHU0liM0RRRUJBUVVBQTRJQkR3QXdnZ0VLQW9JQkFRQzZ6cVVqCnZSaG1vZFJjUnNHZnVCeENvNS9nTnVOLzdLUkdjcVhSWGZKU01GaUQ1TmU1WUNzeW03TlAzKzRMMmg5OGFvRm4KNk9sNTM4NGFISlpXVlhEdTFMSmFIR0ZmdXNSMk13aGlYR0VyNnN5Z2UyRlFLT2FIM2tEbForbEpjQkNtWS9LRgpmZHI0eHpYMGExU3ZDMEovSkZlNWk0UCswd2IwdEY5U0lLeE5aaUJCbDNiQ1VWeTVsR24waXB0WUlpclRkRFlMCjIvd0tIcFZadHRZMjdCVGhwNE1NU1hkTC9qK1dhRGFnVHVKbWdyZGhwK3pHMlJoenFSTGp3bTBsUWRsY0tVTjAKZFNLWERnWU9UOHpEN3dtS0lYYmFid0FLSWtpVFNaeEFKN1UwRXRNV29ieEp6eURybHRKSUdBYkF5UjNBOGJZOApKaWdscmxiODhhMFVQQXVSQWdNQkFBRXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBRXhwV1ZITXB6TlBtZEhqClhBNFQ3UDl0dkxmNWZwUzQyWFZyUHZjRmt0WnUzeno1KzhxZ1UvYnhuVWppRDhnUjFhVHMwQllGT3BGeitqYXYKTzBybzU4R3k0OGFmb1U5MENEL2dGL21JalBjYmtnb01VeUR6alUzdkUrMUxZc3VRWUlGTkV0VnBibTJ4VjVYaAp4cUtiUG5oN3JjVG9nb2hwYVhOT0Q0RTErYU1RUm85VWtndFludVZiOHlacFlvTktJekRNWDhiYTE1RWoxbUFkCmVLUFJPSEw0Z0pvaGVkSW1PcGJyWlN1byt4SWhRUmpCSXBuZ1hCcjl5bkpUUmdKRzlPOTlobG1IMEVqd1VzMHkKQVZLbXVsMnRHNFRlYktGWmRXNFdRRHhMVmRaTlFNRGRjRzMyQnFBeW9rWHl2R2oxNWxyb3d2c3pwNy83dW5DRwpPbDhiRnVvPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==client-key-data: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFcEFJQkFBS0NBUUVBdXM2bEk3MFlacUhVWEViQm43Z2NRcU9mNERiamYreWtSbktsMFYzeVVqQllnK1RYCnVXQXJNcHV6VDkvdUM5b2ZmR3FCWitqcGVkL09HaHlXVmxWdzd0U3lXaHhoWDdyRWRqTUlZbHhoSytyTW9IdGgKVUNqbWg5NUE1V2ZwU1hBUXBtUHloWDNhK01jMTlHdFVyd3RDZnlSWHVZdUQvdE1HOUxSZlVpQ3NUV1lnUVpkMgp3bEZjdVpScDlJcWJXQ0lxMDNRMkM5djhDaDZWV2JiV051d1U0YWVEREVsM1MvNC9sbWcyb0U3aVpvSzNZYWZzCnh0a1ljNmtTNDhKdEpVSFpYQ2xEZEhVaWx3NEdEay9Ndys4SmlpRjIybThBQ2lKSWswbWNRQ2UxTkJMVEZxRzgKU2M4ZzY1YlNTQmdHd01rZHdQRzJQQ1lvSmE1Vy9QR3RGRHdMa1FJREFRQUJBb0lCQVFDb0d3M0ErNG5aMGdlbwpnb1A3bDFMWEpTZmFQWXE4czllaERjcnFmZ0J5dGM3eDRoMi9WQ3VMZjFIOXJ5WW94RUZSVlFiZTIxby9zb2RtCk9CT1IzWkdqV3dTazBxVk40R1NyZVlFeUFxL3ZOWHl2YmxoRUtvcEorbGVzR2JaMXY4TTcrUFZsNjd3QjVFTkoKa016RU9QMitMSlpGQXFmbHlVR1pORGdUVUJPK0VYeHhqZERlRyswUE1TL0NzSmYvaGZQTlB6NEhuVmEydWhyZwppNEczcVE3NDNwL1ExZGwzU0ppTEFTSkh6eHd0OG1BRWJQWDZxcHJHVGQyQzlvT0J3MW8ra085dDc4RFB1eDU3CkZhcFVtMk9yb1MweCt3Nng3WnhqQmpLSUp1Y3hKNHZ4QkVjbTBoRlJtMnBiaVRNZERGN1ZBOVBhZ2RCdkQ4TzMKKzVVQzg4QUJBb0dCQVBoS3dtNnErSTRmNjlZaEpjeU5nNTlBRmJlNng3bTJuenVaY1Q1UUM0eXlNWUZNVllRLwoyeW55R1NsMXhaN3BDbTA2ZWpTNmVEWDNHeUZPVlc1TW5WYjE4dUo5aklUYTlmcG1Kazg5TTlVNFQ5OWVDWjBXCnBHa2lkaEpTV01QVlFDaitaa3g0eDZzeTdjc1pqTVl3d0JubTlScnBqMExNVVlodnIzRENTWWxoQW9HQkFNQ2IKUC9vbUozS1krTHJGZ0hrRWpSa3NvdXlUb2wxMjJFL0Y4Rzkza1hlQ01FOE5YZ2IrR1VybFYrSTB2VlhXbFVLTgpvaVVPQ3ZMeFZjOVhIQ0FUN01HN0xGRWlZNTc4czdIM3FxWERpOThrR1NpT3NnNy9MUGYwVzI2a043K3RZT29wCllzZlZYVllzbHZ6eE05RnBqNkdBWWRSSHpMNCthZzlpNVdReElNQXhBb0dBUjliSm50K1Uvdm81Y0VFekFKWkoKYVFCUHlGTWdpcGxPUlI1R1o3TWRSRjRpZUxpdlhZNWtTU1NsSnh2T1RBWTlZQkUxWHFBOU84LzlaNHVVcUU4KwpqdlNtaStXcmpKMFY0cGMvcWxtWTc2NVZYZG1GaXBBTWplYk1wc3h3cG1qRElabEozQUp1TXhpUE9ONXhucjVvCk5wWmVnS1RuTUhxUmRKcHI5b0lnYU1FQ2dZQU11blhJNXpxV0pTdlMwL2lBaHQ5NE9XM3U2bmJCYkhneEZXaWwKUlNhVTJrS3RCcm9mQmkzUHVFWk5pYVMxaG4vSXJTbDQvMnVUMElVV05iQ0RJaTMwUTVWVEswMmdGUjBlOXJvTgpTRlgzQWlDemdIS2Q4UmtjcmNaWkVuc29yS0dKK0FBeUtwU0hmRnppREdLYlJUbWJ0NnMvWnh0TnV6d3hGaDBJCnVRSnNFUUtCZ1FEUk92WlFkaDhxcUJrZ0VrSzhXcEs5Skg4L29abGhhUzBseE9IcUptN1M4TkRCbU1hQWNxdUQKK2RxRGxnQmdUNHVNM3dmMmsrRU55azR1bktVbWV2czBHbEZ4dmJzTTlBdHJLQ3hLTG1KQ25RS2tFNXNnRStKZQpRZXZ0REFoRVFJYWttRmNuUFlnZ2Zzd2toYmRycU00OTZjam5uV2FEK2MxTzJNbmJEQXdFVHc9PQotLS0tLUVORCBSU0EgUFJJVkFURSBLRVktLS0tLQo=
切换上下文为用户lucky,然后执行kubectl get 命令,发现没有权限,这是因为用户创建以后还没有绑定任何rbac权限。
[root@master]# kubectl config set-context lucky@kubernetes --cluster=kubernetes --user=lucky
[root@master]# kubectl config use-context lucky@kubernetes
Switched to context "lucky@kubernetes".
[root@master]# kubectl get pods
Error from server (Forbidden): pods is forbidden: User "lucky" cannot list resource "pods" in API group "" in the namespace "default"
绑定授权
创建namespace,并且把它绑定到用户上,让该用户只能操作lucky 命名空间下的资源
kubectl create ns lucky
kubectl create rolebinding lucky -n lucky --clusterrole=cluster-admin --user=lucky
serviceAccount
service account是为了方便pod里面的进程调用kubernetes API或其他外部服务而设计的,是为pod设计的。每个pod在创建后,都会自动设置spec.serviceAccount为default,除非制定了service Account。
以12.持久化存储中的nfs provisioner为例,创建的pod就标明了 serviceAccount: nfs-provisioner
[root@master nfs]# cat nfs-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: nfs-provisioner
spec:replicas: 1selector:matchLabels:app: nfs-provisionerstrategy: type: Recreatetemplate:metadata:labels:app: nfs-provisionerspec:serviceAccount: nfs-provisionercontainers:- name: nfs-provisionerimage: registry.cn-beijing.aliyuncs.com/mydlq/nfs-subdir-external-provisioner:v4.0.0imagePullPolicy: IfNotPresentvolumeMounts:- name: nfs-client-rootmountPath: /persistentVolumesenv:- name: PROVISIONER_NAMEvalue: example.com/nfs- name: NFS_SERVERvalue: 100.64.252.90- name: NFS_PATHvalue: /data/nfs_provolumes:- name: nfs-client-rootnfs:path: /data/nfs_proserver: 100.64.252.90
同时这个serviceAccount也是提前定义好的
apiVersion: v1
kind: ServiceAccount
metadata: name: nfs-provisioner
创建sa的时候会自动的创建一个token,保存在secret里面。查看集群里面的sa,可以发现有一个刚才创建的,还有一个命名空间自己的default的service account,这是因为在 my-namespace
中创建一个 Pod,而没有指定 ServiceAccount 时,Pod 会自动使用 default
ServiceAccount,这个 Pod 会自动使用 my-namespace
中 default
ServiceAccount 的 Token,该 Token 存储在 default-token-abcde
Secret 中,并被自动挂载到 Pod 的文件系统中,从而让pod有一定的权限。
[root@master yam_files]# kubectl get sa
NAME SECRETS AGE
default 1 16d
nfs-provisioner 1 32h
[root@master yam_files]# kubectl get secret
NAME TYPE DATA AGE
default-token-sqbqc kubernetes.io/service-account-token 3 16d
nfs-provisioner-token-wgfv4 kubernetes.io/service-account-token 3 32h
[root@master yam_files]# kubectl get secret default-token-sqbqc -o yaml
apiVersion: v1
data:ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvakNDQWVhZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJME1EWXhOVEV5TXpRME9Gb1hEVE0wTURZeE16RXlNelEwT0Zvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTGF2Cm14R3VLeXFZTzhkVVdSVWEyNDR2TE1WM3hvcnpTa04xdGV0RHJtRXJpSkxKZmRVdWRVTDBPYVIzTzFIR1QrZG4KMTNQZStock85QzVuV1kyRWJpMU54bTFKSnVNclZlbThwcURpZnhpNTZ0QnhYRWJPNTQrL1lrSi80cG5MS1I2egpudTZTZElxQ1E4aFVNeFVnL2FIczNuMHE2cjFqWTNxZTArNDhza0hMVWpNbmxmdkp0UDhPaWNNa3ZEaHI4OEJxCjNQVXZGRGl6ZTdBVkVPbzZWOFVhdEp4MkFZOEsySE5rV0YyeWsvTC9MUHh2V3ZwTFRKcTdXcCtJZGdIQVFjUDgKRjVDNm1WQmpsQjZCejVjMnhSN2c5V0g4blJ3aExUMlhURDk5WGpkU0liOWlpblNDdGp5VnMwM0I1SVhWaCtjLwpROHpOa0Rrc2tYaXJOb0Q5anlVQ0F3RUFBYU5aTUZjd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZNbThFTFlSZnUzNmJ0b29CVGlGbk5MR0M5V25NQlVHQTFVZEVRUU8KTUF5Q0NtdDFZbVZ5Ym1WMFpYTXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBS2RncGRWeVJvYm5oeUlGZmE1aApUeW0rRk5RUW52WTVqYzZXWEc1RktVMkNCWGE3TGg2NEFnUHNxL2RHemFHL2pEMUNpM1liaU9KTHpFeGR0RFJCCk9ZemZIUjE0SUZGd3VuS1hiOVNHT09CL3gwWFpVSUtsQk5oWWdwSFdIUUtqZ2N1bzZFQWVxSEV0ekZBVStLdmsKcHhVS3o1V2JSNlovUitzVC92YUoyODRkWEpZcXV0NExORThWNi9VZ25lNUtjeHppQjFlTitmMytNVzh3djNINAp6cExsbVhER1htcThCTEgwaEhSeS92cGc2UUFwMDA4bXZwNWtlY2h3SHNlYjkxVTJSVFd6V0pVWCtobHY3bkFPCkc4QjZKRzRlU2Y4cXBLNEE5UDlGaTUvSzFtWXoyRzB6MFM3T2FNY1B6aVp4dm10KzhDR0NBMVphUjVUeldta3cKRDQwPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==namespace: ZGVmYXVsdA==token: ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNkltb3pSR1pVWTNaVWVIbDNMVzlTWTNjNFNVZE1Temx5Y1ZGeWJXRkxMVk15T0ZaUlJWYzJURU50V1hNaWZRLmV5SnBjM01pT2lKcmRXSmxjbTVsZEdWekwzTmxjblpwWTJWaFkyTnZkVzUwSWl3aWEzVmlaWEp1WlhSbGN5NXBieTl6WlhKMmFXTmxZV05qYjNWdWRDOXVZVzFsYzNCaFkyVWlPaUprWldaaGRXeDBJaXdpYTNWaVpYSnVaWFJsY3k1cGJ5OXpaWEoyYVdObFlXTmpiM1Z1ZEM5elpXTnlaWFF1Ym1GdFpTSTZJbVJsWm1GMWJIUXRkRzlyWlc0dGMzRmljV01pTENKcmRXSmxjbTVsZEdWekxtbHZMM05sY25acFkyVmhZMk52ZFc1MEwzTmxjblpwWTJVdFlXTmpiM1Z1ZEM1dVlXMWxJam9pWkdWbVlYVnNkQ0lzSW10MVltVnlibVYwWlhNdWFXOHZjMlZ5ZG1salpXRmpZMjkxYm5RdmMyVnlkbWxqWlMxaFkyTnZkVzUwTG5WcFpDSTZJbU0xTkRZelltUmlMVFl6TlRVdE5HSXhPUzA0Tm1WakxUY3haR0ZsT1RobU9HSTJNeUlzSW5OMVlpSTZJbk41YzNSbGJUcHpaWEoyYVdObFlXTmpiM1Z1ZERwa1pXWmhkV3gwT21SbFptRjFiSFFpZlEuS1BaM2poWkhwWjc1Uzg4U1pKZHk4RWJBZFlxZ2NXMFBfQnVBOVFIMTBhVGI0VjZDWHp5RWFNb0ZweDJPc3FZQ3dEWjh1UlpaZG5BeDB3emgwNkpHWUtOUGJiNGJDcVJDcVBWVVpuSTktNlRsNjlvT0xVOGJ3V1F3alM5Z2I5eE1aMlNpRGZPOXFtbDFzdDhxc2dXaTZYVmpfR24tNlRHd0NPeDVxT2ZYanB5a2NDTmdXWVlISmFZUEtYdkIzOWtlUklqMVlKNGVNUXNIRmlJVHhIR19zMVBHQTkyZHdsY3liZjlaTE1qMnFiTG5qZEQ4ZzNKeXB0eUJuVElGTUZDaHkxQlB4djVCLW1mOTRMYU5pRmJiU19TTEpKNGI1TFRQYUk2RlNyVjMzR1hsblRQbnM5R0NJZ1VrelRxc3d2ZXdhSk9WdWI5dDBVZ240SWk4bDFYWklR
kind: Secret
metadata:annotations:kubernetes.io/service-account.name: defaultkubernetes.io/service-account.uid: c5463bdb-6355-4b19-86ec-71dae98f8b63creationTimestamp: "2024-06-15T12:35:13Z"name: default-token-sqbqcnamespace: defaultresourceVersion: "425"uid: ee7d82cb-4af1-4949-8faa-367962bcea26
type: kubernetes.io/service-account-token
每一个用于aservice account的secret其实都有一个token和ca证书。
授权
对资源进行授权,授权检查机制回根据授权规则判定该资源是否是该用户可以访问的。k8s的授权是基于插件形成的,其常用的授权插件有以下几种:
1.node节点认证
2.ABAC基于属性的访问控制
3.RBAC基于角色的访问控制
4.webhook基于http回调机制的访问控制
其中RBAC是最常用的授权机制,把用户和角色绑定,从而赋予权限
以12中的nfs 供应商为例,在上面创建sa后,默认情况下,ServiceAccount 的权限非常有限。如果没有为 ServiceAccount 绑定任何 Role 或 ClusterRole,它将无法执行大多数操作,尤其是跨命名空间或集群范围的操作。例如:
- 它无法在其他命名空间中创建、修改或删除资源。
- 它无法获取集群范围的资源(如节点信息)。
- 它只能执行一些基本的读取操作。
所以创建了一个clusterrolebinding,是对整个集群有效,针对的是clusterrole。相对的还有rolebinding,只对rolebinding所在的命名空间有效。
以下命令将 cluster-admin
ClusterRole 绑定到 default
命名空间中的 nfs-provisioner
的ServiceAccount,从而赋予了这个sa权限。
kubectl create clusterrolebinding nfs-provisioner-clusterrolebinding --clusterrole=cluster-admin --serviceaccount=default:nfs-provisioner
RBAC
RBAC有四种资源,role,cluster role,rolebinding,clusterrolebinding
apiGroups
Kubernetes API 由不同的 API 组和版本组成,每个组包含一组相关的资源。比如:
核心api组:apiGroups: [""],
资源:Pod、Service、ConfigMap、Secret、Node、Namespace 等。 API 版本:v1
apiGroups: ["apps"],
资源:Deployment、DaemonSet、StatefulSet、ReplicaSet。API 版本:apps/v1
apiGroups: ["batch"],资源:Job、CronJob。 API 版本:batch/v
apiGroups: ["autoscaling"],资源:HorizontalPodAutoscaler。API 版本:autoscaling/v1
1.role
创建一个角色,针对核心api组进行pod的角色授权。
apiVersion:rbac.authorization.k8s.io/v1
kind: Role
metadata:name: rbacnamespace: pod-read
rules:- apiGroups: [""]resources: ["pods"]resourceNames: []verbs: ["get","watch","list"]
2.clusterRole
创建对整个secret的集群操作角色
如果是对某些资源的某些名称的资源进行操作,还可以在resource name里面进行标注
apiVersion: rbac.authorization.k8s.io/v1
kind: clusterRole
metadata:name: secret-clusterrolenamespace: rbac
rules:apiGroups: [""]resourceNames: []resources: ["secrets"]verbs: ["get","watch","list"]
3.rolebinding
以下是两种rolebinding,一种是绑定了上文中创建的pod-read的角色,另一种是绑定了集群中已经存在的cluster role,但是仅仅在规定的命名空间中使用。
[root@master role]# cat rolebinding1.yaml
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:name: rolebinding_1namespace: rbac
roleRef:apiGroup: rbac.authorization.k8s.iokind: Role name: read-pod
subjects:
- kind: Username: userapiGroup: rbac.authorization.k8s.io
[root@master role]# cat rolebinding_2.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:name: all-resourcenamespace: rbac
subjects:
- kind: Username: userapiGroup: rbac.authorization.k8s.io
roleRef:apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: cluster-admin
绑定成功
[root@master role]# kubectl get rolebinding -n rbac
NAME ROLE AGE
all-resource ClusterRole/cluster-admin 6s
rolebinding_1 Role/read-pod 5m1s
4.cluster rolebinding
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:name: cluster-binding1
roleRef:name: secret-clusterrolekind: ClusterRoleapiGroup: rbac.authorization.k8s.io
subjects:
- name: deploymentkind: GroupapiGroup: rbac.authorization.k8s.io
绑定成功。
[root@master role]# kubectl get clusterrolebinding
NAME ROLE AGE
calico-kube-controllers ClusterRole/calico-kube-controllers 16d
calico-node ClusterRole/calico-node 16d
cluster-admin ClusterRole/cluster-admin 16d
cluster-binding1 ClusterRole/secret-clusterrole 16s
...
特殊群组的授权
(1)qa 命名空间中的所有 Service Account:
subjects:
- kind: Groupname: system:serviceaccounts:qaapiGroup: rbac.authorization.k8s.io
(2)所有 Service Account
subjects:
- kind: Groupname: system:serviceaccountsapiGroup: rbac.authorization.k8s.io
(3)所有认证用户
subjects:
- kind: Groupname: system:authenticatedapiGroup: rbac.authorization.k8s.io
(4)所有未认证用户
subjects:
- kind: Groupname: system:unauthenticatedapiGroup: rbac.authorization.k8s.io
(5)全部用户
subjects:
- kind: Groupname: system:authenticatedapiGroup: rbac.authorization.k8s.io
- kind: Groupname: system:unauthenticatedapiGroup: rbac.authorization.k8s.io
就是说,如果要给所有serviceAccount一个权限角色,可以使用 system:serviceaccounts这个名称
kubectl create clusterrolebinding aa --clusterrole=view --group=system:serviceaccounts
如果给某一个命名空间下的所有serviceAccout都加一个权限角色,需要标明namespace
--clusterrole=view
:指定使用预定义的 ClusterRole
名为 view
,这个 ClusterRole
通常包含了查看大部分资源但不包括写权限的能力。
kubectl create rolebinding bb --clusterrole=view --group=system:serviceaccounts:my-namespace --namespace=my-namespace
为一个命名空间中名为 default 的 Service Account 授权,因为没有写明service Account的pod的默认service account都是default。
kubectl create rolebinding default-view --clusterrole=view --serviceaccount=my-namespace:default --namespace=my-namespace
与service Account绑定
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:name: read-pod-sa
roleRef:name: read-podapiGroup: rbac.authorization.k8s.iokind: ClusterRole
subjects:
- name: read-pod-sakind: ServiceAccountapiGroup: rbac.authorization.k8s.io
准入
准入控制器位于api server中,有两种,第一是变更(Mutating)准入控制:修改请求的对象 。第二是验证(Validating)准入控制:验证请求的对象 。准入控制(Admission Control)是 Kubernetes 中的一种机制,用于在请求到达 API 服务器后但在其持久化之前(持久化是指将资源对象(如 Pod、Service、ConfigMap 等)保存到集群的持久存储中),对请求进行拦截和处理。准入控制器可以对请求进行修改(变更)或验证(验证),确保集群的安全性和策略一致性。
如果没有准入控制的话集群就是在裸奔,kube-apiserver 是 Kubernetes 集群的网关,所有的请求都需要通过它来访问集群。它提供了一个 RESTful API 接口,通过这个接口,用户、开发者、运维人员以及 Kubernetes 内部组件都可以与集群进行交互。
准入控制是为了定义我们授权检查完成之后的其他安全操作的,进一步补充了授权机制,一般在创建、删除修改或者做代理的时候做补充。
k8s的准入控制其实是一个准入控制插件的列表,发送到APIserver的请求都需要通过这个列表中的每个准入控制插件的检查,如果某一个控制器插件准入失败,就准入失败。
练习:
kubectl create rolebinding aa --clusterrole=view --serviceAccount=rbac:myapp --namespace=rbac
kubectl create clusterrolebinding bb --clusterrole=cluser-admin --user=root
kubectl create clusterrolebinding aa --clusterrole=view --serviceAccount=system:serviceaccounts:myapp