IT 技書の森

Kubernetes サービスアカウント

Pod に割り当てる ID で、RBAC と連携して Pod の API アクセス権限を制御する

Kubernetes認証

Kubernetes サービスアカウントとは

サービスアカウント (ServiceAccount) は、Pod に割り当てる ID である。人間のユーザーアカウントとは異なり、Pod が Kubernetes API や外部サービスにアクセスする際の認証に使用する。RBAC (Role-Based Access Control) と組み合わせて、Pod ごとに最小権限を付与する。

基本的な設定

# 1. サービスアカウントの作成
apiVersion: v1
kind: ServiceAccount
metadata:
  name: order-service
  namespace: production
---
# 2. ロールの定義 (何ができるか)
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: order-service-role
  namespace: production
rules:
  - apiGroups: [""]
    resources: ["configmaps", "secrets"]
    verbs: ["get", "list"]
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]
---
# 3. ロールバインディング (誰に何を許可するか)
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: order-service-binding
  namespace: production
subjects:
  - kind: ServiceAccount
    name: order-service
roleRef:
  kind: Role
  name: order-service-role
  apiGroup: rbac.authorization.k8s.io
---
# 4. Pod にサービスアカウントを割り当て
apiVersion: v1
kind: Pod
metadata:
  name: order-service
spec:
  serviceAccountName: order-service
  containers:
    - name: app
      image: order-service:1.0

EKS での IAM 連携 (IRSA)

EKS では IAM Roles for Service Accounts (IRSA) を使って、サービスアカウントに IAM ロールを紐づけられる。Pod が S3 や DynamoDB にアクセスする際、ノードの IAM ロールではなく Pod 固有の IAM ロールで認証される。

apiVersion: v1
kind: ServiceAccount
metadata:
  name: order-service
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/order-service-role

IRSA のメリット:

  • Pod ごとに異なる IAM 権限を付与できる (ノード共有の IAM ロールより細かい制御)
  • 一時的な認証情報が自動的にローテーションされる
  • EC2 メタデータサービスへのアクセスが不要 (SSRF 攻撃のリスク軽減)

EKS Pod Identity (IRSA の後継)

2023 年に発表された EKS Pod Identity は、IRSA の後継として設計された。OIDC プロバイダーの設定が不要で、セットアップが簡素化されている。

apiVersion: v1
kind: ServiceAccount
metadata:
  name: order-service
# Pod Identity では annotations 不要。AWS コンソールまたは CLI で関連付け

デフォルトサービスアカウントの危険性

各 Namespace には default サービスアカウントが自動作成される。サービスアカウントを指定しない Pod はすべて default を使う。

問題点:

  • 全 Pod が同じ ID を共有するため、権限の分離ができない
  • 1 つの Pod が侵害されると、default に付与された権限が悪用される
  • 監査ログで「どの Pod がアクセスしたか」を区別できない

対策:

  • Pod ごとに専用のサービスアカウントを作成する
  • default サービスアカウントの自動マウントを無効化する
apiVersion: v1
kind: ServiceAccount
metadata:
  name: default
automountServiceAccountToken: false  # トークンの自動マウントを無効化

Role と ClusterRole の使い分け

種類 スコープ 用途
Role + RoleBinding Namespace 内 特定 Namespace のリソースへのアクセス
ClusterRole + ClusterRoleBinding クラスター全体 ノード、PV など Namespace を跨ぐリソース

サービスアカウント vs IAM ロール

観点 K8s サービスアカウント IAM ロール
スコープ Pod Lambda, ECS タスク
認証 OIDC トークン STS
AWS 連携 IRSA (IAM Roles for Service Accounts) ネイティブ

Kubernetes サービスアカウントの背景や設計思想は関連書籍に詳しい。

関連用語