Amazon Web Services ブログ

Okta SSO で Amazon EKS を管理する



Amazon Elastic Kubernetes Service (Amazon EKS) を使用すれば、Kubernetes を使ってコンテナ化されたアプリケーションを簡単にデプロイ、管理、スケーリングできます。Okta は、開発者がユーザーアカウントとユーザーアカウントデータを作成、編集、安全に保存し、それらを 1 つまたは複数のアプリケーションに接続できるようにする API サービスです。Okta は、スケーラブルで安全な方法で組織の AWS マネジメントコンソールまたは AWS CLI へのアクセスを提供するのに役立ちます。Okta では、Active Directory または LDAP 認証情報を使用して AWS サービスを使用できます。

Okta が提供する ID を使用して Amazon EKS クラスターを認証する方法を示します。Amazon EKS は、IAM を使用して Kubernetes クラスターに認証を提供しますが、認証はネイティブの Kubernetes ロールベースアクセスコントロール (RBAC) に依拠しています。つまり、IAM は有効な IAM エンティティの認証にのみ使用されます。Amazon EKS クラスターの Kubernetes API とやり取りするためのすべての権限は、ネイティブの Kubernetes RBAC システムを通じて管理されます。

EKS クラスターを作成すると、クラスターを作成する IAM エンティティ (ユーザーまたはロール) が RBAC 管理者 (システム: マスター権限を持つ) になります。最初は、その IAM ID のみが kubectl を使用して Kubernetes API サーバーを呼び出すことができます。クラスターが作成されたら、組織内の他のメンバーにアクセス権を付与できます。

ソリューションの概要

セクション 1 では、Okta アカウントを作成し、次に IAM ID プロバイダーを作成します。これにより、Okta アカウントでユーザーを管理できるようになりますが、ユーザーは IAM ロールを引き受けることができます。

セクション 2 では、IAM ユーザーを作成します。Okta はこのユーザーのアクセス認証情報を使用して IAM ロールを一覧表示し、人間の Okta ユーザーがログインしたときに、Okta が引き受けることができるロール一覧を表示できるようにします。また、EKS クラスターを管理するユーザーが引き受けるロールも作成します。

セクション 3 と 4 では、Okta IdP のセットアップを完了し、Okta ユーザーを使用して AWS マネジメントコンソールにログインし、AWS CLI を使用します。

最後にセクション 5 と 6 で、EKS クラスターと、Kubernetes クラスターの名前空間の 1 つを変更する権限のみを持つ別のロールを作成します。それでは、始めましょう。

セクション 1: AWS アカウント用に SAML 2.0 を構成する

まず Okta アカウントを作成します。まだアカウントをお持ちでない場合は、developer.okta.com で無料アカウントにサインアップできます。Okta アカウントを作成した後に最初に行うことは、新しい AWS アカウントフェデレーションアプリケーションを作成することです。

ステップ 1: Okta アプリを作成する

Okta 開発者コンソールでクラシック UI に切り替えるか、この記事のスクリーンショットが一致しない可能性があります。

  • [開発者コンソール] をクリックし、次に [クラシック UI] を選択します。

  • [アプリケーション] をクリックします。

  • 次の画面で、[アプリケーションの追加] をクリックすると、アプリケーションの追加ウィザードが起動します。

  • [アプリケーションの追加] 画面で、AWS アカウントフェデレーションを検索します。
  • [追加] をクリックします。

  • アプリケーションのラベルを必要なものに変更します。
  • 残りの値はデフォルトのままにすることができます。
  • [次へ] をクリックします。

Okta アプリケーションをさらに進める前に、metadata.xml をダウンロードする必要があります。IAM は、ID プロバイダーを作成するためにこのメタデータドキュメントを必要とします。

  • リンク [ID プロバイダーメタデータ] をクリックします。
  • この XML ファイルを metadata.xml として保存します。
  • このブラウザウィンドウは開いたままにして、次のステップのために別のウィンドウを開きます。

ステップ 2: AWS マネジメントコンソールを使用して IDP を作成する

