API Server作为Kubernetes网关,是访问和管理资源对象的唯一入口,一个Pod如果要想访问API Server需要经过以下步骤
第一步：对客户端访问进行认证操作，确认是否具有访问k8s权限 #这步就是Pod引用Service Account,决定是否能访问API Server
token(共享秘钥)
SSL(双向SSL认证)
....通过任何一个认证即表示认证通过，进入下一步
第二步：授权检查，确认是否对资源具有相关的权限 #这步就是创建一个ClusterRole或者Role,然后ClusterRoleBinding或者RoleBinding把ClusterRole和Server Account绑定到一起,决定该Service Account有权限访问API Server的哪些资源,比如Deployment、Pod之类的
ABAC(基于属性的访问控制)
RBAC(基于角色的访问控制)
NODE(基于节点的访问控制)
WEB HOOK(自定义HTTP回调方法的访问控制)
第三步：准入控制(对操作资源相关联的其他资源是否有权限操作)
ServiceAccount
一.ServiceAccount和User Account介绍
Kubernetes中账号区分为:Service Account(服务账户)和User Account(用户账户),它们的设计及用途如下
1).User Account介绍
User Account是给Kubernetes集群外部使用的,例如运维或者集群管理员,使用kubectl 命令时就是用的User Account账户
User Account是全局性;在集群所有NameSpace中,名称具有唯一性.
用户名称可以在kubeconfig中查看
[root@Centos8 ~]# cd ~/.kube/ [root@Centos8 .kube]# ls cache config http-cache [root@Centos8 .kube]# cat config ... users: - name: kubernetes-admin ...
2)Service Account介绍
Service Account是给运行在Pod里的程序使用的身份认证,Pod容器的进程需要访问API Server时用的就是Service Account账户
Service Account仅局限在它所在的NameSpace，只有该NameSpace下的Pod引用这个Service Account才有权限，每个NameSpace创建时都会自动创建一个Secret(访问API Server时用的Token和CA)和一个Service Account，然后Service Account引用Secret;
如果每个Pod不指定Service Account的话，就会自动引用该NameSpace下默认的Service Account，此时该Pod可以访问API Server了；
Service Account为服务提供了一种方便的认证机制，但是Service Accoun不关心授权问题，Pod绑定该Service Account之后，仅仅是能访问API Server了,但是能访问API Server的哪些资源(Deployment、Pod、ConfigMap之类的资源)，需要配合RBAC来为Service Account授权
二.默认的Service Account
Service Account仅局限它所在的NameSpace，所以在创建NameSpace时会自动创建一个默认的SA,而SA创建时，也会创建对应的Secret，下面操作验证
1)创建命名空间
[root@Centos8 .kube]# kubectl create ns vfan namespace/vfan created
2)查看SA
[root@Centos8 .kube]# kubectl get sa -n vfan NAME SECRETS AGE default 1 67s
3)查看SA引用的默认Secret
[root@Centos8 .kube]# kubectl describe sa default -n vfan Name: default Namespace: vfan Labels: <none> Annotations: <none> Image pull secrets: <none> Mountable secrets: default-token-wwbc8 Tokens: default-token-wwbc8 Events: <none> [root@Centos8 ~]# kubectl get secret -n vfan NAME TYPE DATA AGE default-token-wwbc8 kubernetes.io/service-account-token 3 3m15s
可以看到，创建ns时默认创建了SA，SA默认创建了一个 kubernetes.io/service-account-token类型的secret
所有引用该SA的Pod都能访问API Server了
4)创建一个Pod
文件名:pods.yaml
apiVersion: v1 kind: Pod metadata: name: testnamespace: vfan spec: containers: - name: test image: radial/busyboxplus:curl stdin: true
tty: true
为什么pod使用镜像： radial/busyboxplus:curl ，是为了方便执行 curl命令来进行验证
5)查看Pod引用默认的SA
[root@Centos8 rbac]# kubectl describe pod test -n vfan ... Containers: test: Mounts: /var/run/secrets/kubernetes.io/serviceaccount from default-token-wwbc8 (ro) Volumes: default-token-wwbc8: Type: Secret (a volume populated by a Secret) SecretName: default-token-wwbc8 Optional: false ...
说明:每个Pod在创建后都会引用这个default的Service Account,除非指定了其他的Service Account
每个Container启动后都会挂载对应的ServiceAccount引用的Secret里的token、namespace、ca.crt到/var/run/secrets/kubernetes.io/serviceaccount下
6)进入Pod查看挂载的Token、CA、namespace信息
/test $ ls -l /var/run/secrets/kubernetes.io/serviceaccount/ total 0 lrwxrwxrwx 1 root root 13 Nov 27 09:00 ca.crt -> ..data/ca.crt lrwxrwxrwx 1 root root 16 Nov 27 09:00 namespace -> ..data/namespace lrwxrwxrwx 1 root root 12 Nov 27 09:00 token -> ..data/token
##说明：
可以看到已将ca.crt 、namespace和token放到容器内了，那么这个容器就可以用Token和CA通过https的请求访问apiserver了
7)进入Pod测试访问API Server的权限
#kubectl exec -it test -n vfan $curl --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt --header "Authorization:Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" https://$KUBERNETES_SERVICE_HOST:$KUBERNETES_SERVICE_PORT/api/v1/namespaces/$(cat/var/run/secrets/kubernetes.io/serviceaccount/namespace)/pods { "kind": "Status", "apiVersion": "v1", "metadata": { }, "status": "Failure", "message": "pods is forbidden: User "system:serviceaccount:mynamespace:default" cannot list resource "pods" in API group "" at the cluster scope", "reason": "Forbidden", "details": { "kind": "pods" }, "code": 403 ##表示403无法访问,没权限
###注意：
虽然该Pod的能访问API Server了,还得通过RBAC为该Service Account授权,来决定该ServiceAccount有权限访问API Server的哪些资源,比如Deployment、Pod、Node、Configmap等资源
授权
接下来就要通过RBAC给default这个service account授权,来让default这个Service Account拥有list pod的权限
一、添加ClusterRole
#cat example-clusterrole.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: example-clusterrole rules: - apiGroups: - "" resources: - nodes - nodes/proxy - nodes/metrics - services - endpoints - pods - ingress verbs: - get - list - watch - nonResourceURLs: - /metrics verbs: - get
二、通过ClusterRoleBinding把ClusterRole和ServiceAccount绑定到一起,Service Account就有ClusterRole定义的权限了
通过ClusterRoleBinding给所有NameSpace下的default Service Account授权
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: example-clusterrolebinding subjects: - kind: Group name: system:serviceaccounts apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: example-clusterrole apiGroup: rbac.authorization.k8s.io
二、也可以通过ClusterRoleBinding给单独一个NameSpace下的defult Service Account授权 （可以跟上面的二选一,是给所有授权,还是单独一个授权）
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: annotations: name: example-clusterrolebinding roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: exampe-clusterrole subjects: - kind: ServiceAccount name: default namespace: vfan
三、再次进入容器，通过执行curl命令获取所有pod，执行成功
#kubectl attach -it test -n vfan $curl --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt --header "Authorization:Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" https://$KUBERNETES_SERVICE_HOST:$KUBERNETES_SERVICE_PORT/api/v1/namespaces/$(cat/var/run/secrets/kubernetes.io/serviceaccount/namespace)/pods ... "imageID": "docker-pullable://radial/busyboxplus@sha256:a68c05ab1112fd90ad7b14985a48520e9d26dbbe00cb9c09aa79fdc0ef46b372", "containerID": "docker://d6b1a94caa364392ac7e3c07dd99faa1c80f15fe6f757aa54509ea778b6c93aa", "started": true } ], "qosClass": "BestEffort" } } ]