LDAP を使用して GKE Identity Service を設定する

このドキュメントは、クラスタで GKE Identity Service を設定するクラスタ管理者またはアプリケーション オペレーターを対象としています。このドキュメントでは、Microsoft Active Directory などの Lightweight Directory Access Protocol（LDAP）プロバイダを使用して、クラスタに GKE Identity Service を設定する方法について説明します。お客様またはプラットフォーム管理者が GKE Identity Service に LDAP プロバイダを設定するの手順に沿って、LDAP プロバイダのログイン情報をすでに取得していることを前提としています。GKE Identity Service の仕組みと、ほかの設定手段については、概要をご覧ください。このサービスをデベロッパーや他のクラスタ ユーザーとして使用してクラスタにアクセスする方法については、GKE Identity Service を使用したクラスタにアクセスするをご覧ください。LDAP を使用する GKE Identity Service は、VMware 上の Google Distributed Cloud デプロイ（ユーザー クラスタ）とベアメタル上のデプロイでのみ使用できます。

始める前に

  1. 次のコマンドライン ツールがインストールされていることを確認します。
    • Google Cloud CLI の最新バージョン。Google Cloud とやり取りするためのコマンドライン ツールである gcloud が含まれています。Google Cloud CLI をインストールする必要がある場合は、インストール ガイドをご覧ください。
    • kubectl。Kubernetes クラスタにコマンドを実行するために使用します。kubectl をインストールする必要がある場合は、インストール ガイドをご覧ください。Google Cloud を操作するシェル環境として Cloud Shell を使用している場合は、これらのツールがインストールされています。
  2. プロジェクトで使用する gcloud CLI が初期化されていることを確認します。

この設定を実施している途中で、LDAP サーバーのドキュメントの参照が必要になることがあります。管理者向けの次のガイドには、広く利用されている一部の LDAP プロバイダの構成が説明されています。たとえば、LDAP サーバーへのログインとクラスタの構成に必要な情報を得る方法などが記載されています。

LDAP サービス アカウントの Secret を登録する

GKE Identity Service が LDAP サーバーを認証し、ユーザーの詳細情報を取得するには、サービス アカウントの Secret が必要です。LDAP 認証で許可されるサービス アカウントには、基本認証（ユーザー名とパスワードを使用してサーバーを認証）とクライアント証明書（クライアントの秘密鍵とクライアント証明書を使用）の 2 種類があります。お客様またはプラットフォーム管理者は、GKE Identity Service に LDAP プロバイダを設定するの手順に沿って、プロバイダに関するこの情報を取得している必要があります。GKE Identity Service で LDAP サーバーのログイン情報を使用できるようにするには、GKE Identity Service に LDAP プロバイダを設定するに記載されているログイン情報を使用して、Kubernetes Secret リソースを作成する必要があります。以下の例では、両方のサービス アカウント タイプの Secret を構成する方法を示します。上記の例では、Secret を anthos-identity-service Namespace に適用しています。

基本認証の Secret 構成は、次のようになります。

apiVersion: v1
kind: Secret
metadata:
  name: SERVICE_ACCOUNT_SECRET_NAME
  namespace: "anthos-identity-service"
type: kubernetes.io/basic-auth     # Make sure the type is correct
data:
  username: USERNAME  # Use a base64-encoded username
  password: PASSWORD  # Use a base64-encoded password

ここで、SERVICE_ACCOUNT_SECRET_NAME は、この Secret に付けた名前です。username と password の値は、前のステップで取得したユーザー名とパスワードに置き換えます。USERNAME は Base64 でエンコードされたユーザー名です。PASSWORD は Base64 でエンコードされたパスワードです。

クライアント証明書の Secret 構成は、次のようになります。

apiVersion: v1
kind: Secret
metadata:
  name: SERVICE_ACCOUNT_SECRET_NAME
  namespace: anthos-identity-service
type: kubernetes.io/tls            # Make sure the type is correct
data:
  # the data is abbreviated in this example
  tls.crt: |
       MIIC2DCCAcCgAwIBAgIBATANBgkqh ...
  tls.key: |
       MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ...

SERVICE_ACCOUNT_SECRET_NAME は、この Secret に付けた名前に置き換えます。TLS 証明書と鍵の値は、前のステップで取得しエンコードした証明書と鍵の値で置き換えます。

上記の例では、Secret を anthos-identity-service Namespace に適用しています。この方法をおすすめします。これは、GKE Identity Service がデフォルトで anthos-identity-service の Secret を読み取る権限を持っているためです。別の Namespace を使用する場合は、Secret のメタデータを変更してから、下のように、新しい RBAC ポリシーを追加して、その Namespace の Secret を読み取る権限を GKE Identity Service に付与します。

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: NAMESPACE
  name: ais-secret-reader-role
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get","list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ais-secret-reader-role-binding
  namespace: NAMESPACE
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: ais-secret-reader-role
subjects:
- kind: ServiceAccount
  name: default
  namespace: anthos-identity-service
---

クラスタを構成する

