4.9.6. プライベートレジストリーからの Operator のイメージへのアクセス


Operator Lifecycle Manager (OLM) によって管理される Operator に関連する特定のイメージが、認証されたコンテナーイメージレジストリー (プライベートレジストリー) でホストされている場合、OLM およびソフトウェアカタログは、デフォルトでイメージをプルできません。アクセスを有効にするために、レジストリーの認証情報が含まれるプルシークレットを作成できます。カタログソースの 1 つ以上のプルシークレットを参照することで、OLM はシークレットの配置を Operator およびカタログ namespace で処理し、インストールを可能にします。

Operator またはそのオペランドで必要な他のイメージでも、プライベートレジストリーへのアクセスが必要になる場合があります。OLM は、このシナリオのターゲットテナント namespace ではシークレットの配置を処理しませんが、認証情報をグローバルクラスタープルシークレットまたは個別の namespace サービスアカウントに追加して、必要なアクセスを有効にできます。

OLM によって管理される Operator に適切なプルアクセスがあるかどうかを判別する際に、以下のタイプのイメージを考慮する必要があります。

インデックスイメージ
CatalogSource オブジェクトは、インデックスイメージを参照できます。このイメージは、Operator のバンドル形式を使用し、イメージレジストリーでホストされるコンテナーイメージとしてパッケージ化されるカタログソースです。インデックスイメージがプライベートレジストリーでホストされる場合、シークレットを使用してプルアクセスを有効にすることができます。
バンドルイメージ
Operator バンドルイメージは、Operator の一意のバージョンを表すコンテナーイメージとしてパッケージ化されるメタデータおよびマニフェストです。カタログソースで参照されるバンドルイメージが 1 つ以上のプライベートレジストリーでホストされる場合、シークレットを使用してプルアクセスを有効にすることができます。
Operator イメージおよびオペランドイメージ

カタログソースからインストールされた Operator が、(Operator イメージ自体に、または監視するオペランドイメージの 1 つに) プライベートイメージを使用する場合、デプロイメントは必要なレジストリー認証にアクセスできないため、Operator はインストールに失敗します。カタログソースのシークレットを参照することで、OLM はオペランドがインストールされているターゲットテナント namespace にシークレットを配置することはできません。

代わりに、認証情報を openshift-config namespace のグローバルクラスタープルシークレットに追加できます。これにより、クラスターのすべての namespace へのアクセスが提供されます。または、クラスター全体へのアクセスの提供が許容されない場合、プルシークレットをターゲットテナント namespace の default のサービスアカウントに追加できます。

レジストリー認証情報のシークレットを作成し、そのシークレットを関連するカタログで使用するために追加することで、プライベートレジストリーから Operator のイメージにアクセスできます。

