IDの検証とアクセス制御 - Container Service for Kubernetes - Alibaba Cloud ドキュメントセンター

本人確認およびアクセス制御システムは、認証および許可機能を提供する。認証は、ユーザーがクラスターにアクセスするときにユーザーのIDを確認するために使用されます。権限付与は、クラスター内のリソースにアクセスする権限をユーザーに付与するために使用されます。

ACKクラスターでの認証と承認

Kubernetesは、X.509証明書、ベアラートークン、認証プロキシ、またはOpenID Connect (OIDC) プロトコルを使用してAPIリクエストを認証します。 Container Service For Kubernetes (ACK) クラスターへのアクセスに使用されるデフォルトの方法の詳細については、「クライアント証明書」および「サービスアカウントトークン」をご参照ください。

クライアント証明書を含むkubeconfigファイルは、ACKコンソールまたはACK APIを呼び出して取得できます。詳細については、「クラスターのkubeconfigファイルの照会」をご参照ください。

ACKの承認メカニズムは、RAM (Resource Access Management) 承認とRBAC (role-based access control) 承認で構成されます。クラスターの構成の変更、クラスターのスケール、またはRAMユーザーとしてクラスターにノードを追加する場合は、RAM権限付与を実行する必要があります。 RAM権限付与を使用すると、システムポリシーまたはカスタムポリシーをRAMユーザーにアタッチできます。 RAMユーザーを使用してクラスター内のKubernetesリソースを管理する場合は、ACKコンソールの [権限] ページに移動し、ポッドとノードに関する情報を表示する権限など、RAMユーザーにリソーススコープの権限を付与する必要があります。詳細については、「権限付与の概要」をご参照ください。

クラスターのKubernetes APIサーバーにアクセスするときの認証に一時的なkubeconfigファイルを使用する
ACKクラスターのデフォルトのkubeconfigファイルには、3年間有効な証明書が含まれています。 kubeconfigファイルが公開されている場合、攻撃者はそれを使用してクラスターのKubernetes APIサーバーにアクセスできます。デフォルトのサービスアカウントトークンは、永続的に有効な静的な資格情報です。デフォルトのサービスアカウントトークンが公開されている場合、攻撃者はトークンを悪用して、削除されるまで関連するサービスアカウントと同じ権限を取得できます。
配信されたkubeconfigファイルが公開されている場合は、できるだけ早くkubeconfigファイルを取り消すことを推奨します。詳細については、「クラスターのkubeconfigファイルの取り消し」をご参照ください。 ACKクラスターのkubeconfigファイルの詳細については、「一時的なkubeconfigファイルの生成」をご参照ください。
最小権限の原則に準拠したAlibaba Cloudリソースへのアクセスの付与
ユーザーにACKクラスターへのアクセスを許可する場合、他のAlibaba Cloudサービスのリソースへのアクセス権限を付与しないでください。 RAM権限付与とRBAC権限付与を使用して、ユーザーにACKクラスターへのアクセス権限を付与できます。
最小特権原則に準拠したRoleBindingsとClusterRoleBindingsの作成
最小権限の原則に従って、RoleBindingsとClusterRoleBindingsを作成する必要があります。 RoleまたはClusterRoleを定義する場合は、Verbsフィールドで ["*"] の代わりに必要なアクションを指定します。付与する権限を決定できない場合は、audit2rbacなどのツールを使用して、ロールとロールのバインドを作成できます。 audit2rbacは、Kubernetes監査ログに記録されたすべてのAPI操作をカバーするロールとロールバインディングを生成できます。
ACKクラスターのエンドポイントへのアクセスの制限
デフォルトでは、ACKクラスターのエンドポイントには、クラスター内およびクラスターがデプロイされている仮想プライベートクラウド (VPC) からのみアクセスできます。サービスのインターネットアクセスを有効にし、エンドポイントへのアクセスを制御する方法の詳細については、「CLBインスタンスを構成するためのサービスのYAMLファイルへの注釈の追加」をご参照ください。
ユーザーの権限を定期的に監査する
クラスターに対するユーザーの権限は、時間によって変更される場合があります。クラスターのセキュリティ管理者とO&Mエンジニアは、各RAMユーザーのRAM権限とRBAC権限を定期的に確認し、必要な権限のみが付与されていることを確認する必要があります。セキュリティ管理者とO&Mエンジニアは、オープンソースツールを使用して、サービスアカウント、ユーザー、またはグループに付与されているRBAC権限を確認し、不要な権限を削除できます。詳細については、「kubectl-who-can」および「rbac-lookup」をご参照ください。

ポッド認証

Kubernetesクラスターでは、一部のアプリケーションとプログラムにKubernetesのAPI操作を呼び出す権限が必要です。 ACKクラスターでは、クラウドコントローラーマネージャー (CCM) にノードを追加、削除、変更、およびクエリする権限が必要です。