別のブラウザタブで、AWS IAM コンソールに移動して ID プロバイダーを作成します。

SSO の設定に関する Okta のドキュメント。

IAM コンソールに移動します。

  • [ID プロバイダー] をクリックします。
  • [プロバイダーの作成] をクリックします。

  • [プロバイダータイプ] に SAML を選択し、Okta を [プロバイダー名] として使用します。
  • 前の手順で保存した [メタデータドキュメント] の metadata.xml をアップロードします。

  • [次のステップ] をクリックして詳細を確認し、[作成] をクリックします。
  • 次の画面は、作成された Okta プロバイダーを示しています。

  • 新しく作成した [Okta] ID プロバイダーをクリックします。
  • [プロバイダー ARN] をコピーします。

ステップ 3: Okta AWS アカウントフェデレーションアプリの作成を完了する

Okta 管理コンソールに戻り、Okta AWS アカウントフェデレーションアプリの作成を終了します。

  • [サインオンオプション] 画面で、[詳細サインオン設定] までスクロールします。
  • 前の手順でコピーしたプロバイダー ARN を [ID プロバイダー ARN] に貼り付けます。
  • [完了] をクリックします。

セクション 2: Okta 統合用の IAM ロールとユーザーを作成する

次に、OktaEKSRole という IAM ロールを作成します。このロールは、EKS クラスターを作成するためのアクセス許可を必要とする組織内のユーザーによって引き受けられます。このロールに必要な特定の権限についてのアドバイスを控えていることにお気づきになることでしょう。実際には必要な権限が異なるためです。特に EKS クラスターの管理にユーザーのロールが必要になることはほとんどありません。ロールはユーザーの特定の責任にマップする必要があります。

ステップ 1: Okta SSO 用の OktaEKSRole を作成する

  • AWS マネジメントコンソールにログインし、IAM に移動します。
  • [ロールの作成] をクリックします。
  • 次の画面で、[SAML 2.0 フェデレーション] を選択します。
  • SAML プロバイダーの場合、最後のステップで作成された [Okta] を選択します。
  • さらに、[プラグラムおよび AWS マネジメントコンソールへのアクセスを許可] のラジオボタンを選択します。
  • [次: アクセス許可] をクリックします。

次の画面で、ロールに割り当てるポリシーを選択します。エンドユーザー (EKS クラスターを管理する権限を持つユーザーになる場合) がこのロールを引き受けます。次に [編集] をクリックします。

このブログでは操作を簡単にするために、このロールに本番環境での使用には適していない管理者アクセス権を付与します。現実の世界では、ポリシーはユースケースに依存し、最小権限アクセスの原則を使用する必要があります。詳細については、Amazon EKS での Identity and Access Management を参照してください。

  • エンドユーザーに継承してほしいポリシーを検索します。
  • [次のタグ] をクリックします。
  • タグを追加し、[次: 確認] をクリックします。
  • 次の画面でロール名の入力を求められます。次のステップで参照するために OktaEKSRole と呼びます。
  • [ロールの作成] をクリックします。

ステップ 2: OktaMasterAccountPolicy を作成する

次のステップで作成する IAM ユーザー OktaUserForSSO にアタッチする、OktaMasterAccountPolicy という IAM ポリシーを作成します。この IAM ユーザーのアクセスキーとシークレットアクセスキーをダウンロードし、それを使って後半のステップで Okta アプリを構成します。

  • IAM コンソールで、左側のメニューにある [ポリシー] をクリックします。
  • [ポリシーを作成] をクリックします。
  • [ポリシーの作成] 画面で、[JSON] タブをクリックし、次のポリシーを入力します。
  • [ポリシーの確認] をクリックします。
{
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "iam:ListRoles",
                    "iam:ListAccountAliases"
                 ],
                "Resource": "*"
            }
        ]
    }
  • 次の画面で、このポリシーに [OktaMasterAccountPolicy] という名前を付けます。
  • [ポリシーを作成] をクリックします。

ステップ 3: IAM OktaUserForSSO を作成する

