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 リポジトリーと連携できるようにするには、以下を実行します。

  1. GitHub OAuth アプリ (OAuth 2.0) をセットアップします。
  2. GitHub OAuth アプリケーションシークレットを適用します。
3.10.1.1.1. GitHub OAuth アプリケーションの設定

Set up a GitHub OAuth App using OAuth 2.0.

前提条件

  • GitHub にログインしている。

手順

  1. https://github.com/settings/applications/new にアクセスします。
  2. 以下の値を設定します。

    1. アプリケーション名: <application name>
    2. ホームページ URL: https://<openshift_dev_spaces_fqdn>/
    3. Authorization callback URL: https://<openshift_dev_spaces_fqdn>/api/oauth/callback
  3. Register application をクリックします。
  4. Generate new client secret をクリックします。
  5. GitHub OAuth アプリケーションシークレットを適用する際に使用するために GitHub OAuth クライアント ID をコピーして保存します。
  6. 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 セッション。CLI の使用開始を 参照してください。

手順

  1. 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 クライアントシークレット
  2. シークレットを適用します。

    $ oc apply -f - <<EOF
    <Secret_prepared_in_the_previous_step>
    EOF
  3. 出力に Secret が作成されたことを確認します。

別の GitHub プロバイダー用に OAuth 2.0 を設定するには、上記の手順を繰り返し、別の名前で 2 つ目の GitHub OAuth Secret を作成する必要があります。

3.10.1.2. GitLab の OAuth 2.0 の設定

ユーザーが GitLab インスタンスを使用してホストされるリモート Git リポジトリーと連携できるようにするには、以下を実行します。

  1. GitLab で承認されたアプリケーション (OAuth 2.0) をセットアップします。
  2. GitLab で承認されたアプリケーションシークレットを適用します。
3.10.1.2.1. GitLab で承認されたアプリケーションの設定

OAuth 2.0 を使用して GitLab で承認されたアプリケーションを設定します。

前提条件

  • GitLab にログインしている。

手順

  1. アバターをクリックして、プロファイル アプリケーション の編集に移動します。
  2. NameOpenShift Dev Spaces を入力します。
  3. Redirect URI として https://<openshift_dev_spaces_fqdn>/api/oauth/callback を入力します。
  4. Confidential および Expire access tokens のチェックボックスを選択します。
  5. Scopes の下で、apiwrite_repository、および openid のチェックボックスにチェックを入れます。
  6. Save application をクリックします。
  7. GitLab-authorized アプリケーションシークレットを適用する際に使用するために GitLab アプリケーション ID をコピーして保存します。
  8. GitLab-authorized アプリケーションシークレットを適用する際に使用するために GitLab クライアントシークレット をコピーして保存します。
3.10.1.2.2. GitLab で承認されるアプリケーションシークレットの適用

GitLab で承認されるアプリケーションシークレットを準備し、これを適用します。

前提条件

  • GitLab 認証アプリケーションの設定が完了します。
  • GitLab で承認されたアプリケーションのセットアップ時に生成された以下の値が用意されています。

    • GitLab Application ID
    • GitLab Client Secret
  • 宛先 OpenShift クラスターへの管理権限を持つアクティブな oc セッション。CLI の使用開始を 参照してください。

手順

  1. 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
    1
    OpenShift Dev Spaces namespace。デフォルトは openshift-devspaces です。
    2
    GitLab サーバーの URL です。SAAS バージョンには https://gitlab.com を使用します。
    3
    GitLab アプリケーション ID
    4
    GitLab クライアントシークレット
  2. シークレットを適用します。

    $ oc apply -f - <<EOF
    <Secret_prepared_in_the_previous_step>
    EOF
  3. 出力に Secret が作成されたことを確認します。

3.10.1.3. Bitbucket サーバーの OAuth 2.0 の設定

OAuth 2.0 を使用すると、ユーザーが Bitbucket Server でホストされているリモート Git リポジトリーを操作できるようになります。

  1. Bitbucket Server で OAuth 2.0 アプリケーションリンクをセットアップします。
  2. Bitbucket Server のアプリケーションリンクシークレットを適用します。

3.10.1.4. Bitbucket Cloud 向け OAuth 2.0 の設定

Bitbucket Cloud でホストされているリモート Git リポジトリーをユーザーが操作できるようにすることができます。

  1. Bitbucket Cloud で OAuth コンシューマー (OAuth 2.0) をセットアップします。
  2. Bitbucket Cloud に OAuth コンシューマーシークレットを適用します。
3.10.1.4.1. Bitbucket Cloud で OAuth コンシューマーを設定する

