ワークロード間でのServiceAccountの共有

異なるワークロードでServiceAccountを共有すると、権限の分離やインシデントの調査が難しくなる場合があります。

説明

同じ名前空間で同じ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を指定しています。実際に権限を分離するには、必要に応じてロールバインディングも分けてください。

参考資料