認証 - Container Service for Kubernetes - Alibaba Cloud ドキュメントセンター

Container Service for Kubernetes (ACK) クラスターを保護するために、最小権限の原則に基づく認証、認可、および Pod アイデンティティのプラクティスを適用します。

ACK クラスターにおける認証と認可

Kubernetes は、X.509 証明書、ベアラートークン、認証プロキシ、または OIDC を使用して API リクエストを認証します。ACK は、クライアント証明書とサービスアカウントトークンの 2 つのアクセス方法をネイティブにサポートしています。

Alibaba Cloud コンソールから、または ACK OpenAPI を呼び出して、クライアント証明書を含むkubeconfig ファイルを取得します。

ACK の認可には、RAM 認可と RBAC 認可があります。RAM は、システムポリシーとカスタムポリシーの 2 種類の認可ポリシーをサポートしています。クラスターの可視性管理、クラスターのスケーリング、ノードの追加などの操作には、カスタム RAM ポリシーを作成してください。Pod やノードなどの Kubernetes リソースを管理するには、ACK コンソールの [Authorizations] ページで、RAM ユーザーに RBAC 権限を付与します。認可の概要をご参照ください。

一時的な kubeconfig ファイルと API サーバー認証の使用

デフォルトの kubeconfig 証明書の有効期間は 3 年です。漏えいした場合、攻撃者はクラスターの API サーバーに直接アクセスできます。デフォルトのサービスアカウントトークンも長期の静的認証情報であり、漏えいすると、サービスアカウントが削除されるまで、攻撃者は紐付けられたクラスターアクセス権限を取得します。

漏えいした kubeconfig 認証情報は速やかに失効させてください。kubeconfig ファイルの取得と使用をご参照ください。
最小権限の原則に基づく Alibaba Cloud リソースへのアクセス

ACK クラスターへのアクセスを付与する際は、他のクラウド製品の権限を含めないでください。RAM と RBAC を使用して、必要最小限の権限を適用してください。
RoleBinding と ClusterRoleBinding の作成時における最小権限の原則の適用

RoleBinding および ClusterRoleBinding リソースを作成する際は、最小権限の原則に従ってください。Role および ClusterRole 定義で ["*"] を使用しないでください。明示的な verbs を指定してください。audit2rbac などのツールを使用して、Kubernetes 監査ログからロールとバインディングを生成できます。
ACK クラスターエンドポイントのアクセス範囲の制御

デフォルトでは、ACK クラスターの API サーバーエンドポイントには、クラスターとその Virtual Private Cloud (VPC) 内の内部ネットワークからのみアクセスできます。サービスをインターネットに公開するには、アノテーションを使用して Classic Load Balancer (CLB) を構成してください。
クラスターアクセス権限の定期的な監査

クラスターアクセス権限は時間の経過とともに変化します。RAM と RBAC の権限を定期的に確認し、アクセス権が適切であることを検証してください。kubectl-who-can や rbac-lookup などのツールを使用して権限を監査し、過剰なアクセスを削除してください。

Pod 認証

Kubernetes クラスター内の一部のアプリケーションは Kubernetes API へのアクセスを必要とします。たとえば、ACK Cloud Controller Manager (CCM) には、ノードリソースの作成、読み取り、更新、削除を行う権限が必要です。

Kubernetes サービスアカウント

