第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 オプションのアノテーション
    Annotation説明

    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 ユーザー向けに設定できなかった場合、回避策はパーソナルアクセストークンを使用することです。パーソナルアクセストークンは、OpenShift Dev Spaces ダッシュボードの User Preferences ページ (https://<openshift_dev_spaces_fqdn>/dashboard/#/user-preferences?tab=personal-access-tokens) で設定するか、Kubernetes シークレットとして手動で適用できます。

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

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

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

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

前提条件

  • クラスターにログインしている。

    ヒント

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

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

手順

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

    重要

    パーソナルアクセストークンは機密情報であるため、機密扱いにする必要があります。パスワードのように扱います。認証に問題がある場合は、正しいトークンを使用し、リポジトリーのクローンを作成するための適切なパーミッションがあることを確認してください。

    1. コンピューターのローカルでターミナルを開きます。
    2. パーソナルアクセストークンを使用して、git コマンドでリポジトリーのクローンを作成します。git コマンドの形式は、Git プロバイダーによって異なります。たとえば、GitHub のパーソナルアクセストークンの検証は、以下のコマンドを使用して実行できます。
    git clone https://<PAT>@github.com/username/repo.git

    <PAT> は、パーソナルアクセストークンに、username/repo は適切なリポジトリーパスに置き換えます。トークンが有効で、必要なパーミッションがある場合は、クローンプロセスが正常に実行されるはずです。それ以外の場合、これはパーソナルアクセストークンが正しくない、パーミッションが不十分である、またはその他の問題を示しています。

    重要

    GitHub Enterprise Cloud の場合は、トークンが 組織内での使用が許可されている ことを確認します。

  2. Web ブラウザーで https://<openshift_dev_spaces_fqdn>/api/user/id に移動して、OpenShift Dev Spaces ユーザー ID を取得します。
  3. 新しい 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-organization: <git_provider_organization>4
    stringData:
      token: <Content_of_access_token>
    type: Opaque
    1
    OpenShift Dev Spaces ユーザー ID。
    2
    Git プロバイダー名: githubgitlabbitbucket-server、または azure-devops
    3
    Git プロバイダーの URL。
    4
    この行は、Git プロバイダーのユーザー組織である azure-devops のみに適用されます。
  4. https://<openshift_dev_spaces_fqdn>/api/kubernetes/namespace にアクセスして、OpenShift Dev Spaces ユーザー namespace を name として取得します。
  5. クラスター内の OpenShift Dev Spaces ユーザー namespace に切り替えます。

    ヒント

    OpenShift の場合:

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

      $ oc project

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

      $ oc project <your_user_namespace>

  6. シークレットを適用します。

    ヒント

    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.