GKE Identity Service は、特別な Kubernetes のカスタム リソース タイプ（CRD）を使用して、ClientConfig と呼ばれるクラスタを構成します。この CRD には、ID プロバイダに関する情報のフィールドと、ユーザー情報を返すために必要なパラメータがあります。ClientConfig 構成には、前のセクションで作成して適用した Secret の名前と Namespace も含まれており、これにより GKE Identity Service で LDAP サーバーに対する認証を行えるようになります。

この構成をクラスタに適用するには、kube-public Namespace の clientconfig タイプの KRM デフォルト オブジェクトを編集します。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-public edit clientconfig default

USER_CLUSTER_KUBECONFIG は、クラスタの kubeconfig ファイルのパスに置き換えます。kubeconfig に複数のコンテキストがある場合は、現行のコンテキストが使用されます。コマンドを実行する前に、現在のコンテキストを正しいクラスタにリセットすることが必要になる場合があります。

ClientConfig 構成の形式は次のとおりです。

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  authentication:
    - name: NAME_STRING
      ldap:
        host: HOST_NAME
        certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
        connectionType: CONNECTION_TYPE
        serviceAccountSecret:
          name: SERVICE_ACCOUNT_SECRET_NAME
          namespace: NAMESPACE
          type: SECRET_FORMAT
        user:
          baseDN: BASE_DN
          filter: FILTER
          identifierAttribute: IDENTIFIER_ATTRIBUTE
          loginAttribute: LOGIN_ATTRIBUTE
        group:
          baseDN: BASE_DN
          filter: FILTER
          identifierAttribute: IDENTIFIER_ATTRIBUTE

ClientConfig CRD の各フィールドの説明を、次の表に示します。

フィールド 必須 説明 形式
name ○ この LDAP 構成を識別する名前 文字列
host ○ LDAP サーバーのホスト名または IP アドレス。ポートは省略可能であり、指定しない場合のデフォルトは 389 です。たとえば、ldap.server.example.com や、10.10.10.10:389 です。 文字列
certificateAuthorityData 特定の LDAP 接続タイプで必須 LDAP サーバー用の Base64 エンコードされた PEM 形式の認証局証明書が含まれます。これは、ldaps 接続と startTLS 接続に対してのみ指定する必要があります。 文字列
connectionType ○ LDAP サーバーへの接続時に使用する LDAP 接続タイプ。デフォルトは startTLS です。insecure モードはサーバーへのすべての通信が平文であるため、開発にのみ使用してください。 文字列
serviceAccountSecret
name ○ LDAP サービス アカウントの認証情報を格納する Kubernetes Secret の名前。 文字列
namespace ○ LDAP サービス アカウントの認証情報を格納する Kubernetes Secret の Namespace。 文字列
type ○ さまざまな種類のシークレットをサポートするために、サービス アカウント シークレットの形式を定義します。Secret 構成で basic-auth を指定した場合は、これを basic にする必要があります。それ以外の場合は、tls にする必要があります。指定されていない場合、デフォルトの basic が使用されます。 文字列
user
baseDN ○ ユーザー エントリを検索する LDAP ディレクトリ内のサブツリーの場所 文字列
filter × ユーザーの検索時に適用するオプションのフィルタこれにより、ログインできるユーザー アカウントをさらに制限できます。指定されていない場合、デフォルトの (objectClass=User) が使用されます。 文字列
identifierAttribute × 認証後にユーザーの ID として使用する属性を指定します。これは、ユーザーがユーザー名を使用してログインできるようにする loginAttribute フィールドとは別のものですが、実際の ID がメールアドレスか完全な識別名（DN）になります。たとえば、loginAttribute を sAMAccountName、identifierAttribute を userPrincipalName に設定すると、ユーザーは bsmith としてログインできるようになりますが、ユーザーの実際の RBAC ポリシーは bsmith@example.com として記述されます。ユーザーごとに一意になることから、userPrincipalName の使用をおすすめします。指定しない場合は、デフォルトの userPrincipalName が使用されます。 文字列
loginAttribute × 入力ユーザー名と照合する属性の名前。LDAP データベースでユーザーを検索するために使用されます（例: (<LoginAttribute>=<username>)）。また、オプションのフィルタ フィールドと組み合わせて使用されます。デフォルトは userPrincipalName です。 文字列
group（オプション フィールド）
baseDN ○ グループ エントリを検索する LDAP ディレクトリ内のサブツリーの場所 文字列
filter × ユーザーが所属するグループを検索するときに使用するフィルタ（省略可）。これを使用することで、特定のグループのみを明示的に照合して、各ユーザーから返されるグループの数を減らすことができます。デフォルトは (objectClass=Group) です。 文字列
identifierAttribute × ユーザーが所属する各グループの識別名。たとえば、これが distinguishedName に設定されている場合、RBAC やその他のグループの期待値は完全な DN として記述する必要があります。指定しない場合は、デフォルトの distinguishedName が使用されます。 文字列

次のステップ

構成が適用されたら、GKE Identity Service を使用してクラスタにユーザー アクセスを設定するに進む。