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 をアイデンティティープロバイダーとして使用するには、使用するアプリケーションを登録する必要があります。
手順
アプリケーションを GitHub で登録します。
-
GitHub の場合、Settings
Developer settings OAuth Apps Register a new OAuth application をクリックします。 -
GitHub Enterprise の場合は、GitHub Enterprise ホームページに移動してから Settings
Developer settings Register a new application をクリックします。
-
GitHub の場合、Settings
-
アプリケーション名を入力します (例:
My OpenShift Install
)。 -
ホームページ URL (例:
https://oauth-openshift.apps.<cluster-name>.<cluster-domain>
) を入力します。 - オプション: アプリケーションの説明を入力します。
認可コールバック 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
- 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 Enterprisehostname
値に一致する必要があり、ポート番号を含めることはできません。この値が設定されない場合、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 の組織設定で実行できます。
関連情報
-
すべてのアイデンティティープロバイダーに共通するパラメーターの詳細は、アイデンティティープロバイダーのパラメーター (
mappingMethod
など) について参照してください。
7.6.7. アイデンティティープロバイダーのクラスターへの追加
クラスターのインストール後に、アイデンティティープロバイダーをそのクラスターに追加し、ユーザーの認証を実行できるようにします。
前提条件
- OpenShift Container Platform クラスターを作成します。
- アイデンティティープロバイダーのカスタムリソース (CR) を作成します。
- 管理者としてログインしている必要があります。
手順
定義された 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
この場合は、この警告を無視しても問題ありません。OAuth サーバーからトークンを取得します。
kubeadmin
ユーザーが削除されている限り、oc login
コマンドは、トークンを取得できる Web ページにアクセスする方法についての情報を提供します。Web コンソールからこのページにアクセスするには、(?) Help
Command Line Tools Copy Login Commandに移動します。 認証するトークンを渡して、クラスターにログインします。
$ oc login --token=<token>
注記このアイデンティティープロバイダーは、ユーザー名とパスワードを使用してログインすることをサポートしません。
ユーザーが正常にログインされていることを確認し、ユーザー名を表示します。
$ oc whoami