次に、OktaUserForSSO という IAM ユーザーを作成します。この IAM Okta ユーザーは、IAM ロールの詳細をダウンロードするために使用され、使用可能なロール一覧がエンドユーザーに提示されます。それに OktaMasterAccountPolicy をアタッチします。

IAM コンソールに移動します。IAM 画面で [ユーザー] → [ユーザーの追加] をクリックします。

  • ユーザー名として [OktaUserForSSO] を入力し、[アクセスタイプ] → [プログラムによるアクセス] を選択します。
  • [次: アクセス許可] をクリックします。

  • [既存のポリシーを直接添付する] をクリックします。
  • [OktaMasterAccountPolicy] を検索して選択します。
  • [次のタグ] をクリックします。
  • 必要なタグを追加して、[次: 確認] をクリックします。
  • 次の画面で情報を確認し、[ユーザーの作成] をクリックします。

  • 次のステップで Okta アプリの構成に使用されるアクセスキーを含む [.csv をダウンロード] します。

セクション 3: Okta AWS アカウントフェデレーションアプリを構成する

このセクションでは、セクション 1 で開始した Okta AWS アカウントフェデレーションアプリの作成を完了します。

ステップ 1: Okta API 統合を構成する

  • Okta 管理コンソールに戻り、[アプリケーション] をクリックします。
  • [AWS アカウントフェデレーション] アプリをクリックします。
  • [プロビジョニング] タブをクリックします。
  • 画面の下部にある [API 統合の構成] をクリックします。

  • [API 統合を有効にする] チェックボックスを選択します。
  • OktaUserForSSO の [アクセスキー ID] と [シークレットアクセスキー] を入力します (前のステップでダウンロードした CSV ファイルにあります)。
  • [保存] をクリックします。

  • [プロビジョニング] タブで [編集] をクリックします。
  • [ユーザーの作成] チェックボックスを選択します。
  • [ユーザー属性の更新] チェックボックスを選択します。
  • [保存] をクリックします。

ステップ 2: Okta ユーザーを AWS アカウントフェデレーションアプリに割り当てる

  • [アプリケーション] をクリックします。
  • [詳細] をクリックし、アプリケーションデータを更新します。これにより新しい IAM ロールが取得されます。
  • [アプリケーション] をクリックして、このアプリケーションにユーザーを割り当てます。
  • [割り当て] ドロップダウンメニューをクリックします。
  • [担当者に割り当てる] を選択します。

  • ユーザー名の横にある [割り当て] をクリックします。

  • [ロール] の値に [OktaEKSRole] を選択します。
  • [SAML ユーザーロール] までスクロールします。
  • [SAML ユーザーロール] 値の [OktaEKSRole] の横にあるチェックボックスを選択します。
  • [保存して戻る] をクリックします。

ステップ 3: SSO を使用して AWS コンソールにログインする

  • Okta 管理コンソールで、画面の右上隅にある [マイアプリ] をクリックします。

  • [AWS アカウントフェデレーション] アプリをクリックします。
  • これで、AWS マネジメントコンソールにサインインできます。

[ロール選択] 画面が表示されたら、[OktaEKSRole] ラジオボタンを選択し、[サインイン] をクリックします。これは、ユーザーに複数のロールがある場合に発生します。

AWS マネジメントコンソールにシングルサインオンしました。次のセクションでは、AWS CLI を使用して Okta のシングルサインオンを構成します。

セクション 4: Okta AWS CLI Assume Role ツールを設定する

このセクションでは、AWS CLI アクセスと kubectl に同じ Okta ユーザーを使用します。Okta AWS CLI SSO を構成するために、Okta AWS CLI 引き受けロールツールを使用します。ツールの現在のバージョンには、JDK 11 以降が必要です。ツールと JDK をラップトップにインストールする代わりに、このツールを Docker コンテナとして実行します。そのため、ツールをローカルにインストールしないことを選択した場合は、Docker ランタイムもインストールする必要があります。次の手順は、Amazon Linux 2 と MacOS を実行する Cloud9 でテストされています。

ステップ 1: Okta EKS イメージをビルドする

