第6章 ワークスペースでのクレデンシャルと設定の使用


ワークスペースでクレデンシャルと設定を使用できます。

これを行うには、組織の OpenShift Dev Spaces インスタンスの OpenShift クラスター内の Dev Workspace コンテナーにクレデンシャルと設定をマウントします。

  • クレデンシャルと機密性の高い設定を Kubernetes シークレット としてマウントします。
  • 機密性のない設定を Kubernetes ConfigMaps としてマウントします。

クラスター内の Dev Workspace Pod が認証を必要とするコンテナーレジストリーにアクセスできるようにする必要がある場合は、Dev Workspace Pod の イメージプルシークレット を作成します。

マウントプロセスでは、標準の Kubernetes マウントメカニズムを使用し、既存のリソースに追加のラベルとアノテーションを適用する必要があります。新しいワークスペースを開始するとき、または既存のワークスペースを再起動するときに、リソースがマウントされます。

さまざまなコンポーネントの永続的なマウントポイントを作成できます。

6.1. シークレットのマウント

機密データをワークスペースにマウントするには、Kubernetes シークレットを使用します。

Kubernetes Secrets を使用すると、ユーザー名、パスワード、SSH キーペア、認証トークン (AWS など)、および機密性の高い設定をマウントできます。

組織の OpenShift Dev Spaces インスタンスの OpenShift クラスター内の Dev Workspace コンテナーに Kubernetes シークレットをマウントします。

前提条件

  • 宛先 OpenShift クラスターへの管理権限を持つアクティブな oc セッション。CLI の使用方法 を参照。
  • ユーザープロジェクトですべての Dev Workspace コンテナーにマウントする新しいシークレットを作成するか、既存のシークレットを決定している。

手順

  1. Secret のマウントに必要なラベルを Secret に追加します。

    $ oc label secret <Secret_name> \
            controller.devfile.io/mount-to-devworkspace=true \
            controller.devfile.io/watch-secret=true
  2. オプション: アノテーションを使用して、シークレットのマウント方法を設定します。

    表6.1 オプションのアノテーション
    アノテーション説明

    controller.devfile.io/mount-path:

    マウントパスを指定します。

    デフォルトは /etc/secret/<Secret_name> です。

    controller.devfile.io/mount-as:

    リソースのマウント方法を指定します: filesubpath、または env

    デフォルトは file です。

    mount-as: file は、キーと値をマウントパス内のファイルとしてマウントします。

    mount-as: subpath は、サブパスボリュームマウントを使用して、マウントパス内のキーと値をマウントします。

    mount-as: env は、すべての Dev Workspace コンテナーに環境変数としてキーと値をマウントします。

例6.1 シークレットをファイルとしてマウント

apiVersion: v1
kind: Secret
metadata:
  name: mvn-settings-secret
  labels:
    controller.devfile.io/mount-to-devworkspace: 'true'
    controller.devfile.io/watch-secret: 'true'
  annotations:
    controller.devfile.io/mount-path: '/home/user/.m2'
data:
  settings.xml: <Base64_encoded_content>

ワークスペースを開始すると、/home/user/.m2/settings.xml ファイルが Dev Workspace コンテナーで使用可能になります。

Maven を使用すると、settings.xml ファイルのカスタムパスを設定できます。以下に例を示します。

$ mvn --settings /home/user/.m2/settings.xml clean install

6.1.1. イメージプルシークレットの作成

組織の OpenShift Dev Spaces インスタンスの OpenShift クラスター内の Dev Workspace Pod が、認証を必要とするコンテナーレジストリーにアクセスできるようにするには、イメージプルシークレットを作成します。

oc.dockercfg ファイル、または config.json ファイルを使用して、イメージプルシークレットを作成できます。

6.1.1.1. oc でシークレットをプルするイメージを作成する

前提条件

  • 宛先 OpenShift クラスターへの管理権限を持つアクティブな oc セッション。CLI の使用方法 を参照。

手順

  1. ユーザープロジェクトで、プライベートコンテナーレジストリーの詳細とクレデンシャルを使用してイメージプルシークレットを作成します。

    $ oc create secret docker-registry <Secret_name> \
        --docker-server=<registry_server> \
        --docker-username=<username> \
        --docker-password=<password> \
        --docker-email=<email_address>
  2. 次のラベルをイメージプルシークレットに追加します。

    $ oc label secret <Secret_name> controller.devfile.io/devworkspace_pullsecret=true controller.devfile.io/watch-secret=true

6.1.1.2. .dockercfg ファイルからイメージプルシークレットを作成する

プライベートコンテナーレジストリーのクレデンシャルを .dockercfg ファイルにすでに保存している場合は、そのファイルを使用してイメージプルシークレットを作成できます。

前提条件

  • 宛先 OpenShift クラスターへの管理権限を持つアクティブな oc セッション。CLI の使用方法 を参照。
  • base64 コマンドラインツールは、使用しているオペレーティングシステムにインストールされている。

手順

  1. .dockercfg ファイルを Base64 にエンコードします。

    $ cat .dockercfg | base64 | tr -d '\n'
  2. ユーザープロジェクトに新しい OpenShift シークレットを作成します。

    apiVersion: v1
    kind: Secret
    metadata:
      name: <Secret_name>
      labels:
        controller.devfile.io/devworkspace_pullsecret: 'true'
        controller.devfile.io/watch-secret: 'true'
    data:
      .dockercfg: <Base64_content_of_.dockercfg>
    type: kubernetes.io/dockercfg
  3. シークレットを適用します。

    $ oc apply -f - <<EOF
    <Secret_prepared_in_the_previous_step>
    EOF