サービスアカウントは、Kubernetes RBAC ロールを Pod に割り当てます。Kubernetes は各 namespace にデフォルトのサービスアカウントを作成します。特定のサービスアカウントを参照せずにデプロイされた Pod は、その namespace のデフォルトのサービスアカウントを使用します。JSON Web Token (JWT) を含む Secret が、/var/run/secrets/kubernetes.io/serviceaccount にマウントされます。このトークンをデコードすると、次のメタデータが表示されます。
```
{
  "iss": "kubernetes/serviceaccount",
  "kubernetes.io/serviceaccount/namespace": "default",
  "kubernetes.io/serviceaccount/secret.name": "default-token-vpc2x",
  "kubernetes.io/serviceaccount/service-account.name": "default",
  "kubernetes.io/serviceaccount/service-account.uid": "1d059c50-0818-4b15-905d-bbf05e1d****",
  "sub": "system:serviceaccount:default:default"
}
```
デフォルトのサービスアカウントには、次の Kubernetes API 権限があります。
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:discovery
rules:
- nonResourceURLs:
  - /api
  - /api/*
  - /apis
  - /apis/*
  - /healthz
  - /openapi
  - /openapi/*
  - /version
  - /version/
  verbs:
  - get
```
このロールは、未認証ユーザーおよび認証済みユーザーに対して API ディスカバリー情報への読み取りアクセスを付与し、公開しても安全であると見なされます。

Pod から Kubernetes API を呼び出す場合は、明示的な API 権限を持つサービスアカウントを割り当ててください。最小権限の原則に従い、バインドする Role または ClusterRole を必要な API リソースとメソッドのみに制限してください。デフォルト以外のサービスアカウントを使用するには、Pod spec の spec.serviceAccountName フィールドを設定してください。ServiceAccount 権限をご参照ください。
サービスアカウントトークンのボリュームプロジェクションの使用

セキュリティリスクを軽減するために、ACK でサービスアカウントトークンのボリュームプロジェクションを有効にしてください。kubelet は Pod ごとのトークンを発行します。audience と有効期限を構成でき、トークンの有効期間の 80% 経過時、または 24 時間後にローテーションされます。ServiceAccount トークンのボリュームプロジェクションの使用をご参照ください。
インスタンスメタデータ API へのノードアクセスの制限

ECS インスタンスメタデータは、実行中のインスタンスからアクセスでき、クラウドリソースの詳細やユーザーデータなどの機密データを含む場合があります。メタデータへの無制限なアクセスは、マルチテナント環境で悪用される可能性があります。Egress を必要としない Pod では、ネットワークポリシーを使用して meta-server へのアクセスを制限してください。次の例では、podSelector を使用して、meta-server へのアクセスを含め、指定した Pod のすべての Egress をブロックします。
```
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-egress
  namespace: example
spec:
  podSelector:
    matchLabels:
      app: myapp
  policyTypes:
  - Egress
  egress: []
```
ACK クラスターでネットワークポリシーを使用するをご参照ください。
Pod へのサービスアカウントトークンの自動マウントの無効化

次のいずれかの方法を使用して、サービスアカウントトークンの自動マウントを無効にしてください。
方法1：Pod YAML で、automountServiceAccountToken を false に設定します。
```
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  serviceAccountName: build-robot
  automountServiceAccountToken: false
  ...
```
方法2：namespace のデフォルトのサービスアカウントにパッチを適用し、automountServiceAccountToken フィールドを false に設定します。
```
kubectl patch serviceaccount default -p $'automountServiceAccountToken: false'
```
アプリケーションごとの専用サービスアカウントの割り当て

きめ細かな権限分離のために、各アプリケーションに専用のサービスアカウントを割り当ててください。Pod のサービスアカウントの構成をご参照ください。
非 root ユーザーとしてのアプリケーション実行

コンテナはデフォルトで root として実行され、プロセスに任意のファイルアクセスを付与します。代わりに、PodSpec に spec.securityContext.runAsUser プロパティを追加し、非 root のユーザーIDを指定してください。

この例では、すべての Pod プロセスが runAsUser フィールドで指定されたユーザー ID で実行されます。
```
apiVersion: v1
kind: Pod
metadata:
  name: security-test
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
  containers:
  - name: sec-test
    image: busybox
    command: [ "sh", "-c", "sleep 1h" ]
```
コンテナプロセスは root 専用ファイルにアクセスできません。securityContext に fsGroup を追加すると、コンテナ内のファイルへの読み取りアクセスが付与されます。
```
spec:
  securityContext:
    fsGroup: 65534
```
アプリケーションに Alibaba Cloud リソースへのアクセスを付与する際の最小権限の原則の適用

アプリケーションノードに不要な RAM 権限を付与しないでください。最小権限の原則に従って、きめ細かな RAM ポリシーを作成してください。権限ポリシーで ["*"] などのワイルドカードを使用すると、過剰なアクセスが付与される可能性があるため避けてください。

Authenticator webhook 認証

RAM SSO 統合を使用し、Kubernetes RBAC 認可を個別に管理する場合は、API サーバー webhook 認証に ack-ram-authenticator を使用してください。利点は次のとおりです。

柔軟で制御可能なデータプレーン RBAC 認可を備え、エンタープライズクラウド SSO をサポートします。
ロールベースの SSO 統合シナリオでは、API サーバー監査ログにエンタープライズ IDP のアイデンティティ情報が含まれるため、同じロールを引き受ける異なる IDP ユーザーを監査できます。
従業員の RAM ユーザーまたはロールが削除されると、関連するクラスター RBAC 権限は自動的に失効します。