4.6. GitHub または GitHub Enterprise アイデンティティープロバイダーの設定

github アイデンティティープロバイダーを、GitHub または GitHub Enterprise の OAuth 認証サーバーに対してユーザー名とパスワードを検証するように設定します。OAuth は OpenShift Container Platform と GitHub または GitHub Enterprise 間のトークン交換フローを容易にします。

GitHub 統合を使用して GitHub または GitHub Enterprise のいずれかに接続できます。GitHub Enterprise 統合の場合、インスタンスの hostname を指定する必要があり、サーバーへの要求で使用する ca 証明書バンドルをオプションで指定することができます。

注記

とくに記述がない限り、以下の手順が GitHub および GitHub Enterprise の両方に適用されます。

GitHub 認証を設定することによって、ユーザーは GitHub 認証情報を使用して OpenShift Container Platform にログインできます。GitHub ユーザー ID を持つすべてのユーザーが OpenShift Container Platform クラスターにログインできないようにするために、アクセスを特定の GitHub 組織のユーザーに制限することができます。

4.6.1. OpenShift Container Platform のアイデンティティープロバイダーについて

デフォルトでは、kubeadmin ユーザーのみがクラスターに存在します。アイデンティティープロバイダーを指定するには、アイデンティティープロバイダーを記述し、これをクラスターに追加するカスタムリソース (CR、Custom Resource) を作成する必要があります。

注記

/、:、および % を含む OpenShift Container Platform ユーザー名はサポートされません。

4.6.2. GitHub アプリケーションの登録

GitHub または GitHub Enterprise をアイデンティティープロバイダーとして使用するには、使用するアプリケーションを登録する必要があります。