Kubernetesサービスアカウント
サービスアカウントを使用して、RBACロールをポッドに割り当てることができます。 Kubernetesは、クラスター内の名前空間ごとにデフォルトのサービスアカウントを作成します。ポッドを作成するときに、サービスアカウントを指定しないと、ポッドには同じ名前空間の既定のサービスアカウントが自動的に割り当てられます。 JSON webトークン (JWT) を格納するシークレットは、ポッドの /var/run/secrets/kubernetes.io/serviceaccountディレクトリにボリュームとしてマウントされます。トークンをデコードすると、次のメタデータが返されます。
```
{
  "iss": "kubernetes/serviceaccount" 、
  "kubernetes.io/serviceaccount/namespace": "default" 、
  "kubernetes.io/serviceaccoun t/secret.name": "default-token-vpc2x" 、
  "kubernetes.io/serviceaccoun t/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情報を読み取る権限を付与できます。この役割は、公にアクセスできると安全であると見なされます。
ポッドで実行されるアプリケーションまたはプログラムがKubernetes APIを呼び出す場合、必要な権限を持つサービスアカウントをポッドに割り当てる必要があります。サービスアカウントに関連付けられているRoleまたはClusterRoleで定義されている権限は、ポッドがアクセスする必要があるAPIリソースと、ポッドが使用する必要があるメソッドにスコープする必要があります。これは、最小特権原理に従う。デフォルト以外のサービスアカウントを使用するには、ポッド構成のspec.serviceAccountNameフィールドを、使用するサービスアカウントの名前に設定します。サービスアカウントの作成方法の詳細については、「ServiceAccountアクセス許可」をご参照ください。
サービスアカウントトークンボリューム投影の有効化
ACKはサービスアカウントトークンボリューム予測を提供し、ポッドがサービスアカウントを使用してKubernetes APIサーバーにアクセスするときのセキュリティリスクを軽減します。この機能により、kubeletはポッドの代わりにトークンを要求して保存できます。この機能では、オーディエンスや有効期間などのトークンプロパティを設定することもできます。トークンが24時間を超えて存在している場合、または有効期間の20% 以下しか残っていない場合、kubeletはトークンを自動的に回転させます。詳細については、「サービスアカウントトークンのボリュームプロジェクションの有効化」をご参照ください。
インスタンスメタデータへのアクセス制限
ECS (Elastic Compute Service) インスタンスメタデータには、Alibaba CloudのECSインスタンスに関する情報が含まれています。実行中のインスタンスのメタデータを表示し、メタデータに基づいてインスタンスを構成または管理できます。インスタンスメタデータには、使用済みのクラウドリソースやユーザーデータなどの機密情報が含まれています。インスタンスのメタデータが、インスタンスにデプロイされたポッドに公開されている場合、マルチテナントのシナリオでは、攻撃者によって情報が悪用される可能性があります。アウトバウンド要求を送信する必要がないポッドの場合、ネットワークポリシーを使用して、ポッドがメタサーバーにアクセスすることを禁止できます。次のコードブロックは、podSelectorパラメーターで指定されたラベルを持つポッドからのすべての送信リクエストをブロックするネットワークポリシーを示しています。このように、一致するポッドはメタサーバーにアクセスできません。
```
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-metadata-access
  namespace: example
spec:
  podSelector:
    matchLabels:
      app: myapp
  policyTypes:
  - Egress
  egress: []
```
詳細については、「ACKクラスターでのネットワークポリシーの使用」をご参照ください。
ポッドのサービスアカウントトークンの自動マウントを無効にする
次のいずれかの方法を使用して、ポッドのサービスアカウントトークンの自動マウントを無効にできます。
方法1: 次のYAMLテンプレートを使用して、PodSpecのautomountServiceAccountTokenをfalseに設定します。
```
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  serviceAccountName: build-robot
  automountServiceAccountToken: false
  ...
```
方法2: 次のコマンドを実行して、パッチを使用して、名前空間の既定のサービスアカウントのautoamountServiceAccountTokenパラメーターをfalseに設定します。
```
kubectl patch serviceaccount default -p $'automountServiceAccountToken: false'
```
各アプリケーションに個別のサービスアカウントを割り当てる
詳細なアプリケーション権限管理を有効にするには、各アプリケーションに個別のサービスアカウントを割り当てる必要があります。詳細については、「ポッドのサービスアカウントの構成」をご参照ください。
非rootユーザーとしてアプリケーションを実行
デフォルトでは、コンテナーはrootユーザーとして実行されます。これにより、コンテナ内のプロセスがコンテナ内のデータに対して読み取りおよび書き込み操作を実行できるようになり、セキュリティのベストプラクティスに違反します。コンテナーをroot以外のユーザーとして実行するには、spec.securityContext.ru nAsUserパラメーターをPodSpecに追加します。要件に基づいて、runAsUserを適切な値に設定します。
次のテンプレートでは、ポッド内のすべてのプロセスが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権限を必要とするファイルにアクセスできません。 fsgroup=65534 [Nobody] をsecurityContextパラメーターに追加すると、コンテナー内のプロセスはこれらのファイルにアクセスできます。
```
spec:
  securityContext:
    fsGroup: 65534 
```
最小権限の原則に準拠したAlibaba Cloudリソースへの権限付与
RAMユーザーまたはRAMロールに過度の権限を付与しないでください。最小限の権限の原則に従ってRAMポリシーを構成する必要があります。また、ポリシーコンテンツで ["*"] を指定するなど、過度の権限を付与する可能性のある設定を構成しないでください。

Authenticator webhook認証

SSOをRAMと統合するか、Kubernetes RBAC認証を使用する場合は、ack-ram-authenticatorを使用してwebhook認証を設定することを推奨します。詳細については、「ack-ram-authenticatorを使用してACKマネージドクラスターのAPIサーバーがwebhook認証を完了するのを支援する」をご参照ください。 ack-ram-authenticatorには次の利点があります。

ユーザーがSSOロールとAuthenticator KubeConfigを使用してAPIサーバーにアクセスするシナリオでは、APIサーバーの監査ログには、エンタープライズIDプロバイダー (IDP) によって提供されるID情報が含まれます。これにより、APIサーバーは、同じ役割を担うユーザーから送信されたリクエストを認証できます。
ack-ram-authenticatorは、RBAC認証を実装するための柔軟で制御可能な方法を提供します。
RAMユーザーまたはRAMロールが削除されると、ack-ram-authenticatorは従業員からAuthenticator KubeConfigを自動的に取り消すことができます。