再度、aliceで全Namespaceに対してPodを取得を試みると、存在するPodの情報を取得できるようになりました。


$ kubectl get pods --all-namespaces
NAMESPACE            NAME                                         READY   STATUS    RESTARTS   AGE
default              hello-node-6b89d599b9-wmjvm                  1/1     Running   0          88m
kube-system          coredns-64897985d-7967k                      1/1     Running   0          96m
... (省略) ...
sample               nginx-deployment-9456bbbf9-ld2dp             1/1     Running   0          25m
sample               nginx-deployment-9456bbbf9-pm7q8             1/1     Running   0          25m
sample               nginx-deployment-9456bbbf9-xgwqb             1/1     Running   0          25m

ClusterRoleに関してはRoleBindingと組み合わせることも可能です。この場合、サブジェクトにRoleBindingで指定されたNamespaceに対するリソースの操作権限を付与できます。

また、ClusterRoleではaggregationRuleフィールドを使用することで、複数のClusterRoleを1つのClusterRoleに集約することも可能です。(詳細な設定方法は公式ドキュメント - 集約ClusterRoleを参照ください)

RBACの設定の際は、最小権限の原則に則って、サブジェクトに対してアクセス権を与えるリソースや操作は必要最小限とすることが重要です。

ServiceAccount

ServiceAccountとPodの関係

Kubernetesにはユーザーに似た概念として、ユーザー向けのアカウントと、Kubernetes内のサービス向けのアカウントであるServiceAccountがあります。ユーザー向けのアカウントはKubernetesのオブジェクトとして存在するわけではなく、Azure ADなどのIDプロバイダのアカウントとリンクして利用します。ServiceAccountはKubernetesの中で完結するリソースで、Namespaceにひもづけられていて、Podの動作を制約するために利用します。

Pod起動時にはServiceAccountを1つ以上割り当てる必要があるので、Namespaceを作成するとdefaultというServiceAccountが生成されます。kubectlコマンドでdefaultのServieAccountを確認してみると以下のようになっています。


% kubectl describe sa default -n demo 
Name:                default
Namespace:           demo
Labels:              
Annotations:         
Image pull secrets:  
Mountable secrets:   default-token-z4d65
Tokens:              default-token-z4d65
Events:

Mountable secretsはkubernetes.io/service-account-tokenタイプのSecretで、Bearerトークンと証明書から構成されており、Kubernetesが自動的に作成します。このトークンの更新したい場合は、該当のSecretを削除して自動生成するか、自分で指定することが可能です。

kubectlコマンドでSecretを確認すると以下のようになっています。


apiVersion: v1
data:
  ca.crt: (base64でエンコードされたAPIサーバーの認証局)
  namespace: ZGVtbw==　　← Namespaceをbase64でエンコードした文字列
  token: (base64でエンコードされたBearerトークン)
kind: Secret
metadata:
  # ...
type: kubernetes.io/service-account-token

これらのSecretはKubernetes APIサーバへのアクセス用にPod内の/var/run/secrets/kubernetes.io/serviceaccountにマウントされ、ServiceAccountとして認証するためにBearerトークンが利用されます。認証時には、ServiceAccountはユーザ名system:serviceaccount:(ネームスペース):(サービスアカウント) で認証され、グループ system:serviceaccount と system:serviceaccount:(ネームスペース) に割り当てられます。

Kubernetes APIの呼び出し時には、Podに割り当てたServiceAccountが持っているトークンによって認証が行われます。

  • サービスアカウント認証によるAPI呼び出し

Podが侵害された場合、マウントされたServiceAccountの権限でKubernetes APIの利用が可能になるので、ServiceAccountへの権限付与は最小限にしておくことが推奨されます。