すべてのコードを含む Github リポジトリを作成しました。Okta AWS CLI で Docker イメージを作成し、ロールツールとその依存関係を引き受けます。

GitHub リポジトリを複製します。

mkdir ~/environment
cd ~/environment 
git clone https://github.com/aws-samples/eks-rbac-sso

okta-eks-image イメージをビルドします。

cd ~/environment/eks-rbac-sso
docker build -t okta-eks-image.

この画像には、次のツールとサポートフレームワークが含まれています。

  • eksctl
  • kubectl
  • okta-aws-cli-assume-role ツール

イメージのビルドには約 15 分かかります。完了すると、出力は次のようになります。

Successfully built 8eec5f670e31
Successfully tagged okta-eks-image:latest

ステップ 2: Okta プロパティファイルを編集する

okta_eks_role.properties ファイルで、OKTA_ORG、OKTA_AWS_APP_URL、OKTA_USERNAME、および OKTA_AWS_ROLE_TO_ASSUME プレースホルダーの値を置き換える必要があります。

cd ~/environment/eks-rbac-sso
vi okta_eks_role.properties

OKTA_USERNAME の値を Okta ユーザー名に置き換えます。

OKTA_ORG と OKTA_AWS_APP_URL の値を設定する
Okta Org と App URL の値は、AWS アカウントフェデレーションアプリケーションで確認できます。

  • Okta 管理コンソールに移動し、[アプリケーション] をクリックします。
  • AWS アカウントフェデレーションアプリの右側にある [設定アイコン] をクリックします。
  • [埋め込みリンクをコピー] をクリックします。

  • okta_eks_role.properties の OKTA_AWS_APP_URL 値を、このコピーしたアプリの URL に置き換えます。
  • OKTA_ORG は、OKTA_AWS_APP_URL でコピーされた URL xxxx.okta.com の一部です。以下のテキストで強調されています。
https://xxxx.okta.com/home/amazon_aws/xxxxx/xxxx

OKTA_AWS_ROLE_TO_ASSUME の値を設定する

  • AWS マネジメントコンソールにログインし、IAM に移動します。
  • 左側のメニューで [ロール] をクリックします。
  • OktaEKSRole を検索し、その ARN を次のようにコピーします。
  • okta_eks_role.properties の OKTA_AWS_ROLE_TO_ASSUME 値を OktaEKSRole Arn に置き換えます。
arn:aws:iam::xxxxxx:role/OktaEKSRole

okta_eks_role.properties ファイルを確認して確定する

cd ~/environment/eks-rbac-sso
cat okta_eks_role.properties

ファイルにプレースホルダー値が表示されていないことを確認します。

OKTA_ORG=dev-111111.okta.com
OKTA_AWS_APP_URL=https://dev-111111.okta.com/home/amazon_aws/1111aaa111/111
OKTA_USERNAME=111@111.com
OKTA_AWS_ROLE_TO_ASSUME=arn:aws:iam::11111:role/OktaEKSRole
OKTA_AWS_REGION=us-west-2
OKTA_PROFILE=default

ステップ 3: コンテナを実行する

前のステップで作成したイメージから Docker コンテナを作成します。

docker run -v \
 ~/environment/eks-rbac-sso/okta_eks_role.properties:/root/.okta/config.properties \
 -v /var/run/docker.sock:/var/run/docker.sock \
 -v ~/environment/eks-rbac-sso/aftifacts/:/root/artifacts/ \
 -it okta-eks-image /bin/bash

このコマンドは、コンテナを起動して、コンテナのシェルにドロップします。

bash-4.2#

okta-aws-cli-assume-role 設定を確認する

okta-eks-image には、okta-aws-cli-assume-role がインストールおよび設定されています。これはオープンソースのツールであり、okta-aws と呼ばれるシェル関数を作成します。この関数は bash と fish をサポートし、Okta SSO で AWS CLI コマンドを実行できます。現在の AWS Identity を取得して、セットアップされていることを確認しましょう。

okta-aws default sts get-caller-identity