Bitbucket Cloud で OAuth 2.0 の OAuth コンシューマーをセットアップします。

前提条件

  • Bitbucket Cloud にログインしている。

手順

  1. アバターをクリックして、All workspaces ページに移動します。
  2. ワークスペースを選択してクリックします。
  3. Settings OAuth consumers Add consumer に移動します。
  4. NameOpenShift Dev Spaces を入力します。
  5. Callback URL として https://<openshift_dev_spaces_fqdn>/api/oauth/callback と入力します。
  6. Permissions で、AccountRepositories のすべてのチェックボックスをオンにして、Save をクリックします。
  7. 追加されたコンシューマーを展開し、Bitbucket OAuth コンシューマーシークレットを適用する際に使用するために キー 値をコピーして保存します。
  8. Bitbucket OAuth コンシューマーシークレットを適用する際に使用するために シークレット 値をコピーして保存します。
3.10.1.4.2. Bitbucket Cloud に OAuth コンシューマーシークレットを適用する

Bitbucket Cloud の OAuth コンシューマーシークレットを準備して適用します。

前提条件

  • OAuth コンシューマーは Bitbucket Cloud でセットアップされます。
  • Bitbucket OAuth コンシューマーのセットアップ時に生成された次の値が準備されています。

    • Bitbucket OAuth コンシューマーキー
    • Bitbucket OAuth コンシューマーシークレット
  • 宛先 OpenShift クラスターへの管理権限を持つアクティブな oc セッション。CLI の使用開始を 参照してください。

手順

  1. 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
    1
    OpenShift Dev Spaces namespace。デフォルトは openshift-devspaces です。
    2
    Bitbucket OAuth コンシューマーキー
    3
    Bitbucket OAuth コンシューマーシークレット
  2. シークレットを適用します。

    $ oc apply -f - <<EOF
    <Secret_prepared_in_the_previous_step>
    EOF
  3. 出力に Secret が作成されたことを確認します。

3.10.1.5. Bitbucket サーバー向け OAuth 1.0 の設定

ユーザーが Bitbucket サーバーでホストされるリモート Git リポジトリーと連携できるようにするには、以下を実行します。

  1. Bitbucket Server でアプリケーションリンク (OAuth 1.0) を設定します。
  2. Bitbucket Server のアプリケーションリンクシークレットを適用します。

3.10.1.6. Microsoft Azure DevOps サービス用の OAuth 2.0 の設定

ユーザーが Microsoft Azure Repos でホスティングされているリモート Git リポジトリーを操作できるようにするには:

  1. Microsoft Azure DevOps Services OAuth アプリケーション (OAuth 2.0) をセットアップします。
  2. 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 を参照してください。

    手順

    1. https://app.vsaex.visualstudio.com/app/register/ にアクセスしてください。
    2. 以下の値を設定します。

      1. 会社名: OpenShift Dev Spaces
      2. アプリケーション名: OpenShift Dev Spaces
      3. Application website: https://<openshift_dev_spaces_fqdn>/
      4. Authorization callback URL: https://<openshift_dev_spaces_fqdn>/api/oauth/callback
    3. Select Authorized scopes で、Code (read and write) を選択します。
    4. Create application をクリックします。
    5. Microsoft Azure DevOps Services OAuth アプリケーションシークレットを適用する際に使用するために アプリケーション ID をコピーして保存します。
    6. Show をクリックして、Client Secret を表示します。
    7. 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 セッション。CLI の使用開始を 参照してください。

手順

  1. 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
    1
    OpenShift Dev Spaces namespace。デフォルトは openshift-devspaces です。
    2
    Microsoft Azure DevOps Services OAuth アプリケーション ID
    3
    Microsoft Azure DevOps Services OAuth クライアントシークレット
  2. シークレットを適用します。

    $ oc apply -f - <<EOF
    <Secret_prepared_in_the_previous_step>
    EOF
  3. 出力に Secret が作成されたことを確認します。
  4. OpenShift Dev Spaces サーバーコンポーネントのロールアウトが完了するまで待ちます。

3.10.2. Dev Spaces ユーザーのクラスターロールの設定

OpenShift Dev Spaces ユーザーにクラスターロールを追加することで、より多くのクラスター権限を付与できます。

前提条件

  • 宛先 OpenShift クラスターへの管理権限を持つアクティブな oc セッション。CLI の使用開始を 参照してください。