手順

  1. アプリケーションを GitHub で登録します。

    • GitHub の場合、「Settings」 → 「Developer settings」 → 「OAuth Apps」 → 「Register a new OAuth application」をクリックします。
    • GitHub Enterprise の場合は、GitHub Enterprise ホームページに移動してから 「Settings」 → 「Developer settings」 → 「Register a new application」 をクリックします。
  2. アプリケーション名を入力します (例: My OpenShift Install)。
  3. ホームページ URL (例: https://oauth-openshift.apps.<cluster-name>.<cluster-domain>) を入力します。
  4. オプション: アプリケーションの説明を入力します。

  5. 認可コールバック URL を入力します。 ここで、URL の終わりにはアイデンティティープロバイダーの name が含まれます。 

    https://oauth-openshift.apps.<cluster-name>.<cluster-domain>/oauth2callback/<idp-provider-name>

    以下は例になります。 

    https://oauth-openshift.apps.example-openshift-cluster.com/oauth2callback/github/
  6. Register application をクリックします。GitHub はクライアント ID とクライアントシークレットを提供します。これらの値は、アイデンティティープロバイダーの設定を完了するために必要です。

4.6.3. シークレットの作成

アイデンティティープロバイダーは openshift-config namespace で OpenShift Container Platform シークレットを使用して、クライアントシークレット、クライアント証明書およびキーをこれに組み込みます。

  • 以下のコマンドを使用して、OpenShift Container Platform シークレットを定義できます。 

    $ oc create secret generic <secret_name> --from-literal=clientSecret=<secret> -n openshift-config

  • 以下のコマンドを実行して、証明書ファイルなどのファイルの内容を含む OpenShift Container Platform シークレットを定義できます。 

    $ oc create secret generic <secret_name> --from-file=/path/to/file -n openshift-config

4.6.4. ConfigMap の作成

アイデンティティープロバイダーは、openshift-config namespace で OpenShift Container Platform ConfigMap を使用し、認証局バンドルをこれに組み込みます。これらは、主にアイデンティティープロバイダーで必要な証明書バンドルを組み込むために使用されます。

  • 以下のコマンドを使用して、認証局が含まれる OpenShift Container Platform ConfigMap を定義します。認証局は ConfigMap の ca.crt キーに保存する必要があります。 

    $ oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n openshift-config

4.6.5. GitHub CR のサンプル

以下のカスタムリソース (CR) は、GitHub アイデンティティープロバイダーのパラメーターおよび許可される値を示します。

GitHub CR

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: githubidp 1
    mappingMethod: claim 2
    type: GitHub
    github:
      ca: 3
        name: ca-config-map
      clientID: {...} 4
      clientSecret: 5
        name: github-secret
      hostname: ... 6
      organizations: 7
      - myorganization1
      - myorganization2
      teams: 8
      - myorganization1/team-a
      - myorganization2/team-b

1
このプロバイダー名は GitHub の数字ユーザー ID にプレフィックスとして付加され、アイデンティティー名が作成されます。これはコールバック URL を作成するためにも使用されます。
2
このプロバイダーのアイデンティティーとユーザーオブジェクト間にマッピングが確立される方法を制御します。
3
オプション: 設定済みの URL のサーバー証明書を検証するために使用する PEM エンコードされた認証局バンドルを含む OpenShift Container Platform ConfigMap への参照。非公開で信頼されているルート証明書で GitHub Enterprise の場合のみ使用されます。
4
登録済みの GitHub OAuth アプリケーションのクライアント ID。アプリケーションは、https://oauth-openshift.apps.<cluster-name>.<cluster-domain>/oauth2callback/<idp-provider-name> のコールバック URL を使用して設定する必要があります。
5
GitHub で発行されるクライアントシークレットが含まれる OpenShift Container Platform シークレットへの参照。
6
GitHub Enterprise の場合、example.com などのインスタンスのホスト名を指定する必要があります。この値は /setup/settings ファイルにある GitHub Enterprise hostname 値に一致する必要があり、ポート番号を含めることはできません。この値が設定されない場合、 teams または organizations のいずれかが定義される必要があります。GitHub の場合は、このパラメーターを省略します。
7
組織のオプションの一覧です。これが指定されている場合、少なくとも一覧のいずれかの組織のメンバーである GitHub ユーザーのみがログインできます。その組織が clientID で設定された GitHub OAuth アプリケーションを所有していない場合、組織の所有者はこのオプションを使用するためにサードパーティーのアクセスを付与する必要があります。これは組織の管理者が初回の GitHub ログイン時に、または GitHub の組織設定で実行できます。これは teams フィールドと組み合わせて使用することはできません。
8
チームのオプションの一覧です。これが指定されている場合、少なくとも一覧のいずれかのチームのメンバーである GitHub ユーザーのみがログインできます。そのチームの組織が clientID で設定された GitHub OAuth アプリケーションを所有していない場合、組織の所有者はこのオプションを使用するためにサードパーティーのアクセスを付与する必要があります。これは組織の管理者が初回の GitHub ログイン時に、または GitHub の組織設定で実行できます。これは organizations フィールドと組み合わせて使用することはできません。

4.6.6. アイデンティティープロバイダーのクラスターへの追加

クラスターのインストール後に、アイデンティティープロバイダーをそのクラスターに追加し、ユーザーの認証を実行できるようにします。

前提条件

  • OpenShift Container Platform クラスターを作成します。
  • アイデンティティープロバイダーのカスタムリソース (CR) を作成します。
  • 管理者としてログインしている必要があります。

手順

  1. 定義された CR を適用します。 

    $ oc apply -f </path/to/CR>
    注記

    CR が存在しない場合、oc apply は新規 CR を作成し、さらに以下の警告をトリガーする可能性があります。Warning: oc apply should be used on resources created by either oc create --save-config or oc applyこの場合は、この警告を無視しても問題ありません。

  2. OAuth サーバーからトークンを取得します。

    kubeadmin ユーザーが削除されている限り、 oc login コマンドは、トークンを取得できる Web ページにアクセスする方法についての情報を提供します。

    Web コンソールからこのページにアクセスするには、(?) Help → Command Line Tools → Copy Login Commandに移動します。

  3. 認証するトークンを渡して、クラスターにログインします。 

    $ oc login --token=<token>
    注記

    このアイデンティティープロバイダーは、ユーザー名とパスワードを使用してログインすることをサポートしません。

  4. ユーザーが正常にログインされていることを確認し、ユーザー名を表示します。 

    $ oc whoami