この関数は Okta パスワードの入力を求めます。ユーザー名には、okta_eks_role.properties ファイルで指定した値がすでに入力されています。出力は次のようになります。

    "Account": "xxxxx",
    "UserId": "AAAXXXX:xxxxx@xxxx.com",
    "Arn": "arn:aws:sts::xxxxxxx:assumed-role/OktaEKSRole/xxxxx@xxxx.com"

セクション 5: EKS クラスターを作成する

すべてのツール (kubectl、eksctl、およびその他の依存関係) は、作成した docker okta-eks-image にすでにインストールおよび構成されています。

ステップ 1: ブログの構成ファイルをコピーする

アカウント ARN および AWS リージョンの環境変数をエクスポートし、init.sh を実行します。次の構成ファイルを Docker コンテナの ~/okta-blog-config フォルダにコピーし、okta-blog-config フォルダ内の次のファイルにある AWS アカウント ARN および AWS リージョンプレースホルダーを置き換えます。

  • assume-role-policy-document.json
  • aws-auth-okta-prodadmin-role.yaml
  • iam-role-policy.json
  • okta-kubectl-blog-cluster.yaml
  • role-binding-production-admin.yaml
  • role-production-admin.yaml
cd ~/artifacts
chmod +x init.sh
./init.sh

出力は次のようになります。

AWS_REGION: us-west-2
ACCOUNT_ID: 111111111

?注: 次のエラーが発生した場合は、okta-aws default sts get-caller-identity を実行して認証情報を更新してください。

GetCallerIdentity オペレーションを呼び出すときにエラーが発生しました (ExpiredToken): 
リクエストに含まれるセキュリティトークンの有効期限が切れています。

ステップ 2: EKS クラスターを作成して検証する

okta-kubectl-blog-cluster.yml を使用して EKS クラスターを作成します。AWS リージョンの値が okta-kubectl-blog-cluster.yaml で空白でないことを確認してください。

cat ~/okta-blog-config/okta-kubectl-blog-cluster.yaml

次に、EKS クラスターを作成します。

eksctl create cluster -f ~/okta-blog-config/okta-kubectl-blog-cluster.yaml

?注: EKS とすべての依存関係の起動には約 15 分かかります。

完了すると、出力は次のようになります。

EKS cluster "okta-kubectl-blog-eksctl" in "us-west-2" region is ready

kubectl が機能していることがわかります。Kubectl は OktaEKSRole 権限を使用します。

kubectl get nodes
# 3 つのノードが表示されます

セクション 6: OktaProdAdminRole を使用するように EKS クラスターを構成する

OktaEKSRole には、EKS クラスター全体に対する管理レベルのアクセス権があり、このロールを持つユーザーは何でも実行できます。しかし、範囲が限定されたロールが必要な場合はどうでしょうか。本番環境の名前空間内でのみ権限が制限されているロールを作成する必要がある場合はどうなりますか? どうやったら出来ますか?

クラスター全体に対する権限を必要としないユーザーに別の IAM ロールを作成し、RBAC で権限を構成できます。

ステップ 1: IAM ロール OktaProdAdminRole を作成する

OktaProdAdminRole という IAM ロールを作成します。assume-role-policy-document.json は、Okta を SAML 2.0 の信頼できるエンティティとして構成します。これにより、SAML 2.0 とフェデレーションされた Okta ユーザーは、この OktaProdAdminRole がクラスター内の本番名前空間でアクションを実行できるようになります。このコマンドでこのファイルを表示できます。

cat ~/okta-blog-config/assume-role-policy-document.json

次のコマンドは OktaProdAdminRole を作成します。

aws iam create-role --role-name OktaProdAdminRole \
 --assume-role-policy-document file://~/okta-blog-config/assume-role-policy-document.json \
 --output text --query 'Role.Arn'

コマンドの出力には、OktaProdAdminRole の ARN が表示されます。

arn:aws:iam::1111111:role/OktaProdAdminRole

次に、IAM セキュリティポリシーを OktaProdAdminRole にアタッチします。このポリシーは、エンドユーザーに EKS サービスへのフルアクセスを許可します。セキュリティポリシーは iam-role-policy.json ファイルにあります。

