7.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 の両方に適用されます。

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

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

注記

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

7.6.2. GitHub 認証について

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

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

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

手順

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

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

7.6.4. シークレットの作成

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

手順

  • 以下のコマンドを使用して、文字列を含む Secret オブジェクトを作成します。 

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

    または、以下の YAML を適用してシークレットを作成できます。 

    apiVersion: v1
kind: Secret
metadata:
  name: <secret_name>
  namespace: openshift-config
type: Opaque
data:
  clientSecret: <base64_encoded_client_secret>

  • 以下のコマンドを実行して、証明書ファイルなどのファイルの内容を含む Secret オブジェクトを定義できます。 

    $ oc create secret generic <secret_name> --from-file=<path_to_file> -n openshift-config

7.6.5. 設定マップの作成

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

注記

この手順は、GitHub Enterprise にのみ必要です。

手順

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

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

    または、以下の YAML を適用して設定マップを作成できます。 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: ca-config-map
  namespace: openshift-config
data:
  ca.crt: |
    <CA_certificate_PEM>

7.6.6. 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
このプロバイダーのアイデンティティーと User オブジェクト間にマッピングが確立される方法を制御します。
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 Secret オブジェクトへの参照。
6
GitHub Enterprise の場合、example.com などのインスタンスのホスト名を指定する必要があります。この値は /setup/settings ファイルにある GitHub Enterprise hostname 値に一致する必要があり、ポート番号を含めることはできません。この値が設定されない場合、teams または organizations のいずれかが定義される必要があります。GitHub の場合は、このパラメーターを省略します。
7
組織の一覧です。hostname フィールドが設定されていないか、または mappingMethod が lookup に設定されている場合は organizations または teams フィールドを設定する必要があります。これは teams フィールドと組み合わせて使用することはできません。
8
チームの一覧です。hostname フィールドが設定されていないか、または mappingMethod が lookup に設定されている場合は teams または organizations フィールドのいずれかを設定する必要があります。これは organizations フィールドと組み合わせて使用することはできません。
注記

organizations または teams が指定されている場合、少なくとも一覧のいずれかの組織のメンバーである GitHub ユーザーのみがログインできます。その組織が clientID で設定された GitHub OAuth アプリケーションを所有していない場合、組織の所有者はこのオプションを使用するためにサードパーティーのアクセスを付与する必要があります。これは組織の管理者が初回の GitHub ログイン時に、または GitHub の組織設定で実行できます。

関連情報

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

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

前提条件

  • 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