3.10. ID および承認の管理
このセクションでは、Red Hat OpenShift Dev Spaces の ID および承認の管理のさまざまな側面について説明します。
3.10.1. Git プロバイダーの OAuth の設定
OpenShift Dev Spaces と Git プロバイダーの間で OAuth を設定して、ユーザーがリモート Git リポジトリーを操作できるようにすることができます。
3.10.1.1. Configuring OAuth 2.0 for GitHub
ユーザーが GitHub でホストされるリモート Git リポジトリーと連携できるようにするには、以下を実行します。
- GitHub OAuth アプリ (OAuth 2.0) をセットアップします。
- GitHub OAuth アプリケーションシークレットを適用します。
3.10.1.1.1. GitHub OAuth アプリケーションの設定
Set up a GitHub OAuth App using OAuth 2.0.
前提条件
- GitHub にログインしている。
手順
- https://github.com/settings/applications/new にアクセスします。
以下の値を設定します。
-
アプリケーション名:
<application name>
-
ホームページ URL:
https://<openshift_dev_spaces_fqdn>/
-
Authorization callback URL:
https://<openshift_dev_spaces_fqdn>/api/oauth/callback
-
アプリケーション名:
- Register application をクリックします。
- Generate new client secret をクリックします。
- GitHub OAuth アプリケーションシークレットを適用する際に使用するために GitHub OAuth クライアント ID をコピーして保存します。
- GitHub OAuth アプリケーションシークレットを適用する際に使用するために GitHub OAuth クライアントシークレット をコピーして保存します。
3.10.1.1.2. GitHub OAuth アプリケーションシークレットの適用
GitHub OAuth App Secret を準備し、これを適用します。
前提条件
- GitHub OAuth アプリケーションのセットアップが完了します。
GitHub OAuth アプリケーションのセットアップ時に生成された以下の値が用意されています。
- GitHub OAuth Client ID
- GitHub OAuth Client Secret
-
宛先 OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。Getting started with the CLI を参照してください。
手順
Secret を準備します。
kind: Secret apiVersion: v1 metadata: name: github-oauth-config namespace: openshift-devspaces 1 labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: oauth-scm-configuration annotations: che.eclipse.org/oauth-scm-server: github che.eclipse.org/scm-server-endpoint: <github_server_url> 2 che.eclipse.org/scm-github-disable-subdomain-isolation: true 3 type: Opaque stringData: id: <GitHub_OAuth_Client_ID> 4 secret: <GitHub_OAuth_Client_Secret> 5
- 1
- OpenShift Dev Spaces namespace。デフォルトは
openshift-devspaces
です。 - 2
- これは、組織が使用している GitHub 製品によって異なります。GitHub.com または GitHub Enterprise Cloud でリポジトリーをホストする場合は、この行を省略するか、デフォルトの
https://github.com
を入力します。GitHub Enterprise Server でリポジトリーをホストする場合は、GitHub Enterprise Server の URL を入力します。 - 3
- この行は、サブドメイン分離 オプションが無効になっている GitHub Enterprise Server にのみ追加されます。GitHub Enterprise Server でサブドメイン分離オプションが有効になっている場合は、このアノテーションを省略するか、
false
に設定する必要があります。 - 4
- GitHub OAuth クライアント ID。
- 5
- GitHub OAuth クライアントシークレット。
シークレットを適用します。
$ oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
- 出力に Secret が作成されたことを確認します。
別の GitHub プロバイダー用に OAuth 2.0 を設定するには、上記の手順を繰り返し、別の名前で 2 つ目の GitHub OAuth Secret を作成する必要があります。
3.10.1.2. GitLab の OAuth 2.0 の設定
ユーザーが GitLab インスタンスを使用してホストされるリモート Git リポジトリーと連携できるようにするには、以下を実行します。
- GitLab で承認されたアプリケーション (OAuth 2.0) をセットアップします。
- GitLab で承認されたアプリケーションシークレットを適用します。
3.10.1.2.1. GitLab で承認されたアプリケーションの設定
OAuth 2.0 を使用して GitLab で承認されたアプリケーションを設定します。
前提条件
- GitLab にログインしている。
手順
-
アバターをクリックして、
の編集に移動します。 - Name に OpenShift Dev Spaces を入力します。
-
Redirect URI として
https://<openshift_dev_spaces_fqdn>/api/oauth/callback
を入力します。 - Confidential および Expire access tokens のチェックボックスを選択します。
-
Scopes の下で、
api
、write_repository
、およびopenid
のチェックボックスにチェックを入れます。 - Save application をクリックします。
- GitLab-authorized アプリケーションシークレットを適用する際に使用するために GitLab アプリケーション ID をコピーして保存します。
- GitLab-authorized アプリケーションシークレットを適用する際に使用するために GitLab クライアントシークレット をコピーして保存します。
3.10.1.2.2. GitLab で承認されるアプリケーションシークレットの適用
GitLab で承認されるアプリケーションシークレットを準備し、これを適用します。
前提条件
- GitLab 認証アプリケーションの設定が完了します。
GitLab で承認されたアプリケーションのセットアップ時に生成された以下の値が用意されています。
- GitLab Application ID
- GitLab Client Secret
-
宛先 OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。Getting started with the CLI を参照してください。
手順
Secret を準備します。
kind: Secret apiVersion: v1 metadata: name: gitlab-oauth-config namespace: openshift-devspaces 1 labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: oauth-scm-configuration annotations: che.eclipse.org/oauth-scm-server: gitlab che.eclipse.org/scm-server-endpoint: <gitlab_server_url> 2 type: Opaque stringData: id: <GitLab_Application_ID> 3 secret: <GitLab_Client_Secret> 4
シークレットを適用します。
$ oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
- 出力に Secret が作成されたことを確認します。
3.10.1.3. Bitbucket サーバーの OAuth 2.0 の設定
OAuth 2.0 を使用すると、ユーザーが Bitbucket Server でホストされているリモート Git リポジトリーを操作できるようになります。
- Bitbucket Server で OAuth 2.0 アプリケーションリンクをセットアップします。
- Bitbucket Server のアプリケーションリンクシークレットを適用します。
3.10.1.3.1. Bitbucket Server での OAuth 2.0 アプリケーションリンクのセットアップ
Bitbucket Server で OAuth 2.0 アプリケーションリンクをセットアップします。
前提条件
- Bitbucket Server にログインしている。
手順
- Administration > Applications > Application links に移動します。
- Creae List を選択します。
- External application および Incoming を選択します。
-
Redirect URL フィールドに
https://<openshift_dev_spaces_fqdn>/api/oauth/callback
を入力します。 - Application permissions で Admin - Write チェックボックスを選択します。
- Save をクリックします。
- Bitbucket アプリケーションリンクのシークレットを適用する際に使用するために クライアント ID をコピーして保存します。
- Bitbucket アプリケーションリンクのシークレットを適用する際に使用するために、クライアントシークレット をコピーして保存します。
3.10.1.3.2. Bitbucket Server の OAuth 2.0 アプリケーションリンクシークレットの適用
Bitbucket Server の OAuth 2.0 アプリケーションリンクシークレットを準備して適用します。
前提条件
- アプリケーションリンクが Bitbucket Server にセットアップされている。
Bitbucket アプリケーションリンクのセットアップ時に生成された以下の値が用意されています。
- Bitbucket Client ID
- Bitbucket Client secret
-
宛先 OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。Getting started with the CLI を参照してください。
手順
Secret を準備します。
kind: Secret apiVersion: v1 metadata: name: bitbucket-oauth-config namespace: openshift-devspaces 1 labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: oauth-scm-configuration annotations: che.eclipse.org/oauth-scm-server: bitbucket che.eclipse.org/scm-server-endpoint: <bitbucket_server_url> 2 type: Opaque stringData: id: <Bitbucket_Client_ID> 3 secret: <Bitbucket_Client_Secret> 4
シークレットを適用します。
$ oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
- 出力に Secret が作成されたことを確認します。
3.10.1.4. Bitbucket Cloud 向け OAuth 2.0 の設定
Bitbucket Cloud でホストされているリモート Git リポジトリーをユーザーが操作できるようにすることができます。
- Bitbucket Cloud で OAuth コンシューマー (OAuth 2.0) をセットアップします。
- Bitbucket Cloud に OAuth コンシューマーシークレットを適用します。
3.10.1.4.1. Bitbucket Cloud で OAuth コンシューマーを設定する
Bitbucket Cloud で OAuth 2.0 の OAuth コンシューマーをセットアップします。
前提条件
- Bitbucket Cloud にログインしている。
手順
- アバターをクリックして、All workspaces ページに移動します。
- ワークスペースを選択してクリックします。
-
に移動します。 - Name に OpenShift Dev Spaces を入力します。
-
Callback URL として
https://<openshift_dev_spaces_fqdn>/api/oauth/callback
と入力します。 - Permissions で、Account と Repositories のすべてのチェックボックスをオンにして、Save をクリックします。
- 追加されたコンシューマーを展開し、Bitbucket OAuth コンシューマーシークレットを適用する際に使用するために キー 値をコピーして保存します。
- Bitbucket OAuth コンシューマーシークレットを適用する際に使用するために シークレット 値をコピーして保存します。
3.10.1.4.2. Bitbucket Cloud に OAuth コンシューマーシークレットを適用する
Bitbucket Cloud の OAuth コンシューマーシークレットを準備して適用します。
前提条件
- OAuth コンシューマーは Bitbucket Cloud でセットアップされます。
Bitbucket OAuth コンシューマーのセットアップ時に生成された次の値が準備されています。
- Bitbucket OAuth コンシューマーキー
- Bitbucket OAuth コンシューマーシークレット
-
宛先 OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。Getting started with the CLI を参照してください。
手順
Secret を準備します。
kind: Secret apiVersion: v1 metadata: name: bitbucket-oauth-config namespace: openshift-devspaces 1 labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: oauth-scm-configuration annotations: che.eclipse.org/oauth-scm-server: bitbucket type: Opaque stringData: id: <Bitbucket_Oauth_Consumer_Key> 2 secret: <Bitbucket_Oauth_Consumer_Secret> 3
シークレットを適用します。
$ oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
- 出力に Secret が作成されたことを確認します。
3.10.1.5. Bitbucket サーバー向け OAuth 1.0 の設定
ユーザーが Bitbucket サーバーでホストされるリモート Git リポジトリーと連携できるようにするには、以下を実行します。
- Bitbucket Server でアプリケーションリンク (OAuth 1.0) を設定します。
- Bitbucket Server のアプリケーションリンクシークレットを適用します。
3.10.1.5.1. Bitbucket Server でのアプリケーションリンクの設定
Bitbucket Server で OAuth 1.0 のアプリケーションリンクをセットアップします。
前提条件
- Bitbucket Server にログインしている。
-
openssl
は、使用しているオペレーティングシステムにインストールされている。
手順
コマンドラインでコマンドを実行して、次の手順に必要なファイルを作成し、アプリケーションリンクシークレットを適用するときに使用します。
$ openssl genrsa -out private.pem 2048 && \ openssl pkcs8 -topk8 -inform pem -outform pem -nocrypt -in private.pem -out privatepkcs8.pem && \ cat privatepkcs8.pem | sed 's/-----BEGIN PRIVATE KEY-----//g' | sed 's/-----END PRIVATE KEY-----//g' | tr -d '\n' > privatepkcs8-stripped.pem && \ openssl rsa -in private.pem -pubout > public.pub && \ cat public.pub | sed 's/-----BEGIN PUBLIC KEY-----//g' | sed 's/-----END PUBLIC KEY-----//g' | tr -d '\n' > public-stripped.pub && \ openssl rand -base64 24 > bitbucket-consumer-key && \ openssl rand -base64 24 > bitbucket-shared-secret
-
に移動します。 -
URL フィールドに
https://<openshift_dev_spaces_fqdn>/
と入力し、Create new link をクリックします。 - 提供されたアプリケーション URL が一度リダイレクトされました で、この URL を使用する チェックボックスをオンにして、続行 をクリックします。
- Application Name に OpenShift Dev Spaces を入力します。
- Application Type として Generic Application を選択します。
- OpenShift Dev Spaces を Service Provider Name として入力します。
-
bitbucket-consumer-key
ファイルの内容を Consumer キー として貼り付けます。 -
bitbucket-shared-secret
ファイルの内容を Shared シークレット として貼り付けます。 -
リクエストトークンの URL として
<bitbucket_server_url>/plugins/servlet/oauth/request-token
と入力します。 -
アクセストークンの URL として
<bitbucket_server_url>/plugins/servlet/oauth/access-token
と入力します。 -
Authorize URL として
<bitbucket_server_url>/plugins/servlet/oauth/authorize
と入力します。 - 受信リンクの作成 チェックボックスをオンにして、続行 をクリックします。
-
bitbucket-consumer-key
ファイルの内容を Consumer Key として貼り付けます。 - コンシューマー名 として OpenShift Dev Spaces を入力します。
-
public-stripped.pub
ファイルの内容を 公開鍵 として貼り付け、Continue をクリックします。
3.10.1.5.2. Bitbucket Server 用にアプリケーションリンクシークレットを適用する
Bitbucket Server のアプリケーションリンクシークレットを準備して適用します。
前提条件
- アプリケーションリンクが Bitbucket Server にセットアップされている。
アプリケーション連携の設定時に作成された以下のファイルが用意されています。
-
privatepkcs8-stripped.pem
-
bitbucket-consumer-key
-
bitbucket-shared-secret
-
-
宛先 OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。Getting started with the CLI を参照してください。
手順
Secret を準備します。
kind: Secret apiVersion: v1 metadata: name: bitbucket-oauth-config namespace: openshift-devspaces 1 labels: app.kubernetes.io/component: oauth-scm-configuration app.kubernetes.io/part-of: che.eclipse.org annotations: che.eclipse.org/oauth-scm-server: bitbucket che.eclipse.org/scm-server-endpoint: <bitbucket_server_url> 2 type: Opaque stringData: private.key: <Content_of_privatepkcs8-stripped.pem> 3 consumer.key: <Content_of_bitbucket-consumer-key> 4 shared_secret: <Content_of_bitbucket-shared-secret> 5
シークレットを適用します。
$ oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
- 出力に Secret が作成されたことを確認します。
3.10.1.6. Microsoft Azure DevOps サービス用の OAuth 2.0 の設定
ユーザーが Microsoft Azure Repos でホスティングされているリモート Git リポジトリーを操作できるようにするには:
- Microsoft Azure DevOps Services OAuth アプリケーション (OAuth 2.0) をセットアップします。
- Microsoft Azure DevOps Services OAuth アプリケーションシークレットを適用します。
3.10.1.6.1. Microsoft Azure DevOps Services OAuth アプリケーションのセットアップ
OAuth 2.0 を使用して、Microsoft Azure DevOps Services OAuth アプリケーションをセットアップします。
前提条件
Microsoft Azure DevOps Services にログインしています。
重要Third-party application access via OAuth
が、組織で有効になっています。Change application connection & security policies for your organization を参照してください。手順
- https://app.vsaex.visualstudio.com/app/register/ にアクセスしてください。
以下の値を設定します。
-
会社名:
OpenShift Dev Spaces
-
アプリケーション名:
OpenShift Dev Spaces
-
Application website:
https://<openshift_dev_spaces_fqdn>/
-
Authorization callback URL:
https://<openshift_dev_spaces_fqdn>/api/oauth/callback
-
会社名:
- Select Authorized scopes で、Code (read and write) を選択します。
- Create application をクリックします。
- Microsoft Azure DevOps Services OAuth アプリケーションシークレットを適用する際に使用するために アプリケーション ID をコピーして保存します。
- Show をクリックして、Client Secret を表示します。
- Microsoft Azure DevOps Services OAuth アプリケーションシークレットを適用する際に使用するために クライアントシークレット をコピーして保存します。
3.10.1.6.2. Microsoft Azure DevOps Services OAuth アプリケーションシークレットの適用
Microsoft Azure DevOps Services シークレットを準備および適用します。
前提条件
- Microsoft Azure DevOps Services OAuth アプリケーションのセットアップが完了しました。
Microsoft Azure DevOps Services OAuth アプリの設定時に生成された次の値が用意されています。
- アプリケーション ID
- Client Secret
-
宛先 OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。Getting started with the CLI を参照してください。
手順
Secret を準備します。
kind: Secret apiVersion: v1 metadata: name: azure-devops-oauth-config namespace: openshift-devspaces1 labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: oauth-scm-configuration annotations: che.eclipse.org/oauth-scm-server: azure-devops type: Opaque stringData: id: <Microsoft_Azure_DevOps_Services_OAuth_App_ID>2 secret: <Microsoft_Azure_DevOps_Services_OAuth_Client_Secret>3
シークレットを適用します。
$ oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
- 出力に Secret が作成されたことを確認します。
- OpenShift Dev Spaces サーバーコンポーネントのロールアウトが完了するまで待ちます。
3.10.2. Dev Spaces ユーザーのクラスターロールの設定
OpenShift Dev Spaces ユーザーにクラスターロールを追加することで、より多くのクラスター権限を付与できます。
前提条件
-
宛先 OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。Getting started with the CLI を参照してください。
手順
ユーザーロール名を定義します。
$ USER_ROLES=<name> 1
- 1
- 一意のリソース名。
OpenShift Dev Spaces Operator がデプロイされている namespace を見つけます。
$ OPERATOR_NAMESPACE=$(oc get pods -l app.kubernetes.io/component=devspaces-operator -o jsonpath={".items[0].metadata.namespace"} --all-namespaces)
必要なロールを作成します。
$ kubectl apply -f - <<EOF kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: ${USER_ROLES} labels: app.kubernetes.io/part-of: che.eclipse.org rules: - verbs: - <verbs> 1 apiGroups: - <apiGroups> 2 resources: - <resources> 3 EOF
ロールを OpenShift Dev Spaces Operator に委譲します。
$ kubectl apply -f - <<EOF kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: ${USER_ROLES} labels: app.kubernetes.io/part-of: che.eclipse.org subjects: - kind: ServiceAccount name: devspaces-operator namespace: ${OPERATOR_NAMESPACE} roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: ${USER_ROLES} EOF
ロールを
che
サービスアカウントに委譲するように OpenShift Dev Spaces Operator を設定します。$ kubectl patch checluster devspaces \ --patch '{"spec": {"components": {"cheServer": {"clusterRoles": ["'${USER_ROLES}'"]}}}}' \ --type=merge -n openshift-devspaces
ロールをユーザーに委譲するように OpenShift Dev Spaces サーバーを設定します。
$ kubectl patch checluster devspaces \ --patch '{"spec": {"devEnvironments": {"user": {"clusterRoles": ["'${USER_ROLES}'"]}}}}' \ --type=merge -n openshift-devspaces
- OpenShift Dev Spaces サーバーコンポーネントのロールアウトが完了するまで待ちます。
- ログアウトして、新しいロールを適用するようにユーザーに依頼します。
3.10.3. 高度な認証の設定
OpenShift Dev Spaces へのアクセスを許可するユーザーとグループを決定できます。
前提条件
-
宛先 OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。Getting started with the CLI を参照してください。
手順
CheCluster
カスタムリソースを設定します。「CLI を使用して CheCluster カスタムリソースの設定」 を参照してください。spec: networking: auth: advancedAuthorization: allowUsers: - <allow_users> 1 allowGroups: - <allow_groups> 2 denyUsers: - <deny_users> 3 denyGroups: - <deny_groups> 4
- OpenShift Dev Spaces サーバーコンポーネントのロールアウトが完了するまで待ちます。
OpenShift Dev Spaces へのアクセスをユーザーに許可するには、そのユーザーを allowUsers
リストに追加します。あるいは、ユーザーがメンバーとなっているグループを選択し、そのグループを allowGroups
リストに追加します。OpenShift Dev Spaces へのユーザーのアクセスを拒否するには、そのユーザーを denyUsers
リストに追加します。あるいは、ユーザーがメンバーとなっているグループを選択し、そのグループを denyGroups
リストに追加します。ユーザーが allow
と deny
の両方のリストに登録されている場合は、OpenShift Dev Spaces へのアクセスは拒否されます。
allowUsers
と allowGroups
が空の場合、deny
リストにあるユーザーを除くすべてのユーザーが OpenShift Dev Spaces へのアクセスを許可されます。denyUsers
と denyGroups
が空の場合、allow
リストのユーザーのみが OpenShift Dev Spaces へのアクセスを許可されます。
allow
と deny
リストの両方が空の場合、すべてのユーザーが OpenShift Dev Spaces にアクセスできます。
3.10.4. GDPR に準拠したユーザーデータの削除
個人データを消去する権利を個人に強制する General Data Protection Regulation (GDPR) に従って、OpenShift Container Platform 上のユーザーのデータを削除できます。他の Kubernetes インフラストラクチャーのプロセスは異なる場合があります。Red Hat OpenShift Dev Spaces のインストールに使用しているプロバイダーのユーザー管理のベストプラクティスに従ってください。
次のようにユーザーデータを削除すると、元に戻すことはできません。削除されたデータはすべて削除され、復元できなくなります。
前提条件
-
OpenShift Container Platform クラスターの管理権限を持つアクティブな
oc
セッション。Getting started with the OpenShift CLI を参照してください。
手順
次のコマンドを使用して、OpenShift クラスター内のすべてのユーザーをリスト表示します。
$ oc get users
- ユーザーエントリーを削除します。
ユーザーに関連するリソース (プロジェクト、ロール、サービスアカウントなど) がある場合は、ユーザーを削除する前に、まずそれらを削除する必要があります。
$ oc delete user <username>