aws iam put-role-policy --role-name OktaProdAdminRole \
 --policy-name eks-full-access-policy \
 --policy-document file://~/okta-blog-config/iam-role-policy.json

ステップ 2: IAM ロール OktaProdAdminRole を Okta ユーザーに割り当てる

OktaProdAdminRole ロールを Okta ユーザーに割り当てます。Okta 管理コンソールを使用して割り当てるには、次の手順通りに実行します。

  • Okta 管理コンソールに移動します。
  • [アプリケーション] をクリックします。
  • [詳細] をクリックし、アプリケーションデータを更新します。これにより新しい IAM ロールが取得されます。
  • [AWS アカウントフェデレーション] アプリをクリックします。
  • クラスター内の本番稼働用の名前空間への管理者アクセス権を付与するユーザーの Okta ユーザー名の横にある [ペンアイコン] をクリックします。
  • [OktaProdAdminRole] の横にあるチェックボックスを選択します。
  • [保存] をクリックします。

ステップ 3: Kubernetes ロールとロールバインディングを作成する

IAM ロールを作成し、Okta ユーザーに割り当てました。次に、OktaProdAdminRole を Kubernetes ロールにマッピングします。
Kubernetes には、Role と ClusterRole の 2 種類のロールがあります。ロールは、名前空間内の権限を付与するために使用され、特定の名前空間に制限されています。ClusterRole を適用して、クラスター全体のリソースへのアクセスを許可できます。

OktaProdAdminRole を production-admin という名前の Kubernetes ロールにマップし、本番稼働用の名前空間内でのアクセスのみを許可します。RBAC Production Admin Role アクセスは、このファイル role-production-admin.yaml にあります。

cat ~/okta-blog-config/role-production-admin.yaml

本番稼働用の名前空間を作成する

kubectl create namespace production

Kubernetes ロールを作成する

kubectl apply -f role-production-admin.yaml

Kubernetes ロールバインディングを作成する

production-admin ロールを Kubernetes ユーザー production-user-admin にバインドしましょう。次の手順で、このユーザーを IAM ロール OktaProdAdminRole にマップします。

cat ~/okta-blog-config/role-binding-production-admin.yaml

RBAC ロールバインディングを作成するには、次のコマンドを実行します。

kubectl apply -f ~/okta-blog-config/role-binding-production-admin.yaml

? Roles と RoleBinding については、こちらをご覧ください。

ステップ 4: aws-auth Configmap を編集して OktaProdAdminRole をマッピングする

production-admin という名前の Kubernetes ロールを作成し、production-user-admin にバインドしたので、IAM ロール OktaProdAdminRole を RBAC ユーザー production-user-admin にマップできます。このロールを引き受けるエンドユーザーは、production-admin ロールの権限を持ちます。

マニフェストでアカウント ID が正しく設定されていることを確認してください。

cat  ~/okta-blog-config/aws-auth-okta-prodadmin-role.yaml

OktaProdAdminRole ARN を検証する

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: arn:aws:iam::{ACCOUNT_ID}:role/OktaProdAdminRole
      username: production-admin-user
      groups:
        - prod-admin-group

重要! 既存のクラスターでこれを行う場合は、既存の構成マップを上書きする代わりに編集してください。

次に、ConfigMap を適用して、このマッピングをシステムに適用します。

kubectl apply -f ~/okta-blog-config/aws-auth-okta-prodadmin-role.yaml

OktaProdAdminRole が構成されていることを確認する
次のコマンドを実行して、Configmap への変更を表示します。

kubectl -n kube-system get configmap/aws-auth -o yaml

OktaProdAdmin が Configmap に追加されたことがわかります。

apiVersion: v1
data:
  mapRoles: |
    - *rolearn**: arn:aws:iam::xxxxxxx:role/OktaProdAdminRole
      username: production-admin-user
      groups:
        - prod-amdin-group*
      rolearn: arn:aws:iam::xxxxxx:role/eksctl-eksworkshop-eksctl-nodegro-NodeInstanceRole-1QJK5GGFM27K4
      username: system:node:{{EC2PrivateDNSName}}