手順

  1. ユーザーロール名を定義します。

    $ USER_ROLES=<name> 1
    1
    一意のリソース名。
  2. 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)
  3. 必要なロールを作成します。

    $ 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
    1
    <verbs> として、このルールに含まれるすべての ResourceKind および AttributeRestrictions に適用されるすべての動詞をリストします。* を使用してすべての動詞を表すことができます。
    2
    <apiGroups> として、リソースを含む APIGroups に名前を付けます。
    3
    <resources> として、このルールが適用されるすべてのリソースをリストします。* を使用してすべての動詞を表すことができます。
  4. ロールを 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
  5. ロールを che サービスアカウントに委譲するように OpenShift Dev Spaces Operator を設定します。

    $ kubectl patch checluster devspaces \
      --patch '{"spec": {"components": {"cheServer": {"clusterRoles": ["'${USER_ROLES}'"]}}}}' \
      --type=merge -n openshift-devspaces
  6. ロールをユーザーに委譲するように OpenShift Dev Spaces サーバーを設定します。

    $ kubectl patch checluster devspaces \
      --patch '{"spec": {"devEnvironments": {"user": {"clusterRoles": ["'${USER_ROLES}'"]}}}}' \
      --type=merge -n openshift-devspaces
  7. OpenShift Dev Spaces サーバーコンポーネントのロールアウトが完了するまで待ちます。
  8. ログアウトして、新しいロールを適用するようにユーザーに依頼します。

3.10.3. 高度な認証の設定

OpenShift Dev Spaces へのアクセスを許可するユーザーとグループを決定できます。

前提条件

  • 宛先 OpenShift クラスターへの管理権限を持つアクティブな oc セッション。CLI の使用開始を 参照してください。

手順

  1. CheCluster カスタムリソースを設定します。「CLI を使用して CheCluster カスタムリソースの設定」 を参照してください。

    spec:
      networking:
        auth:
          advancedAuthorization:
            allowUsers:
              - <allow_users> 1
            allowGroups:
              - <allow_groups> 2
            denyUsers:
              - <deny_users> 3
            denyGroups:
              - <deny_groups> 4
    1
    Red Hat OpenShift Dev Spaces へのアクセスが許可されているユーザーのリスト。
    2
    Red Hat OpenShift Dev Spaces へのアクセスが許可されているユーザーのグループのリスト (OpenShift Container Platform のみ)。
    3
    Red Hat OpenShift Dev Spaces へのアクセスを拒否されたユーザーのリスト。
    4
    Red Hat OpenShift Dev Spaces へのアクセスを拒否されたユーザーのグループのリスト (OpenShift Container Platform のみ)。
  2. OpenShift Dev Spaces サーバーコンポーネントのロールアウトが完了するまで待ちます。
注記

OpenShift Dev Spaces へのアクセスをユーザーに許可するには、そのユーザーを allowUsers リストに追加します。あるいは、ユーザーがメンバーとなっているグループを選択し、そのグループを allowGroups リストに追加します。OpenShift Dev Spaces へのユーザーのアクセスを拒否するには、そのユーザーを denyUsers リストに追加します。あるいは、ユーザーがメンバーとなっているグループを選択し、そのグループを denyGroups リストに追加します。ユーザーが allowdeny の両方のリストに登録されている場合は、OpenShift Dev Spaces へのアクセスは拒否されます。

allowUsersallowGroups が空の場合、deny リストにあるユーザーを除くすべてのユーザーが OpenShift Dev Spaces へのアクセスを許可されます。denyUsersdenyGroups が空の場合、allow リストのユーザーのみが OpenShift Dev Spaces へのアクセスを許可されます。

allowdeny リストの両方が空の場合、すべてのユーザーが OpenShift Dev Spaces にアクセスできます。

3.10.4. GDPR に準拠したユーザーデータの削除

個人データを消去する権利を個人に強制する General Data Protection Regulation (GDPR) に従って、OpenShift Container Platform 上のユーザーのデータを削除できます。他の Kubernetes インフラストラクチャーのプロセスは異なる場合があります。Red Hat OpenShift Dev Spaces のインストールに使用しているプロバイダーのユーザー管理のベストプラクティスに従ってください。

警告

次のようにユーザーデータを削除すると、元に戻すことはできません。削除されたデータはすべて削除され、復元できなくなります。

前提条件

手順

  1. 次のコマンドを使用して、OpenShift クラスター内のすべてのユーザーをリスト表示します。

    $ oc get users
  2. ユーザーエントリーを削除します。
重要

ユーザーに関連するリソース (プロジェクト、ロール、サービスアカウントなど) がある場合は、ユーザーを削除する前に、まずそれらを削除する必要があります。

$ oc delete user <username>
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.