このページの改善にご協力ください

このユーザーガイドに貢献するには、すべてのページの右側のペインにある「GitHub でこのページを編集する」リンクを選択してください。

EKS 機能のセキュリティに関する考慮事項

このトピックでは、EKS 機能のセキュリティを考慮するうえで重要な事項について説明します。具体的には、IAM ロール設定、Kubernetes アクセス許可、マルチクラスターデプロイとクロスアカウント AWS リソース管理のアーキテクチャパターンなどです。

EKS 機能では、IAM ロール、EKS アクセスエントリ、Kubernetes RBAC を組み合わせることにより、AWS サービスとクラスター内 Kubernetes リソースに安全にアクセスし、AWS CodeConnections、AWS Secrets Manager、およびその他の AWS サービスと統合できます。

機能 IAM ロール

機能を作成するときは、自分の代わりに EKS がアクションを実行するように IAM 機能ロールを指定できます。このロールの要件は次のとおりです。

ここでのベストプラクティスは、特定のユースケースに必要な権限の範囲を考慮したうえで、要件を満たすために必要なアクセス許可のみを付与することです。例えば、Kube Resource Orchestrator に EKS 機能を使用する場合には IAM アクセス許可は必要ありませんが、Kubernetes 用 AWS コントローラーに EKS 機能を使用する場合には 1 つ以上の AWS サービスへのフルアクセスを許可できます。

機能 IAM ロールの作成と設定の詳細については、「Amazon EKS 機能 IAM ロール」を参照してください。

EKS アクセスエントリ

IAM ロールと共に機能を作成すると、Amazon EKS がそのロールのアクセスエントリをクラスターに自動的に作成します。このアクセスエントリにより、動作に必要なベースラインとなる Kubernetes アクセス許可が機能に付与されます。

アクセスエントリの内容は以下のとおりです。

機能別のデフォルトアクセスエントリポリシー

機能タイプごとに必要なアクセス許可が機能ロールに付与され、次のように異なるデフォルトアクセスエントリポリシーが設定されます。

詳細については、「アクセスポリシーアクセス許可を確認する」を参照してください。

その他の Kubernetes アクセス許可

機能によっては、デフォルトのアクセスエントリポリシーの範囲を超える Kubernetes アクセス許可が追加で必要になる場合があります。こうしたアクセス許可を付与するには、次のいずれかを使用します。

ACK シークレット読み取りアクセス許可

ACK コントローラーによっては、データベースパスワードなどの機密データを取得するために Kubernetes シークレットを読み取る必要があります。次の ACK コントローラーでは、シークレット読み取りアクセスが必要です。

シークレット読み取りアクセス許可を付与するには:

kro による任意のリソースアクセス許可

kro には、ResourceGraphDefinitions に定義されたリソースを作成および管理するためのアクセス許可が必要です。デフォルトでは、kro は RGD 自体を監視および管理できるだけです。

kro にリソースを作成するためのアクセス許可を付与するには:

オプション 1: アクセスエントリポリシー

AmazonEKSAdminPolicy や AmazonEKSEditPolicy などの事前定義済みのアクセスエントリポリシーを機能のアクセスエントリに関連付けます。

オプション 2: Kubernetes RBAC

ClusterRoleBinding を作成して、機能の Kubernetes ユーザーに必要なアクセス許可を付与します。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kro-cluster-admin
subjects:
- kind: User
  name: arn:aws:sts::111122223333:assumed-role/my-kro-role/kro
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

機能で必要な IAM アクセス許可

セキュリティのベストプラクティス

IAM 最小特権

ユースケースに必要なアクセス許可のみを機能リソースに付与します。これは、機能には必要に応じて広範な管理アクセス許可を付与できないという意味ではありません。このような場合は、そうしたリソースに対するアクセスを適切に管理する必要があります。

機能ロール:

例: "Resource": "*" ではなく、特定のリソースやリソースグループに対するパターンを指定します。

"Resource": [
  "arn:aws:s3:::my-app-*",
  "arn:aws:rds:us-west-2:111122223333:db:prod-*"
]

IAM 条件キーを使用して、アクセスをさらに制限します。

"Condition": {
  "StringEquals": {
    "aws:ResourceTag/Environment": "production"
  }
}

IAM 設定の詳細については、各機能の考慮事項に関するセクションを参照してください。

Argo CD シークレットの名前空間の分離

マネージド Argo CD 機能は、自身に設定された名前空間内のすべての Kubernetes シークレットにアクセスできます (デフォルト: argocd)。最適なセキュリティ体制を維持するには、名前空間の分離に関する以下のプラクティスに従ってください。

この分離により、Argo CD のシークレットアクセスは、Git リポジトリの認証やその他の Argo CD に固有のオペレーションに必要な認証情報のみに制限されます。

Kubernetes RBAC

機能リソースを作成および管理できるユーザーおよびサービスアカウントを制御します。ここでのベストプラクティスは、適切な RBAC ポリシーに沿って専用の名前空間に機能リソースをデプロイすることです。

例: ACK で RBAC ロールを使用して、app-team 名前空間で S3 バケットリソースを管理できるようにします。

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: ack-s3-manager
  namespace: app-team
rules:
- apiGroups: ["s3.services.k8s.aws"]
  resources: ["buckets"]
  verbs: ["get", "list", "create", "update", "delete"]

監査ログ

CloudTrail: すべての EKS Capability API オペレーション (作成、更新、削除) が AWS CloudTrail に記録されます。

CloudTrail ログ記録では以下を追跡できます。

ネットワークアクセスおよび VPC エンドポイント

プライベート Argo CD API アクセス

Argo CD API サーバーへのアクセスを制限するには、ホストされた Argo CD エンドポイントに 1 つ以上の VPC エンドポイントを関連付けます。これにより、パブリックインターネットを経由することなく、VPC 内から Argo CD UI と API へのプライベート接続が可能になります。

プライベートクラスターにデプロイする

Argo CD 機能ではアプリケーションを完全にプライベートな EKS クラスターにデプロイできるため、VPC ピアリングや複雑なネットワーク設定が不要になり、運用面で大きなメリットが得られます。ただし、このアーキテクチャを設計するときは、Argo CD が Git リポジトリ (パブリックの場合あり) から設定をプルして、プライベートクラスターに適用するようにすることを検討してください。

以下の点を確認します。

コンプライアンス

EKS 機能は、完全マネージド型で、Amazon EKS のコンプライアンス認定を受けています。

現在のコンプライアンス情報については、「コンプライアンスプログラムによる対象範囲内の AWS サービス」を参照してください。

次のステップ