クラスターアクセス管理

プリンシパル (ヒューマンユーザー) または自動プロセスは、適切な AWS アカウントのアクセス許可を提示することで AWS IAM を介して認証します。このステップでは、適切な AWS IAM プリンシパル (ロールまたはユーザー) にマッピングされます。

次に、EKS アクセスエントリは、Kubernetes アクセス許可のみを含む適切なアクセスポリシーを定義することで、この IAM プリンシパルを Kubernetes RBAC プリンシパル (ユーザーまたはグループ) にマッピングします。

Kubernetes エンドユーザーがクラスターにアクセスしようとすると、その認証リクエストは aws-iam-authenticator または AWS EKS CLI によって処理され、kubeconfig ファイルのクラスターコンテキストに対して検証されます。

最後に、EKS オーソライザーは、認証されたユーザーのアクセスエントリに関連付けられたアクセス許可を検証し、それに応じてアクセスを許可または拒否します。

設定ミスのリスクを軽減: API ベースの直接管理により、ConfigMap の手動編集に関連する一般的なエラーを排除します。これにより、クラスターからユーザーをロックアウトする可能性のある誤った削除や構文エラーを防ぐことができます。

最小特権の原則を強化: クラスター作成者 ID からクラスター管理者アクセス許可が不要になり、より詳細で適切なアクセス許可の割り当てが可能になります。このアクセス許可は、Break Glass ユースケースに追加できます。

拡張セキュリティモデル: アクセスエントリが適用される前に、組み込みの検証を提供します。さらに、 は認証のために AWS IAM とのより緊密な統合を提供します。

オペレーションの合理化: AWS ネイティブツールを使用してアクセス許可を管理する、より直感的な方法を提供します。

AWS Organizations を使用して複数のアカウントを管理し、サービスコントロールポリシー (SCPs。

最小特権の原則を実装するには、さまざまな EKS ロール (管理者、開発者、読み取り専用など) に特定のアクセス許可セットを作成します。

属性ベースのアクセスコントロール (ABAC) を使用して、ユーザー属性に基づいてポッドにアクセス許可を動的に割り当てます。

アクセス許可を定期的に監査して確認します。

Identity Center によって生成されたロール ARNs にはランダムなサフィックスがあるため、静的設定での使用が困難です。

Kubernetes リソースレベルでのきめ細かなアクセス許可のサポートが制限されました。カスタム Kubernetes RBAC ロールには追加の設定が必要です。Kubernetes ネイティブ RBAC に加えて、EKS クラスターでの高度なアクセス許可管理に Kyverno を使用することを検討してください。

IAM アクセス許可をきめ細かく制御します。

予測可能なロール ARN と静的ロール ARNs

ユーザーアカウントの管理オーバーヘッドの増加

一元化された ID 管理の欠如

IAM エンティティの拡散の可能性

セキュリティと管理性を向上させるために、IAM ユーザーの代わりに IAM ロールを使用する

一貫性と管理の容易性を確保するために、ロールの命名規則を実装する

IAM ポリシー条件を使用して、タグやその他の属性に基づいてアクセスを制限します。

アクセスキーを定期的にローテーションし、アクセス許可を確認します。

多数のユーザーまたはロールを管理する際のスケーラビリティの問題

組み込みのシングルサインオン機能がない

既存の ID 管理システムとの統合

ユーザーアカウントの管理オーバーヘッドの削減

追加の設定の複雑さ

認証中のレイテンシーが増加する可能性

外部 ID プロバイダーへの依存関係

OIDC プロバイダーを慎重に設定して、安全なトークン検証を確保します。

有効期間の短いトークンを使用し、トークン更新メカニズムを実装します。

OIDC 設定を定期的に監査および更新します。

IAM と比較して AWS サービスとのネイティブ統合が制限されました。

EKS が署名キーを検出するには、OIDC プロバイダーの発行者 URL がパブリックにアクセス可能である必要があります。