前提条件

  • プライベートレジストリーで、以下を 1 つ以上ホストしている。

    • インデックスイメージまたはカタログイメージ。
    • Operator のバンドルイメージ
    • Operator またはオペランドのイメージ。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  1. 必要な各プライベートレジストリーのシークレットを作成します。

    1. プライベートレジストリーにログインして、レジストリー認証情報ファイルを作成または更新します。

      $ podman login <registry>:<port>
      注記

      レジストリー認証情報のファイルパスは、レジストリーへのログインに使用されるコンテナーツールによって異なります。podman CLI の場合、デフォルトの場所は ${XDG_RUNTIME_DIR}/containers/auth.json です。docker CLI の場合、デフォルトの場所は /root/.docker/config.json です。

    2. シークレットごとに 1 つのレジストリーに対してのみ認証情報を追加し、別のシークレットで複数のレジストリーの認証情報を管理することが推奨されます。これ以降の手順で、複数のシークレットを CatalogSource オブジェクトに含めることができ、OpenShift Container Platform はイメージのプル時に使用する単一の仮想認証情報ファイルにシークレットをマージします。

      レジストリー認証情報ファイルは、デフォルトで複数のレジストリーまたはリポジトリーの詳細を 1 つのレジストリーに保存できます。ファイルの現在の内容を確認します。以下に例を示します。

      複数のレジストリーの認証情報を保存するファイル

      {
          "auths": {
              "registry.redhat.io": {
                  "auth": "FrNHNydQXdzclNqdg=="
              },
              "quay.io": {
                  "auth": "fegdsRib21iMQ=="
              },
              "https://quay.io/my-namespace/my-user/my-image": {
                  "auth": "eWfjwsDdfsa221=="
              },
              "https://quay.io/my-namespace/my-user": {
                  "auth": "feFweDdscw34rR=="
              },
              "https://quay.io/my-namespace": {
                  "auth": "frwEews4fescyq=="
              }
          }
      }

      これ以降の手順で、シークレットの作成にこのファイルが使用されるため、保存できる詳細は 1 つのファイルにつき 1 つのレジストリーのみであることを確認してください。これには、以下の方法の 1 つを使用します。

      • podman logout <registry> コマンドを使用して、必要な 1 つのレジストリーのみになるまで、追加のレジストリーの認証情報を削除します。
      • レジストリー認証情報ファイルを編集し、レジストリーの詳細を分離して、複数のファイルに保存します。以下に例を示します。

        1 つのレジストリーの認証情報を保存するファイル

        {
                "auths": {
                        "registry.redhat.io": {
                                "auth": "FrNHNydQXdzclNqdg=="
                        }
                }
        }

        別のレジストリーの認証情報を保存するファイル

        {
                "auths": {
                        "quay.io": {
                                "auth": "Xd2lhdsbnRib21iMQ=="
                        }
                }
        }

    3. プライベートレジストリーの認証情報が含まれるシークレットを openshift-marketplace namespace に作成します。

      $ oc create secret generic <secret_name> \
          -n openshift-marketplace \
          --from-file=.dockerconfigjson=<path/to/registry/credentials> \
          --type=kubernetes.io/dockerconfigjson

      この手順を繰り返して、他の必要なプライベートレジストリーの追加シークレットを作成し、--from-file フラグを更新して別のレジストリー認証情報ファイルのパスを指定します。

  2. 1 つ以上のシークレットを参照するように既存の CatalogSource オブジェクトを作成または更新します。

    apiVersion: operators.coreos.com/v1alpha1
    kind: CatalogSource
    metadata:
      name: my-operator-catalog
      namespace: openshift-marketplace
    spec:
      sourceType: grpc
      secrets: 
    1
    
      - "<secret_name_1>"
      - "<secret_name_2>"
      grpcPodConfig:
        securityContextConfig: <security_mode> 
    2
    
      image: <registry>:<port>/<namespace>/<image>:<tag>
      displayName: My Operator Catalog
      publisher: <publisher_name>
      updateStrategy:
        registryPoll:
          interval: 30m
    1
    spec.secrets セクションを追加し、必要なシークレットを指定します。
    2
    legacy または restricted の値を指定します。フィールドが設定されていない場合、デフォルト値は legacy です。今後の OpenShift Container Platform リリースでは、デフォルト値が restricted になる予定です。
    注記

    restricted 権限でカタログを実行できない場合は、このフィールドを手動で legacy に設定することを推奨します。

  3. サブスクライブされた Operator によって参照される Operator イメージまたはオペランドイメージにプライベートレジストリーへのアクセスが必要な場合は、クラスター内のすべての namespace または個々のターゲットテナント namespace のいずれかにアクセスを提供できます。

    • クラスター内のすべての namespace へアクセスを提供するには、認証情報を openshift-config namespace のグローバルクラスタープルシークレットに追加します。

      警告

      クラスターリソースは新規のグローバルプルシークレットに合わせて調整する必要がありますが、これにより、クラスターのユーザービリティーが一時的に制限される可能性があります。

      1. グローバルプルシークレットから .dockerconfigjson ファイルを展開します。

        $ oc extract secret/pull-secret -n openshift-config --confirm
      2. .dockerconfigjson ファイルを、必要なプライベートレジストリーまたはレジストリーの認証情報で更新し、これを新規ファイルとして保存します。

        $ cat .dockerconfigjson | \
            jq --compact-output '.auths["<registry>:<port>/<namespace>/"] |= . + {"auth":"<token>"}' \
        1
        
            > new_dockerconfigjson
        1
        <registry>:<port>/<namespace> をプライベートレジストリーの詳細に置き換え、<token> を認証情報に置き換えます。
      3. 新規ファイルでグローバルプルシークレットを更新します。

        $ oc set data secret/pull-secret -n openshift-config \
            --from-file=.dockerconfigjson=new_dockerconfigjson
    • 個別の namespace を更新するには、ターゲットテナント namespace でアクセスが必要な Operator のサービスアカウントにプルシークレットを追加します。

      1. テナント namespace で openshift-marketplace 用に作成したシークレットを再作成します。

        $ oc create secret generic <secret_name> \
            -n <tenant_namespace> \
            --from-file=.dockerconfigjson=<path/to/registry/credentials> \
            --type=kubernetes.io/dockerconfigjson
      2. テナント namespace を検索して、Operator のサービスアカウントの名前を確認します。

        $ oc get sa -n <tenant_namespace> 
        1
        1
        Operator が個別の namespace にインストールされていた場合、その namespace を検索します。Operator がすべての namespace にインストールされていた場合、openshift-operators namespace を検索します。

        出力例

        NAME            SECRETS   AGE
        builder         2         6m1s
        default         2         6m1s
        deployer        2         6m1s
        etcd-operator   2         5m18s 
        1

        1
        インストールされた etcd Operator のサービスアカウント。
      3. シークレットを Operator のサービスアカウントにリンクします。

        $ oc secrets link <operator_sa> \
            -n <tenant_namespace> \
             <secret_name> \
            --for=pull
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

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

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

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

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

Legal Notice

Theme

© 2026 Red Hat
トップに戻る