説明
同じ名前空間で同じserviceAccountNameを使うワークロードは、同一のサービスアカウントのAPI権限を使います。現在のPodに紐付いたトークンはPodごとに発行されるため、アカウントが同じでもトークンの文字列まで同じとは限りません。ワークロードが侵害されると、共有アカウントの権限が悪用されるおそれがあります。
ワークロードの役割が異なる場合はServiceAccountを分けてください。同じアプリケーションのレプリカなど、必要な権限が同じPodでアカウントを共有することは、適切な構成である場合もあります。
想定される影響
- 異なるワークロードに、必要以上の共通権限が付与されるおそれがあります。
- 1つのワークロードの侵害が、共有アカウントでアクセスできる他のリソースに影響する可能性があります。
- 監査ログでワークロードごとのリクエストを区別しにくくなる場合があります。
対処方法
- 用途が異なるワークロードには別々のServiceAccountを使用してください。
- 共有アカウントに過剰な権限がないか確認してください。
- アプリケーションの権限要件に応じてアカウントを分け、それぞれに必要なRBAC権限だけを付与してください。
例
2つのPodを同じ名前空間に配置する想定です。参照するServiceAccountと必要なロールバインディングは別途作成してください。
変更前
yaml
apiVersion: v1
kind: Pod
metadata:
name: pod1
spec:
serviceAccountName: service1
containers:
- name: mycontainer
image: redis
---
apiVersion: v1
kind: Pod
metadata:
name: pod2
spec:
serviceAccountName: service1
containers:
- name: envars-test-container
image: nginx
変更後
yaml
apiVersion: v1
kind: Pod
metadata:
name: pod1
spec:
serviceAccountName: service1
containers:
- name: mycontainer
image: redis
---
apiVersion: v1
kind: Pod
metadata:
name: pod2
spec:
serviceAccountName: service2
containers:
- name: envars-test-container
image: nginx
説明:
- 変更前: 両方のワークロードが同じServiceAccountの権限を使います。必要なアクセスが異なる場合は分離してください。
- 変更後: 別々のServiceAccountを指定しています。実際に権限を分離するには、必要に応じてロールバインディングも分けてください。