6.1.1.3. config.json ファイルからイメージプルシークレットを作成する

プライベートコンテナーレジストリーのクレデンシャルを $HOME/.docker/config.json ファイルに既に保存している場合は、そのファイルを使用してイメージプルシークレットを作成できます。

前提条件

  • 宛先 OpenShift クラスターへの管理権限を持つアクティブな oc セッション。CLI の使用方法 を参照。
  • base64 コマンドラインツールは、使用しているオペレーティングシステムにインストールされている。

手順

  1. $HOME/.docker/config.json ファイルを Base64 にエンコードします。

    $ cat config.json | base64 | tr -d '\n'
  2. ユーザープロジェクトに新しい OpenShift シークレットを作成します。

    apiVersion: v1
    kind: Secret
    metadata:
      name: <Secret_name>
      labels:
        controller.devfile.io/devworkspace_pullsecret: 'true'
        controller.devfile.io/watch-secret: 'true'
    data:
      .dockerconfigjson: <Base64_content_of_config.json>
    type: kubernetes.io/dockerconfigjson
  3. シークレットを適用します。

    $ oc apply -f - <<EOF
    <Secret_prepared_in_the_previous_step>
    EOF

6.1.2. Git プロバイダーアクセストークンの使用

GitHub、GitLab、Bitbucket、または Microsoft Azure Repos の OAuth は、社内の OpenShift Dev Spaces インスタンスの 管理者が設定 する必要があります。管理者が OpenShift Dev Spaces ユーザー用に設定できなかった場合の回避策は、パーソナルアクセストークンを Kubernetes シークレットとして適用することです。

アクセストークンを Secret としてマウントすると、OpenShift Dev Spaces サーバーは、リポジトリーの /.che および /.vscode フォルダーへのアクセスを含め、ワークスペースの作成中に複製されたリモートリポジトリーにアクセスできます。

組織の OpenShift Dev Spaces インスタンスの OpenShift クラスターのユーザープロジェクトにシークレットを適用します。

シークレットを適用した後、GitHub、GitLab、Bitbucket Server、または Microsoft Azure Repos でホスティングされているプライベート Git リポジトリーのクローンを使用して、ワークスペースを作成できます。

Git プロバイダーごとに複数のアクセストークンシークレットを作成および適用できます。これらの各 Secret をユーザープロジェクトに適用する必要があります。

前提条件

  • 組織の OpenShift Dev Spaces インスタンスが実行されているクラスターのクラスター管理者権限を持っています。
  • クラスターにログインしました。

    ヒント

    OpenShift では、oc コマンドラインツールを使用してクラスターにログインできます。

    $ oc login https://<openshift_dev_spaces_fqdn> --username=<my_user>

手順

  1. Git プロバイダーの Web サイトでアクセストークンを生成します。
  2. アクセストークンを Base64 にエンコードします。

    ヒント

    Base64 コマンドラインツールがインストールされている場合は、コマンドラインを使用できます。

    $ echo -n '<your_access_token_string>' | base64
  3. Web ブラウザーで https://<openshift_dev_spaces_fqdn>/api/user/id に移動して、OpenShift Dev Spaces ユーザー ID を取得します。
  4. 新しい OpenShift シークレットを準備します。

    kind: Secret
    apiVersion: v1
    metadata:
      name: personal-access-token-<your_choice_of_name_for_this_token>
      labels:
        app.kubernetes.io/component: scm-personal-access-token
        app.kubernetes.io/part-of: che.eclipse.org
      annotations:
        che.eclipse.org/che-userid: <devspaces_user_id>1
        che.eclipse.org/scm-personal-access-token-name: <git_provider_name>2
        che.eclipse.org/scm-url: <git_provider_endpoint>3
        che.eclipse.org/scm-username: <git_provider_username>4
        che.eclipse.org/scm-organization: <git_provider_organization>5
    data:
      token: <Base64_encoded_access_token>
    type: Opaque
    1
    OpenShift Dev Spaces ユーザー ID。
    2
    Git プロバイダー名: githubgitlabbitbucket-server、または azure-devops
    3
    Git プロバイダーの URL。
    4
    Git プロバイダーのユーザー名。azure-devops の場合は、ユーザーの電子メールアドレス。
    5
    この行は、Git プロバイダーのユーザー組織である azure-devops のみに適用されます。
  5. https://<openshift_dev_spaces_fqdn>/api/kubernetes/namespace にアクセスして、OpenShift Dev Spaces ユーザー namespace を name として取得します。
  6. クラスター内の OpenShift Dev Spaces ユーザー namespace に切り替えます。

    ヒント

    OpenShift の場合:

    • oc コマンドラインツールは、クラスター内で現在使用している namespace を返すことができます。これを使用して、現在の namespace を確認できます。

      $ oc project
    • 必要に応じて、コマンドラインで OpenShift Dev Spaces ユーザー namespace に切り替えることができます。

      $ oc project <your_user_namespace>
  7. シークレットを適用します。

    ヒント

    OpenShift では、oc コマンドラインツールを使用できます。

    $ oc apply -f - <<EOF
    <Secret_prepared_in_step_5>
    EOF

検証

  1. Git プロバイダーがホストする リモート Git リポジトリーの URL を使用して、新しいワークスペースを開始します
  2. 変更を加えて、ワークスペースからリモート Git リポジトリーにプッシュします。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.