「Kubernetes Objects」- ServiceAccount | 为应用提供惟一的身份

认识

如何赋予应用程序唯一的身份，以便从细节上控制其对 Kubernetes 资源的访问？

创建 ServiceAccount（服务帐号）资源，并在 Pod 的 Spec 中使用该资源； 

# kubectl create serviceaccount myappsa
# kubectl describe serviceaccount myappsa
# kubectl describe secret "myappsa-token-rr6jc" # 参数 "myappsa-token-rr6jc" 由上一步输出；

然后，在 Pod 中使用该 ServiceAccount 资源： 

kind: Pod
apiVersion: v1
metadata:
  name: myapp
spec:
  serviceAccountName: myappsa
  container:
  - name: main
    image: centos:7
    command:
    - "sleep"
    - "infinity"

验证该 Pod 正常使用 ServiceAccount 资源： 

# kubectl exec myapp -c main cat /var/run/secrte/kubernetes.io/serviceaccount/token

如果正确挂载就会有输出；

# 讨论

「可以识别的实体」是认证和授权的前提条件。从 APIServer 的角度看，由两种类型的实体：终端用户；应用程序。终端用户不再 K8S 的管理范围内，但是 k8s 提供了代表应用程序的以及资源：ServiceAccount；

严格来讲，应用程序的认证由 token 认证，并保存在本地的 /var/run/secrets/kubernetes.io/serviceaccount/token 文件中，该文件通过 secret 自动挂载。ServiceAccount 属于 Namespace 的资源，访问形式如下：

system:serviceaccount:$NAMESPACE:$SERVICEACCOUNT

查看某个命名空间内的 ServiceAccount，可以看到类似的信息： 

# kubectl get serviceaccounts
NAME            SECRETS   AGE
default         1         365d

这里由一个名为 defalut 的服务帐号，提示自动创建的；

如果不明确为 Pod 指定 ServiceAccount，则系统会自动在该 Pod 的 Namespace 内为其分配为 default 的 ServiceAccount；

查看访问权限信息

如何查看可用的操作？例如更新部署或列举 secret？

假如你采用的是 RBAC：

# kubectl auth can-i list pod –as=system:serviceaccount:sec:myappsa -n=sec

查看 Namespace 中的 Role 列表：

# kubectl get roles -n=kube-system

# kubectl get clusterroles -n kube-system # 查看命名空间内的 ClusterRole 列表

上述命令显示预定义的 Role 列表；

进一步查看允许的操作

# kubectl describe clusterroles/view -n kube-system

还可以自定义角色，下面会介绍；

Filed under: K4NZDROID - @ 12:31 AM