Kubernetesアクセス管理を構成する
前提条件
- Kubernetesアクセス管理機能が有効な既存のOkta Privileged Accessチーム
- 既存のK8sクラスター
- TerraformおよびOktaPAM Terraformプロバイダーがインストールおよび構成されたデバイス
- v1.61.2以降のOkta Privileged Accessクライアントがインストールされたデバイス
- kubectlがインストールされたデバイス
OktaPAM Terraformプロバイダーを準備する
最初に管理者は、Okta Privileged Access内に作成するクラスターリソースを定義するTerraformファイルを作成する必要があります。このファイルには、特定のOkta Privileged Accessチームの認証情報も含める必要があります。詳細については、「認証」を参照してください。
例
terraform { required_providers { oktapam = { source = "okta/oktapam" version = "0.2.1" } } } provider "oktapam" { # Authentication options oktapam_key = # An Okta PAM API Key oktapam_secret = # An Okta PAM API Secret oktapam_team = # An Okta PAM Team Name }
Kubernetesアクセス管理向けにOkta Privileged Accessを構成する
Okta Privileged AccessがKubernetesクラスターへのアクセスを管理するには、Okta Privileged Accessと管理対象クラスターの両方に相互に関する情報を構成する必要があります。
各クラスターを効果的に管理するには、クラスターのAPIサーバーアドレスとTLS証明書の両方が含まれるクラスターオブジェクトを作成し、更新することが重要です。kubernetesが管理する各クラスターは、Okta Privileged AccessをOIDC認証エンドポイントとして使用するように構成されている必要があります。OktaPAM Terraformプロバイダーは、クラスターごとにこの情報をOkta Privileged Accessに構成する際に使用されるkubernetes固有のリソースをサポートします。
クラスターのリソースをOkta Privileged Accessに構成すると、Okta Privileged Access管理者は、Okta Privileged AccessコンソールのKubernetesセクションでクラスターに関する情報をレビューできるようになります。
-
クラスター：すでに追加されているすべてのクラスターをリスト表示します。チームは、関連付けられているラベルをこのページで素早く確認することもできます。特定のクラスターをクリックすると、詳細ビューが表示されます。チームは、クラスターに関連付けられているOIDC認証URLを取得できます。
-
クラスターグループ：すでに追加されているすべてのクラスターグループをリスト表示します。チームは、各クラスターグループのラベルをこのページで確認できます。
タスク1：Okta Privileged Accessにクラスターを追加する
まず、Okta Privileged Accessリソース管理者は、Okta Privileged Access内に作成する1つ以上のK8sクラスターリソースを定義するリソースブロックを追加する必要があります。各クラスターリソースには、その特定クラスターの認証の構成に使用されるOIDC URLが関連付けられています。チームは一度に複数のクラスターを追加できますが、クラスターごとに個別のリソースブロックを作成する必要があります。
オプションとして、チームはクラスターリソースの1つ以上のラベルセレクターを定義できます。チームは、これらのラベルを使って各クラスターへのグループアクセスを制御できます。
| リクエスト | |
|---|---|
| パラメーター | 説明 |
| auth_mechanism | クラスターに認証の詳細を提供するために使われる特定のメカニズム。現在サポートされるのは、OIDC_RSA2048のみです。 |
| key | Okta Privileged Access内のクラスターの識別に使われる判読可能な名前。空白文字は使用できません。使用できる文字は、A～Z、0～9です。 |
| labels | Okta Privileged Access内のグループアクセスの制御に使われるラベルのマップ。 |
| 応答 | |
| プロパティ | 説明 |
| id | Okta Privileged Access内に作成されるリソースのID。 |
| oidc_issuer_url | K8sクラスターの構成に使用されるOIDC Issuer URL。 |
| 例
resource "oktapam_kubernetes_cluster" "asa_docs" { auth_mechanism = "OIDC_RSA2048" key = "asadocs" labels = { env = "prod", tier = "gold" } } |
|
タスク2：Okta Privileged Accessをクラスター情報で更新する
Okta Privileged Accessには、kubectl構成ファイルを管理し、ユーザーがクラスターにアクセスできるようにするために、管理しているクラスターに関する追加情報が必要です。この情報には、クラスターのAPIサーバーとのHTTPS接続の確立に使用される、クラスターのAPIサーバーのアドレスと証明書が含まれます。この情報は、クラスターの作成方法とホスティング場所に応じて、Terraform状態ファイルから（Terraformで構築されたクラスターの場合）、またはクラスター管理コンソールまたはAPIサーバーから取得できます。
| リクエスト | |
|---|---|
| パラメーター | 説明 |
| cluster_id | クラスターのIDは、oktapam_kubernetes_clusterリソースから返されます。 |
| api_url | KubernetesクラスターのHTTPS URL。これは、Okta Privileged Accessクライアントによってユーザーのkubeconfigファイルに構成されるエンドポイントです。 |
| public_certificate | クラスターのAPIサーバーで使用されるPEMエンコードされたTLS証明書。この証明書は、クラスターのAPIサーバーが提示する証明書の検証時にkubectlによって使用されます。 AWS EKSクラスターでは、AWS EKSの詳細ページに信頼証明書が表示されます。ただし、このリソースに渡すには、証明書データを事前にPEM形式に変換する必要があります。この変換は、base64 -decodeコマンドで実行できます。 |
| 応答 | |
| プロパティ | 説明 |
| id | Okta Privileged Access内に作成されるリソースのID。 |
| oidc_issuer_url | K8sクラスターの構成に使用されるOIDC Issuer URL。 |
| 例
resource "oktapam_kubernetes_cluster_connection" "asa_docs" { cluster_id = oktapam_kubernetes_cluster.asa_docs.id api_url = data.tls_certificate.asa_docs.url public_certificate = data.tls_certificate.asa_docs.certificates[0].cert_pem } |
|
タスク3：クラスターグループを作成する
最後に、管理者は1つ以上のクラスターグループリソースブロックを作成する必要があります。クラスターグループは、既存のOkta Privileged AccessグループをKubernetesクラスターにマッピングし、チームがグループごとの特定のラベルとクレームを定義できるようにします。チームは一度に複数のクラスターグループを追加できますが、グループごとに個別のリソースブロックを作成する必要があります。
ラベルは、グループのどのクラスターメンバーがアクセス可能であるかを制御します。たとえば、チームは一部のクラスターにenv: prodセレクターを割り当て、その他のクラスターにenv: devセレクターを割り当てるかもしれません。その上で、特定のグループのみにprodラベルを割り当てる可能性があります。
Okta Privileged Accessがトークンに含めるクレームを指定するときは、Okta Privileged Accessに作成したクレームのキー名と、クラスターロールバインディングに構成されるキー名が完全に一致することを確認してください。同様に、ロールバインディングに指定されたKubernetesクラスタークレーム値が使用プレフィックスを指定する場合（AWS EKS）、Okta Privileged Accessに構成されたクレーム値にプレフィックスとクレーム値が含まれることを確認してください。
たとえば、groupsPrefixの値をpam、groupsClaimの値をgroupsでEKSクラスターのOIDC構成を構成する場合、Okta Privileged Access内にクラスターグループを作成するときは、groups = pam:<groupname>というクレームを構成する必要があります（この<groupname>は、クラスターに作成されたロールバインディングの名前）。
クレームは、Okta Privileged Accessが作成するトークンに含まれており、KubernetesクラスターがトークンをKubernetesロールバインディングにマッピングするときに使用されます。グループの全メンバーは、関連付けられているクラスターとのやりとりでこのロールを受信します。
この機能は、クラスター上のロールバインディングを作成または管理しません。クレームにマッピングされるロールとロールバインディングは、クラスターに事前に構成されている必要があります。
| リクエスト | |
|---|---|
| パラメーター | 説明 |
| cluster_selector | ラベルクラスターは、K8sクラスターの照合に使用されます。 |
| group_name | 既存のOkta Privileged Accessグループの判読可能な名前。値の大文字/小文字は区別されます。 |
| claims | クラスター認証に使われるユーザー資格情報が含まれるクレームのマップ。クラスターに事前に構成されるロールバインディングに対応するクレーム。 |
| 応答 | |
| プロパティ | 説明 |
| id | Okta Privileged Access内に作成されるリソースのID。 |
| 例
resource "oktapam_kubernetes_cluster_group" "asa_docs" { cluster_selector = "env=prod" group_name = "existingGroup" claims = { groups = "ExampleGroup" } } |
|
タスク4：クラスターを構成する
チームがOkta Privileged Access内にリソースを作成したら、管理者は、認証にOkta Privileged Accessを使用するようにクラスターを構成する必要があります。
チームがOktaPam Terraformプロバイダーを使ってクラスターを追加すると、チームは一意のOIDC認証URLを受信します。管理者はこのURLを使用して、ユーザー認証時のOkta Privileged Accessの使用をクラスターに強制します。Kubernetesのドキュメントを参照してください。
Minikubeクラスター
Kubernetesアクセス管理機能をminikubeクラスターでテストすることを予定しているのであれば、次の表は、minikubeの起動コマンドに渡す必要があるパラメーターの概要を示しています。
| Minikube起動引数 | |
|---|---|
| パラメーター | 説明 |
| apiserver.authorization-mode | クラスターでKubernetes RBACを有効にするには、これをRBACに設定します。 |
| apiserver.oidc-issuer-url | クラスターの作成時にOkta Privileged Accessが生成するOIDC URL。これは、Okta Privileged Accessダッシュボードの［Cluster Details（クラスター詳細）］ページで確認できます。 |
| apiserver.oidc-username-claim | ユーザー名を定義するJWTクレーム。 subを入力します。 |
| apiserver.oidc-groups-claim | グループを定義するJWTクレーム。この値は、Okta Privileged Accessクラスターグループに構成される1つ以上のグループクレームと一致する必要があります。これは、通常はグループに設定されます。 |
| apiserver.oidc-client-id | これは、kubernetesに設定します。 |
| minikube起動コマンドの例
minikube start \ --extra-config=apiserver.authorization-mode=Node,RBAC \ --extra-config=apiserver.oidc-issuer-url=\ https://app.scaleft.com/v1/teams/XXXXXX/kubernetes/clusters/XXXX-XXXX-XXXX-XXXX \ --extra-config=apiserver.oidc-username-claim=sub \ --extra-config=apiserver.oidc-client-id=kubernetes \ --extra-config=apiserver.oidc-groups-claim=groups |
|
AWS EKSクラスター
AWS EKSクラスターでは、Okta Privileged Accessを使ったクラスターの認証のために追加の構成が必要となります。次の表は、EKSクラスターの構成方法を示すシンプルな例を提供します。詳細については、EKSクラスター認証のドキュメントを参照してください。IDをEKSクラスターに関連付け、Okta Privileged Accessによる認証とアクセスを有効にする、eksctl CLIで使用するためのYAMLファイルの例を次に示します。
| EKSの構成 | |
|---|---|
| パラメーター | 説明 |
| IssuerUrl | ラベルクラスターは、K8sクラスターの照合に使用されます。 |
| ClientId | 既存のOkta Privileged Accessグループの判読可能な名前。値の大文字/小文字は区別されます。 |
| UsernameClaim | クラスター認証に使用されるユーザー資格情報が含まれるクレームのマップ。クラスターに事前に構成されるロールバインディングに対応するクレーム。 |
| GroupsClaim | グループを定義するJWTクレーム。この値は、Okta Privileged Access クラスターグループに構成される1つ以上のグループクレームと一致する必要があります。これは、通常はグループに設定されます。 |
| UsernamePrefix | 任意。競合を防止するためにユーザーアカウントの先頭に追加される文字列。 任意の説明的な文字列（例：ASAUser:）を入力します。 |
| GroupsPrefix | 任意。競合を防止するためにユーザーグループの先頭に追加される文字列。 任意の説明的な文字列（例：ASAGroup:）を入力します。 |
| アクセスIDプロバイダーファイルの例（eksctlで使用）
apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: eks-k8s-beta region: us-east-1 identityProviders: - name: okta-asa-k8s type: oidc issuerUrl: <ASA OIDC URL> clientId: kubernetes usernameClaim: sub groupsClaim: groups Example Cluster Role kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: ASA-readonly rules: - apiGroups: ["*"] resources: ["*"] verbs: ["get", "list"] Example Role Binding kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: ASA-readonly-binding roleRef: kind: ClusterRole name: ASA-readonly apiGroup: rbac.authorization.k8s.io subjects: - kind: Group name: ASAGroup:ExampleGroup apiGroup: rbac.authorization.k8s.io |
|