kind: ConfigMap
metadata:
....

?ヒント: aws-auth ConfigMap を手動で編集できます。次のコマンドを実行できます: kubectl edit -n kube-system configmap/aws-auth。

セクション 7: ロールを OktaProdAdminRole に切り替える

これまで、OktaEKSRole を使用して kubectl コマンドを実行してきました。OktaEKSRole は、クラスターで任意のアクション (取得、削除、更新など) を実行する権限を持っています。okta-eks-image を使用して別のコンテナを作成し、AWS アクセスには OktaProdAdminRole を使用します。

ステップ 1: okta_eks_role.properties をコピーする

別のターミナルウィンドウを開きます。okta_eks_role.properties ファイルをコピーして、okta_prod-admin_role.properties という名前の別のファイルを作成します。それから OktaEKSRole を OktaProdAdminRole に変更するか、次のコマンドを実行すると、ファイルが作成されロール名が変更されます。

cd ~/environment/eks-rbac-sso
./create-okta-prod-admin-properties.sh

ステップ 2: コンテナを OktaProdAdminRole として開始する

別のターミナルウィンドウを開き、okta-kubectl-image を OktaProdAdminRole として使用してコンテナを起動します。

docker run -v \
 ~/environment/eks-rbac-sso/okta_prod_admin_role.properties:/root/.okta/config.properties \
 -v /var/run/docker.sock:/var/run/docker.sock \
 -v ~/environment/eks-rbac-sso/aftifacts/:/root/artifacts/ \
 -it okta-eks-image /bin/bash

現在の IAM ロールを確認できます。

okta-aws default sts get-caller-identity

Okta パスワードの入力を求められます。

 { "Account": "11111", "UserId": "xxxxxxx", "Arn": 
    "arn:aws:sts::1111:assumed-role/*OktaProdAdminRole*/xxxxx" }

アカウントとリージョンの環境変数を設定します。

cd ~/artifacts
./init.sh

KubeConfig を更新して OktaProdAdminRole として接続する

次のコマンドで EKS クラスター名と AWS リージョンを置き換えて実行します。

okta-aws default eks --region us-west-2 \
 update-kubeconfig --name okta-kubectl-blog-eksctl

応答は次のようになります。

新しいコンテキストを追加 arn:aws:eks:us-west-2:111111:cluster/okta-kubectl-blog-eksctl
        in /root/.kube/config

ステップ 3: ポッドを OktaProdAdminRole として検証およびデプロイする

これで、本番稼働用の名前空間外でのすべてのアクションが拒否されます。実行しようとすると、

kubectl get pods

権限が拒否されたというメッセージを受け取ります。

サーバーからのエラー (禁止): ポッドは禁止されています: ユーザー "production-admin-user" 
名前空間 "default" の API グループのリソース "pods" を一覧表示できません

OktaProdAdmin ロールは本番稼働用の名前空間にしかアクセスできないため、リクエストで本番稼働用の名前空間を指定する必要があります。

kubectl get pods -n production

今回はエラーは発生しません。

リソースが見つかりませんでした。

ポッドの作成をテストできます。

kubectl create deployment nginx --image=nginx -n production

出力は以下のようになります。

deployment.apps/nginx created

EKS クラスター認証の管理については、こちらをご覧ください。さまざまな AWS ロールを作成して、Kubernetes ロールにバインドできます。

まとめ

Okta を使用して AWS サービスへの安全なアクセスを提供し、アクセス管理を簡素化する方法を示しました。このアプローチでは、組織のメンバーごとに IAM ユーザーを作成する必要はありません。Okta を使用すれば、ユーザーが会社に入社したり退職したりするときに、ユーザーアクセスや認証情報を簡単に維持できます。Active Directory または LDAP の認証情報を使用して AWS サービスにアクセスすることもできます。

参考文献:

AWS アカウントフェデレーション用に SAML 2.0 を構成する方法
ID プロバイダーとフェデレーション
サードパーティー用 SAML ソリューションプロバイダーと AWS の統合
AWS での SAML 2.0 フェデレーションのトラブルシューティング