Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

Red Hat Quayの管理

Red Hat Quay 3.4

Red Hat Quayの管理

概要

Red Hat Quayの管理

前書き
リンクのコピー

Red Hat Quay レジストリを展開した後、その展開をさらに設定、管理する方法は数多くあります。ここでは、以下のようなトピックを取り上げています。

  • Red Hat Quayの高度な設定
  • Red Hat Quay の新リリースを知らせる通知の設定
  • SSLおよびTLS証明書による接続の保護
  • アクションログのストレージをElasticsearchに誘導する
  • Clairによるイメージセキュリティスキャンの設定
  • Container Security Operator でポッドイメージをスキャン
  • Quay Bridge OperatorでRed Hat QuayをOpenShiftに統合します。
  • リポジトリミラーリングによるイメージの反映
  • BitTorrentサービスによるQuay画像の共有
  • LDAPによるユーザーの認証
  • PrometheusとGrafanaのメトリクスにQuayを有効にする
  • ジオレプリケーションの設定
  • Quayのトラブルシューティング

第1章 Red Hat Quayの高度な設定
リンクのコピー

初期導入後のRed Hat Quayは、いくつかの異なるインターフェースを使って設定することができます。

  • Red Hat Quay Config Tool: quayコンテナをconfigモードで実行すると、Red Hat Quay クラスタを構成するための Web ベースのインターフェースが表示されます。この方法は、Red Hat Quayサービス自体のほとんどの構成に推奨される方法です。
  • config.yaml の編集: config.yaml ファイルには、Red Hat Quayクラスタの構成情報のほとんどが格納されています。このファイルを直接編集することは可能ですが、Config Toolでは利用できない高度なチューニングやパフォーマンス機能を利用する場合にのみお勧めします。
  • Red Hat QuayのAPI: 一部のRed Hat Quayの設定はAPIを通じて行うことができます。

特定の機能のための設定は別のセクションで説明しますが、このセクションでは、それぞれのインターフェイスを使用して、より高度な設定を行う方法を説明します。

1.1. Red Hat Quay Config Tool を使用した Red Hat Quay の変更
リンクのコピー

Red Hat Quay Config Tool は、通常の Red Hat Quay サービスと並行してquayコンテナをconfigモードで実行することで利用可能になります。Config Toolの実行は、OpenShift上で動作するRed Hat Quayクラスターの場合は、ホストシステム上で直接動作する場合とは異なります。

1.1.1. Red Hat Quay OperatorからのConfig Toolの実行
リンクのコピー

OpenShiftからRed Hat Quay Operatorを実行している場合は、おそらくConfig Toolがすでに利用可能になっていると思います。コンフィグツールにアクセスするには、次のようにします。

  1. OpenShift コンソールから、Red Hat Quay が実行されているプロジェクトを選択します。（例えば、quay-enterprise）

  2. 左の列からネットワーク→ルートを選択します。次の画像に示すように、Red Hat Quay アプリケーションと Config Tool の両方へのルートが表示されます。

    View the route to the Red Hat Quay Config Tool

  3. Config Toolへのルート（例: example-quayecosystem-quay-config）を選択し、選択します。ブラウザにConfig tool Web UIが表示されます。

  4. Modify configuration for this cluster を選択します。次の画像に示すように、Config Tool が表示され、Red Hat Quay クラスタの機能を変更する準備ができています。

    Modify Red Hat Quay cluster settings from the Config Tool

  5. 必要な変更を行った後、Save Configuration Changesを選択します。コンフィグツールが変更内容を検証します。
  6. 必要に応じて、Continue Editingを選択して修正するか、Nextを選択して次に進みます。
  7. プロンプトが表示されたら、Download Configurationを選択することをお勧めします。これにより、新しいconfig.yamlと、Red Hat Quayのセットアップで使用された証明書や鍵を含むtarボールがダウンロードされます。
  8. Go to deployment rolloutを選択し、Populate the configuration to deploymentsを選択します。Red Hat Quay のポッドが再起動され、変更が有効になります。

保存されたconfig.yamlファイルは、設定の高度な変更を行うために使用することも、今後の参考のために保存しておくこともできます。

1.1.2. コマンドラインからのコンフィグツールの実行
リンクのコピー

podmanコマンドやdockerコマンドなどのツールを使用してホストシステムから直接 Red Hat Quay を実行している場合は、最初の Red Hat Quay の展開後に Config Tool を再起動して Red Hat Quay クラスターを変更することができます。以下に、実行する方法を説明します。

  1. quayをコンフィグモードで起動します。最初のquayノードで以下を実行し、my-secret-passwordをあなたのパスワードに置き換えます。既存のコンフィグバンドルを変更したい場合は、レジストリモードと同じように、コンフィグディレクトリをQuayコンテナにマウントするだけです。 

    # podman run --rm -it --name quay_config -p 8080:8080 \
    -v path/to/config-bundle:/conf/stack \
    registry.redhat.io/quay/quay-rhel8:v3.4.6 config my-secret-password
    Copy to Clipboard Toggle word wrap
  2. ブラウザを開く: quayのコンフィグレーションツールが起動したら、コンフィグレーションツールを実行しているシステムのURLとポート8080に向けてブラウザを開きます（例: https://myquay.example.com:8080）。ユーザー名とパスワードの入力を求められます。

この時点で、前述のようにRed Hat Quayクラスターの変更を開始することができます。

1.2. APIを使用したRed Hat Quayの変更
リンクのコピー

Red Hat Quay API へのアクセス方法については、Red Hat Quay API Guideを参照してください。

1.3. config.yamlファイルを編集して Red Hat Quay を変更します。
リンクのコピー

Config Toolでは利用できない高度なRed Hat Quayの設定は、config.yamlファイルを直接編集することで実現できます。利用可能な設定は、Schema for Red Hat Quay configurationに記載されています。以下は、config.yamlファイルで直接変更できる設定の例です。

1.3.1. Red Hat Quayのサインインに名前と会社を追加する
リンクのコピー

以下のように設定すると、ユーザーが最初にサインインしたときに、名前と会社名を入力するプロンプトが表示されます。オプションとして、Red Hat Quay のユーザーに関する追加データを提供することができます。

+ FEATURE_USER_METADATA: true

1.3.2. TLSプロトコルの無効化
リンクのコピー

SSL_PROTOCOLS 設定を変更して、Red Hat Quay インスタンスでサポートしたくない SSL プロトコルを削除することができます。例えば、デフォルトのSSL_PROTOCOLS : ['TLSv1','TLSv1.1','TLSv1.2']からTLS v1のサポートを削除するには、以下のように変更します。

+ SSL_PROTOCOLS : ['TLSv1.1','TLSv1.2']

1.3.3. APIコールのレート制限
リンクのコピー

config.yamlにFEATURE_RATE_LIMITSパラメータを追加すると、nginxは特定のAPIコールを1秒あたり30回に制限します。この機能が設定されていない場合、APIコールは1秒間に300回に制限されます（事実上無制限）。利用可能なリソースがトラフィックで圧迫されないようにする必要がある場合、レート制限は重要な機能となります。

名前空間の中には、無制限のアクセスを必要とするものもあります（例えば、CI/CDにとって重要であり、優先順位が高いなど）。この場合、それらの名前空間は、config.yamlのNON_RATE_LIMITED_NAMESPACESのリストに配置することができます。

1.3.4. データベースのコネクションプールの調整
リンクのコピー

Red Hat Quayは、すべてが同じコンテナ内で実行される多くの異なるプロセスで構成されています。これらのプロセスの多くは、データベースと連動しています。

有効にすると、データベースと対話する各プロセスには、コネクションプールが含まれます。これらのプロセスごとのコネクションプールは、最大20個の接続を維持するように設定されています。高負荷時には、Red Hat Quayコンテナ内のすべてのプロセスの接続プールを満たすことが可能です。特定の展開や負荷の下では、Red Hat Quay がデータベースの構成された最大接続数を超えないようにするための分析が必要になる場合があります。

時間が経つと、接続プールはアイドル接続を解放します。すべての接続をすぐに解除するには、Red Hat Quay は再起動が必要です。

データベース接続プールは、環境変数 DB_CONNECTION_POOLING={true|false} を設定して切り替えることができます。

データベース接続プーリングが有効な場合、接続プールの最大サイズを変更することができます。これは、以下の config.yaml オプションを使用して実行できます。 

DB_CONNECTION_ARGS:
  max_connections: 10
Copy to Clipboard Toggle word wrap
1.3.4.1. データベース接続引数
リンクのコピー

Red Hat Quay のデータベース接続設定はconfig.yamlファイル内でカスタマイズすることができます。これらは、Postgres用のpsycopg2やMySQL用のpymysqlのように、基礎となるデータベースドライバに完全に依存しています。また、以下のように、Peeweeのコネクションプーリング機構が使用する引数を渡すことも可能です。 

DB_CONNECTION_ARGS:
  max_connections: n  # Max Connection Pool size. (Connection Pooling only)
  timeout: n  # Time to hold on to connections. (Connection Pooling only)
  stale_timeout: n  # Number of seconds to block when the pool is full. (Connection Pooling only)
Copy to Clipboard Toggle word wrap
1.3.4.2. HTTP接続回数
リンクのコピー

環境変数を使って、HTTPの同時接続数を指定することができます。これらは、全体として、または特定のコンポーネントに対して指定することができます。それぞれのデフォルトは、1プロセスあたり50並列接続です。

環境変数: - WORKER_CONNECTION_COUNT_REGISTRY=n - WORKER_CONNECTION_COUNT_WEB=n - WORKER_CONNECTION_COUNT_SECSCAN=n - WORKER_CONNECTION_COUNT=n

特定のコンポーネントのカウントを指定すると、WORKER_CONNECTION_COUNT で設定された値が上書きされます。

1.3.4.3. ダイナミックなプロセスカウント
リンクのコピー

ダイナミックサイズのプロセスの量を推定するために、デフォルトでは以下の計算が行われます。

注記

Red Hat Quay は、マシン全体から利用可能な CPU 数を照会します。kubernetesやその他の非仮想化メカニズムを使用して適用された制限は、この動作に影響しません。Red Hat Quayはノード上のプロセッサの合計数に基づいて計算します。記載されているデフォルト値は単なる目標値であり、最大値を超えてはならず、最小値を下回ってはならない。

以下の各プロセス量は、以下の環境変数を使ってオーバーライドすることができます。

  • registry - レジストリアクションを処理するためのHTTPエンドポイントを提供します。

    • 最小値: 8
    • 最大値: 64
    • デフォルト: $CPU_COUNT x 4
    • 環境変数: WORKER_COUNT_REGISTRY

  • web - ウェブベースのインターフェース用のHTTPエンドポイントを提供します

    • 最小値: 2
    • 最大値: 32
    • デフォルト: $CPU_COUNT x 2
    • 環境変数: WORKER_COUNT_WEB

  • secscan - Clairと相互作用

    • 最小値: 2
    • 最大値: 4
    • デフォルト: $CPU_COUNT x 2
    • 環境変数: WORKER_COUNT_SECSCAN
1.3.4.4. 環境変数
リンクのコピー

Red Hat Quay では、環境変数を使用してデフォルトの動作をオーバーライドすることができます。この表では、各変数と、使用できる値を一覧にして説明しています。

Expand
表1.1 ワーカー数の環境変数
変数説明値

WORKER_COUNT_REGISTRY

Quayコンテナ内でレジストリ要求を処理するプロセスの数を指定します。

8～64の整数

WORKER_COUNT_WEB

コンテナ内でUI/Webリクエストを処理するプロセスの数を指定します。

2～32の整数

WORKER_COUNT_SECSCAN

コンテナ内でセキュリティスキャン（Clairなど）の統合を処理するプロセス数を指定します。

2～4の整数

DB_CONNECTION_POOLING

データベースのコネクションプーリングを切り替えます。3.4では、デフォルトで無効になっています。

true または false

1.3.4.5. コネクションプーリングの停止
リンクのコピー

大量のユーザーアクティビティを伴う Red Hat Quay の展開では、定期的に最大 2k のデータベース接続制限に達することがあります。このような場合、Red Hat Quayでデフォルトで有効になっているコネクションプーリングは、データベース接続数が指数関数的に増加する原因となるため、コネクションプーリングをオフにする必要があります。

コネクションプーリングをオフにしてもデータベース接続数が2kに制限されるのを防ぐのに十分でない場合は、追加の対策を講じる必要があります。この場合、ワークロードに合わせてデータベースの最大接続数を増やす必要があるかもしれません。

1.4. コンフィギュレーションAPIの利用
リンクのコピー

設定ツールは、設定の構築、検証、バンドル、デプロイに使用できる4つのエンドポイントを示します。config-toolのAPIは、https://github.com/quay/config-tool/blob/master/pkg/lib/editor/API.md にドキュメント化されています。ここでは、APIを使って現在の設定を取得する方法と、変更した内容を検証する方法について説明します。

1.4.1. 初期設定値の取得
リンクのコピー

初めてコンフィギュレーションツールを実行するときに、既存のコンフィギュレーションがない場合は、デフォルトのコンフィギュレーションを取得することができます。コンテナをコンフィグモードで起動します。 

$ sudo podman run --rm -it --name quay_config \
  -p 8080:8080 \
  registry.redhat.io/quay/quay-rhel8:v3.4.6 config secret
Copy to Clipboard Toggle word wrap

デフォルトを取得するには、コンフィギュレーションAPIのconfigエンドポイントを使用します。 

$ curl -X GET -u quayconfig:secret http://quay-server:8080/api/v1/config  | jq
Copy to Clipboard Toggle word wrap

返される値は、JSON形式によるデフォルト設定です。 

{
  "config.yaml": {
    "AUTHENTICATION_TYPE": "Database",
    "AVATAR_KIND": "local",
    "DB_CONNECTION_ARGS": {
      "autorollback": true,
      "threadlocals": true
    },
    "DEFAULT_TAG_EXPIRATION": "2w",
    "EXTERNAL_TLS_TERMINATION": false,
    "FEATURE_ACTION_LOG_ROTATION": false,
    "FEATURE_ANONYMOUS_ACCESS": true,
    "FEATURE_APP_SPECIFIC_TOKENS": true,
    ....
  }

}
Copy to Clipboard Toggle word wrap

1.4.2. 現在の設定の取得
リンクのコピー

すでにQuayレジストリを構成してデプロイしている場合は、コンテナを停止してコンフィグレーションモードで再起動し、既存のコンフィグレーションをボリュームとして読み込みます。 

$ sudo podman run --rm -it --name quay_config \
  -p 8080:8080 \
  -v $QUAY/config:/conf/stack:Z \
  registry.redhat.io/quay/quay-rhel8:v3.4.6 config secret
Copy to Clipboard Toggle word wrap

現在の設定を取得するには、APIのconfigエンドポイントを使用します。 

$ curl -X GET -u quayconfig:secret http://quay-server:8080/api/v1/config  | jq
Copy to Clipboard Toggle word wrap

返される値は、データベースとRedisの設定データを含む、JSON形式の現在の設定です。 

{
  "config.yaml": {
    ....
    "BROWSER_API_CALLS_XHR_ONLY": false,
    "BUILDLOGS_REDIS": {
      "host": "quay-server",
      "password": "strongpassword",
      "port": 6379
    },
    "DATABASE_SECRET_KEY": "4b1c5663-88c6-47ac-b4a8-bb594660f08b",
    "DB_CONNECTION_ARGS": {
      "autorollback": true,
      "threadlocals": true
    },
    "DB_URI": "postgresql://quayuser:quaypass@quay-server:5432/quay",
    "DEFAULT_TAG_EXPIRATION": "2w",
    ....


  }

}
Copy to Clipboard Toggle word wrap

1.4.3. APIによる設定の検証
リンクのコピー

設定を検証するには、config/validateエンドポイントに設定を投稿します。 

curl -u quayconfig:secret --header 'Content-Type: application/json' --request POST --data '
{
  "config.yaml": {
    ....
    "BROWSER_API_CALLS_XHR_ONLY": false,
    "BUILDLOGS_REDIS": {
      "host": "quay-server",
      "password": "strongpassword",
      "port": 6379
    },
    "DATABASE_SECRET_KEY": "4b1c5663-88c6-47ac-b4a8-bb594660f08b",
    "DB_CONNECTION_ARGS": {
      "autorollback": true,
      "threadlocals": true
    },
    "DB_URI": "postgresql://quayuser:quaypass@quay-server:5432/quay",
    "DEFAULT_TAG_EXPIRATION": "2w",
    ....

  }

} http://quay-server:8080/api/v1/config/validate | jq
Copy to Clipboard Toggle word wrap

返される値は、設定で見つかったエラーを含む配列です。設定が有効であれば、空の配列[]が返されます。

1.4.4. 必須項目の決定
リンクのコピー

空の構成構造をconfig/validateエンドポイントに投稿することで、必須フィールドを決定することができます。 

curl -u quayconfig:secret --header 'Content-Type: application/json' --request POST --data '
{
  "config.yaml": {
  }

} http://quay-server:8080/api/v1/config/validate | jq
Copy to Clipboard Toggle word wrap

返される値は、どのフィールドが必須であるかを示す配列です。 

[
  {
    "FieldGroup": "Database",
    "Tags": [
      "DB_URI"
    ],
    "Message": "DB_URI is required."
  },
  {
    "FieldGroup": "DistributedStorage",
    "Tags": [
      "DISTRIBUTED_STORAGE_CONFIG"
    ],
    "Message": "DISTRIBUTED_STORAGE_CONFIG must contain at least one storage location."
  },
  {
    "FieldGroup": "HostSettings",
    "Tags": [
      "SERVER_HOSTNAME"
    ],
    "Message": "SERVER_HOSTNAME is required"
  },
  {
    "FieldGroup": "HostSettings",
    "Tags": [
      "SERVER_HOSTNAME"
    ],
    "Message": "SERVER_HOSTNAME must be of type Hostname"
  },
  {
    "FieldGroup": "Redis",
    "Tags": [
      "BUILDLOGS_REDIS"
    ],
    "Message": "BUILDLOGS_REDIS is required"
  }
]
Copy to Clipboard Toggle word wrap

第2章 Red Hat Quay のリリース通知の取得
リンクのコピー

Red Hat Quay の最新リリースや Red Hat Quay に関連するその他の変更を確認するには、Red Hat Customer Portalでアップデート通知に登録してください。通知に登録すると、Red Hat Quay の新しいバージョン、ドキュメントの更新、その他の Red Hat Quay のニュースをお知らせする通知を受け取ることができます。

  1. Red Hat カスタマーアカウントの認証情報を使ってRed Hat Customer Portalにログインします。
  2. ユーザー名（右上隅）を選択すると、Red Hat Account と Customer Portal の選択項目が表示されます。 View account and portal selections
  3. Notificationsを選択します。あなたのプロフィール活動ページが表示されます。
  4. Notificationsタブを選択します。
  5. Manage Notificationsを選択します。
  6. Follow を選択し、ドロップダウンボックスから Product を選択します。
  7. 製品の隣にあるドロップダウンボックスから、Red Hat Quayを検索して選択します。 Select Products from notifications box
  8. SAVE NOTIFICATIONボタンを選択します。今後、Red Hat Quay製品に新しいリリースなどの変更があった場合には、通知が届きます。

第3章 Red Hat Quayへの接続を保護するためのSSLの使用
リンクのコピー

このドキュメントでは、Red Hat Quay をシングルノードまたは高可用性デプロイメントでデプロイしていることを前提としています。

自己署名証明書を使用して Red Hat Quay を構成するには、認証局 (CA) を作成し、必要なキーファイルと証明書ファイルを生成する必要があります。その後、Red Hat Quay Config Toolやコマンドラインを使ってこれらのファイルを入力します。

3.1. CAの作成と証明書への署名
リンクのコピー

  1. ルートCAを作成します。 

    $ openssl genrsa -out rootCA.key 2048
$ openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.pem
    Copy to Clipboard Toggle word wrap

    その結果、カレントディレクトリに rootCA.key と rootCA.pem のファイルが作成されます。

  2. 証明書と秘密鍵の作成: Red Hat QuayにTLSを処理させる場合は、構成時に提供する証明書と秘密鍵を作成する必要があります。これらのファイルは、証明書機関から入手することができます。ここでは、先ほど作成した自己署名証明書を使って、これらのファイルを作成する方法を紹介します。

    この例では、device.crtとdevice.keyファイルを作成します。これらのファイルはRed Hat Quayにアップロードされ、それぞれssl.certとssl.keyという名前に変更されます。

    OpenShift は長い完全修飾ドメイン名を作成するため、Red Hat Quay アプリケーションへの特定のルートではなく、より大きなドメインを特定するためにワイルドカードの使用を検討してください。例えば、サーバーのホスト名を聞かれたら、*.apps.openshift.example.comのように入力します。 

    Common Name (eg, your name or your server's hostname) []:*apps.openshift.example.com
    Copy to Clipboard Toggle word wrap 
    $ openssl genrsa -out device.key 2048
$ openssl req -new -key device.key -out device.csr
    Copy to Clipboard Toggle word wrap

    そして、先ほど作成したルートCAで証明書に署名します。 

    $ openssl x509 -req -in device.csr -CA rootCA.pem \
       -CAkey rootCA.key -CAcreateserial -out device.crt -days 500 -sha256
    Copy to Clipboard Toggle word wrap
注記

先ほどの*.keyと*.crtファイルを生成する代わりに、openssl.cnfファイルを作成することができます。これにより、証明書要求を生成するコマンドのプロンプトに応答するだけでは得られない、より多くの情報を証明書に追加することができます。このopenssl.cnfファイルの例では、DNS.1とIP.1をRed Hat Quayサーバーのホスト名とIPアドレスに置き換えます。

openssl.cnf 

[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name
[req_distinguished_name]
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = reg.example.com
IP.1 = 12.345.678.9
Copy to Clipboard Toggle word wrap

そして、次のようにして鍵を生成することができます。 

$ openssl x509 -req -in ssl.csr -CA rootCA.pem \
   -CAkey rootCA.key -CAcreateserial -out ssl.cert \
   -days 356 -extensions v3_req -extfile openssl.cnf
Copy to Clipboard Toggle word wrap

3.2. Red Hat Quay が新しい証明書を使用するように設定します。
リンクのコピー

次のステップは、Red Hat Quayの画面でもターミナルからでも可能です。

3.2.1. Red Hat Quayのセットアップ画面からSSLを設定する
リンクのコピー

各デプロイメントガイドに記載されている通り、configモードでquayコンテナを起動します。server Configurationセクションで、以下のようにSSLを有効にします。

  1. サーバーのホスト名を適切な値に設定し、SSLを有効にするにチェックを入れ、ssl.keyとssl.certファイル（この例では、それぞれdevice.keyとdevice.crtという名前になっています）をアップロードしてください。 Enable SSL
  2. 設定を保存します。Red Hat Quayは自動的にSSL証明書を検証します。 validating SSL
  3. コンテナの再起動 restart the container

3.2.2. コマンドラインでの設定
リンクのコピー

ウェブインターフェイスを使用しないことで、Red Hat Quayに組み込まれている構成チェックメカニズムが利用できなくなります。可能であれば、ウェブインターフェースを使用することをお勧めします。OpenShift以外のインストールでは、以下のようにコマンドラインインターフェースからSSLを設定することができます。

  1. ssl.keyとssl.certを指定されたconfigディレクトリにコピーします。この例では、Red Hat Quay の config ディレクトリは reg.example.com というホスト上の /mnt/quay/config というディレクトリにあります。

    注記

    証明書/鍵ファイルの名前はssl.keyとssl.certでなければなりません。 

    $ ls
ssl.cert  ssl.key
$ scp ssl.* root@reg.example.com:/mnt/quay/config/
[root@reg.example.com ~]$ ls /mnt/quay/config/
config.yaml  ssl.cert  ssl.key
    Copy to Clipboard Toggle word wrap

  2. config.yamlのPREFERRED_URL_SCHEME:パラメータをhttpからhttpsに変更します。 

    PREFERRED_URL_SCHEME: https
    Copy to Clipboard Toggle word wrap

  3. Red Hat Quay コンテナを再起動します。 

    $ sudo podman ps
CONTAINER ID  IMAGE                     COMMAND                 CREATED       STATUS      PORTS                   NAMES
eaf45a4aa12d  ...redhat.io/rhel8/redis-5 "/usr/bin/redis-serve" 22 hours ago  Up 22 hours 0.0.0.0:6379->6379/tcp  dreamy...
cbe7b0fa39d8  quay.io/redhat/quay       "/sbin/my_init"         22 hours ago  Up one hour 80/tcp,443/tcp,443/tcp  ferv...
705fe7311940  rhel8/mysql-80                 "/entrypoint.sh mysql"  23 hours ago  Up 22 hours 0.0.0.0:3306->3306/tcp  mysql
$ sudo podman restart cbe7b0fa39d8
    Copy to Clipboard Toggle word wrap

3.2.3. 安全な接続のテスト
リンクのコピー

ブラウザからURLにアクセスして設定を確認する https://reg.example.com/ restart the container 「あなたの接続は安全ではありません」は、CAが信頼されていないことを意味しますが、SSLが正常に機能していることを確認します。これらのメッセージを避けるためには、信頼できる認証機関から証明書を取得する必要があります。

3.3. 証明機関を信頼するようにDockerを設定する
リンクのコピー

Dockerでは、カスタムcertsを/etc/docker/certs.d/に、ホスト名のプライベートレジストリと同じ名前のディレクトリにインストールする必要があります。また、証明書の名前がca.crtであることも必要です。その方法をご紹介します。

  1. rootCAファイルをコピーします。 

    $ cp tmp/rootCA.pem /etc/docker/certs.d/reg.example.com/ca.crt
    Copy to Clipboard Toggle word wrap

  2. rootCA.pemファイルをコピーすると、docker loginが正常に認証され、リポジトリへのプッシュが成功するはずです。 

    $ sudo docker push reg.example.com/kbrwn/hello
The push refers to a repository [reg.example.com/kbrwn/hello]
5f70bf18a086: Layer already exists
e493e9cb9dac: Pushed
1770dbc4af14: Pushed
a7bb4eb71da7: Pushed
9fad7adcbd46: Pushed
2cec07a74a9f: Pushed
f342e0a3e445: Pushed
b12f995330bb: Pushed
2016366cdd69: Pushed
a930437ab3a5: Pushed
15eb0f73cd14: Pushed
latest: digest: sha256:c24be6d92b0a4e2bb8a8cc7c9bd044278d6abdf31534729b1660a485b1cd315c size: 7864
    Copy to Clipboard Toggle word wrap

第4章 Red Hat QuayコンテナへのTLS証明書の追加
リンクのコピー

カスタム TLS 証明書を Red Hat Quay に追加するには、Red Hat Quay の config ディレクトリの下にextra_ca_certs/という名前の新しいディレクトリを作成します。必要なサイト固有のTLS証明書をこの新しいディレクトリにコピーします。

4.1. TLS証明書をRed Hat Quayに追加する
リンクのコピー

  1. コンテナに追加されるビュー証明書 

    $ cat storage.crt
-----BEGIN CERTIFICATE-----
MIIDTTCCAjWgAwIBAgIJAMVr9ngjJhzbMA0GCSqGSIb3DQEBCwUAMD0xCzAJBgNV
[...]
-----END CERTIFICATE-----
    Copy to Clipboard Toggle word wrap

  2. certsディレクトリを作成し、そこに証明書をコピーする 

    $ mkdir -p quay/config/extra_ca_certs
$ cp storage.crt quay/config/extra_ca_certs/
$ tree quay/config/
├── config.yaml
├── extra_ca_certs
│   ├── storage.crt
    Copy to Clipboard Toggle word wrap

  3. podman psでquayコンテナのCONTAINER IDを取得します。 

    $ sudo podman ps
CONTAINER ID        IMAGE                                COMMAND                  CREATED             STATUS              PORTS
5a3e82c4a75f        <registry>/<repo>/quay:v3.4.6 "/sbin/my_init"          24 hours ago        Up 18 hours         0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp, 443/tcp   grave_keller
    Copy to Clipboard Toggle word wrap

  4. そのIDでコンテナを再起動します。 

    $ sudo podman restart 5a3e82c4a75f
    Copy to Clipboard Toggle word wrap

  5. コンテナの名前空間にコピーされた証明書を調べます。 

    $ sudo podman exec -it 5a3e82c4a75f cat /etc/ssl/certs/storage.pem
-----BEGIN CERTIFICATE-----
MIIDTTCCAjWgAwIBAgIJAMVr9ngjJhzbMA0GCSqGSIb3DQEBCwUAMD0xCzAJBgNV
    Copy to Clipboard Toggle word wrap

4.2. Kubernetesへのデプロイ時に証明書を追加します。
リンクのコピー

Kubernetesにデプロイすると、Red Hat Quayはconfigアセットを保存するボリュームとしてシークレットにマウントします。残念ながら、これは現在、スーパーユーザーパネルの証明書のアップロード機能に干渉します。

このエラーを回避するには、Red Hat Quay が展開された後にbase64 エンコードされた証明書をシークレットに追加します。以下に、実行する方法を説明します。

  1. まず、証明書の内容をBase64エンコードします。 

    $ cat ca.crt
-----BEGIN CERTIFICATE-----
MIIDljCCAn6gAwIBAgIBATANBgkqhkiG9w0BAQsFADA5MRcwFQYDVQQKDA5MQUIu
TElCQ09SRS5TTzEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2
MDExMjA2NTkxMFoXDTM2MDExMjA2NTkxMFowOTEXMBUGA1UECgwOTEFCLkxJQkNP
UkUuU08xHjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTCCASIwDQYJKoZI
[...]
-----END CERTIFICATE-----

$ cat ca.crt | base64 -w 0
[...]
c1psWGpqeGlPQmNEWkJPMjJ5d0pDemVnR2QNCnRsbW9JdEF4YnFSdVd3PT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
    Copy to Clipboard Toggle word wrap

  2. kubectlツールを使って、quay-enterprise-config-secretを編集します。 

    $ kubectl --namespace quay-enterprise edit secret/quay-enterprise-config-secret
    Copy to Clipboard Toggle word wrap

  3. 証明書のエントリを追加し、エントリの下にbase64エンコードされた文字列を完全に貼り付けます。 

      custom-cert.crt:
c1psWGpqeGlPQmNEWkJPMjJ5d0pDemVnR2QNCnRsbW9JdEF4YnFSdVd3PT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
    Copy to Clipboard Toggle word wrap
  4. 最後に、すべての Red Hat Quay ポッドをリサイクルします。kubectl deleteを使用して、すべての Red Hat Quay ポッドを削除します。Red Hat Quay Deployment は、新しい証明書データを使用して交換用ポッドを自動的にスケジュールします。

第5章 Elasticsearchのアクションログストレージの設定
リンクのコピー

デフォルトでは、過去3ヶ月分の使用ログがRed Hat Quayデータベースに保存され、組織レベルとリポジトリレベルでウェブUIを介して公開されます。ログエントリを見るには、適切な管理者権限が必要です。大量の操作ログが記録されるデプロイメントでは、Red Hat Quay データベースバックエンドの代わりに Elasticsearch に使用ログを保存できるようになりました。これを行うには、独自のElasticsearchスタックを用意する必要があります。これは、カスタマイズ可能なコンポーネントとしてRed Hat Quayに含まれていないためです。

Elasticsearch のロギングを有効にするには、Red Hat Quay の展開中、または展開後に Red Hat Quay Config Tool を使用して行うことができます。出来上がった設定は、config.yamlファイルに格納されます。一度設定すれば、使用ログへのアクセスは、これまでと同様に、リポジトリや組織のWeb UIを介して提供されます。

ここでは、アクションログストレージをデフォルトのRed Hat QuayデータベースからElasticsearchを使用するように変更するための設定方法を説明します。

  1. Elasticsearchのアカウントを取得します。
  2. Red Hat Quay Config Tool を開きます（Red Hat Quay の展開中または展開後）。

  3. Action Log Storage Configuration設定までスクロールし、Databaseの代わりにElasticsearchを選択します。次の図は、表示されるElasticsearchの設定です。

    Choose Elasticsearch to view settings to store logs

  4. 使用するElasticsearchインスタンスの以下の情報を入力します。

    • Elasticsearchホスト名: Elasticsearchサービスを提供するシステムのホスト名またはIPアドレス。
    • Elasticsearchのポート: 先ほど入力したホストでElasticsearchサービスを提供しているポート番号です。ポートが、Red Hat Quay レジストリを実行しているすべてのシステムからアクセス可能でなければならないことに注意してください。デフォルトはTCP 9200番ポートです。
    • Elasticsearchのアクセスキー: 必要に応じて、Elasticsearchサービスにアクセスするために必要なアクセスキーです。
    • Elasticsearchの秘密鍵: 必要に応じて、Elasticsearchサービスにアクセスするために必要な秘密鍵。
    • AWSリージョン: AWS上で運用している場合は、AWSリージョンを設定します（そうでない場合は、空欄のままです）。
    • Index prefix: ログエントリに付けるプレフィックスを選択します。

    • Logs Producer: Elasticsearch（デフォルト）またはKinesisのいずれかを選択し、ログをAWS上の中間的なKinesisストリームに導きます。KinesisからElasticsearch（Logstashなど）にログを送るためには、独自のパイプラインを設定する必要があります。次の図は、Kinesisに必要な追加フィールドを示しています。

      On AWS

  5. Logs ProducerとしてElasticsearchを選択した場合、これ以上の設定は必要ありません。Kinesisを選択した場合、以下を記入してください。

    • ストリーム名: Kinesisのストリームの名前です。
    • AWSのアクセスキー: Kinesisストリームへのアクセスを得るために必要なAWSアクセスキーの名前（必要な場合）。
    • AWSの秘密鍵: Kinesisストリームにアクセスするために必要なAWSのシークレットキーの名前（必要な場合）。
    • AWSリージョン: AWSのリージョンです。
  6. 完了したら、設定を保存します。Config Tool が設定内容を検証します。ElasticsearchまたはKinesisサービスへの接続に問題がある場合は、エラーが表示され、編集を続ける機会が与えられます。そうしないと、新しい設定に伴いでクラスタが再起動した後に、ロギングがあなたのElasticsearch設定に対して開始されます。

第6章 クレアセキュリティスキャン
リンクのコピー

6.1. Clairとは?
リンクのコピー

Clairは、Red Hat Quayと共に使用できるマイクロサービスのセットで、一連のLinuxオペレーティングシステムに関連付けられたコンテナイメージの脆弱性スキャンを実行します。Clairのマイクロサービス設計は、エンタープライズ環境に合わせてコンポーネントを個別に拡張できるような、高いスケーラビリティを持った構成で実行するのに適しています。

クレアは、以下の脆弱性データベースを利用して、お客様の画像の問題点をスキャンします。

  • アルパインSecDBデータベース
  • AWS UpdateInfo
  • Debian Ovalデータベース
  • Oracle Ovalデータベース
  • RHEL Ovalデータベース
  • SUSE Ovalデータベース
  • Ubuntu Ovalデータベース
  • Pyup.io (python)データベース

Clairが異なるデータベースとのセキュリティマッピングを行う方法については、ClairCore Severity Mappingを参照してください。

注記

Red Hat Quay 3.4のリリースに伴い、新しいClair V4 (image registry.redhat.io/quay/clair-rhel8)が以前のClair V2 (image quay.io/redhat/clair-jwt)を完全に置き換えました。V4のアップデート中にV2をリードオンリーモードで動作させる方法は以下を参照してください。

6.1.1. Clair V4とClair V2の同時実行について
リンクのコピー

Clair V4 (registry.redhat.io/quay/clair-rhel8:v3.4.6) は Red Hat Quay が使用している Clair のバージョンですが、Clair V4 とそれ以前の Clair V2 (quay.io/redhat/clair-jwt) の両方が Red Hat Quay と同時に実行可能となっています。これは、Clair V2に依存していたが、Clair V4を使用してスキャン結果を中断しないようにしたいという、既存のRed Hat Quayのデプロイメントに有効です。新しい画像のスキャンはすべてClair V4で行われ、既存の画像は自動的に再スキャンされます。Red Hat Quayを通じてスキャン結果が要求された場合、新しいClair V4の結果が利用できない場合は、既存のClair V2の結果が取得されます。Clair V2のスキャン結果が不要になったら、デコミッションしてRed Hat Quayの構成から削除することができます。

画像の再スキャンの進行状況は、Red Hat Quay APIを介して監視することができます。(詳細はUsing The Quay APIを参照してください） 

/secscan/_backfill_status
Copy to Clipboard Toggle word wrap

これにより、Clair V4でスキャンされたマニフェストの完成率を示すシンプルなJSONレスポンスが生成されます。 

{"backfill_percent": 73.4}
Copy to Clipboard Toggle word wrap

レジストリ内の大部分のイメージがClair V4によってスキャンされたら、Clair V2のデプロイメントを完全に削除する必要があります（実行中のコンテナとコンフィグからの削除の両方）。

6.2. Red Hat Quay OpenShift deloymentでのClairのセットアップ
リンクのコピー

6.2.1. Quay Operatorによるデプロイ
リンクのコピー

OpenShift上の新しいRed Hat QuayデプロイメントにClair V4をセットアップするには、Quay Operatorを使用することを強くお勧めします。デフォルトでは、Quay Operatorは、Red Hat QuayのデプロイとともにClairのデプロイメントをインストールまたはアップグレードし、Clairのセキュリティスキャンを自動的に構成します。

6.2.2. 手動でClairを展開する
リンクのコピー

Clair V2を実行している既存のRed Hat Quay OpenShiftデプロイメントにClair V4を設定するには、まずRed Hat Quayが少なくともバージョン3.4.0にアップグレードされていることを確認します。その後、以下の手順でClair V4をClair V2と一緒に手動で設定します。

  1. 現在のプロジェクトを、Red Hat Quay が実行されているプロジェクトの名前に設定します。例: 

    $ oc project quay-enterprise
    Copy to Clipboard Toggle word wrap

  2. Clair v4用のPostgres展開ファイル（例: clairv4-postgres.yaml）を以下のように作成します。

    clairv4-postgres.yaml

    ---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: clairv4-postgres
  namespace: quay-enterprise
  labels:
    quay-component: clairv4-postgres
spec:
  replicas: 1
  selector:
    matchLabels:
      quay-component: clairv4-postgres
  template:
    metadata:
      labels:
        quay-component: clairv4-postgres
    spec:
      volumes:
        - name: postgres-data
          persistentVolumeClaim:
            claimName: clairv4-postgres
      containers:
        - name: postgres
          image: postgres:11.5
          imagePullPolicy: "IfNotPresent"
          ports:
            - containerPort: 5432
          env:
            - name: POSTGRES_USER
              value: "postgres"
            - name: POSTGRES_DB
              value: "clair"
            - name: POSTGRES_PASSWORD
              value: "postgres"
            - name: PGDATA
              value: "/etc/postgres/data"
          volumeMounts:
            - name: postgres-data
              mountPath: "/etc/postgres"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: clairv4-postgres
  labels:
    quay-component: clairv4-postgres
spec:
  accessModes:
    - "ReadWriteOnce"
  resources:
    requests:
      storage: "5Gi"
    volumeName: "clairv4-postgres"
---
apiVersion: v1
kind: Service
metadata:
  name: clairv4-postgres
  labels:
    quay-component: clairv4-postgres
spec:
  type: ClusterIP
  ports:
    - port: 5432
      protocol: TCP
      name: postgres
      targetPort: 5432
  selector:
    quay-component: clairv4-postgres
    Copy to Clipboard Toggle word wrap

  3. 以下のように、postgresデータベースをデプロイします。 

    $ oc create -f ./clairv4-postgres.yaml
    Copy to Clipboard Toggle word wrap

  4. Clair v4で使用するClairconfig.yamlファイルを作成します。例:

    config.yaml

    introspection_addr: :8089
http_listen_addr: :8080
log_level: debug
indexer:
  connstring: host=clairv4-postgres port=5432 dbname=clair user=postgres password=postgres sslmode=disable
  scanlock_retry: 10
  layer_scan_concurrency: 5
  migrations: true
matcher:
  connstring: host=clairv4-postgres port=5432 dbname=clair user=postgres password=postgres sslmode=disable
  max_conn_pool: 100
  run: ""
  migrations: true
  indexer_addr: clair-indexer
# tracing and metrics
trace:
  name: "jaeger"
  probability: 1
  jaeger:
    agent_endpoint: "localhost:6831"
    service_name: "clair"
metrics:
  name: "prometheus"
    Copy to Clipboard Toggle word wrap

Clairの設定フォーマットについての詳細は、upstream Clair documentationに記載されています。

  1. Clairのconfig.yamlからシークレットを作成します。 

    $ oc create secret generic clairv4-config-secret --from-file=./config.yaml
    Copy to Clipboard Toggle word wrap

  2. Clair v4のデプロイメントファイル（例: clair-combo.yaml）を作成し、必要に応じて修正します。

    clair-combo.yaml

    ---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    quay-component: clair-combo
  name: clair-combo
spec:
  replicas: 1
  selector:
    matchLabels:
      quay-component: clair-combo
  template:
    metadata:
      labels:
        quay-component: clair-combo
    spec:
      containers:
        - image: registry.redhat.io/quay/clair-rhel8:v3.4.6
    1 
    
          imagePullPolicy: IfNotPresent
          name: clair-combo
          env:
            - name: CLAIR_CONF
              value: /clair/config.yaml
            - name: CLAIR_MODE
              value: combo
          ports:
            - containerPort: 8080
              name: clair-http
              protocol: TCP
            - containerPort: 8089
              name: clair-intro
              protocol: TCP
          volumeMounts:
            - mountPath: /clair/
              name: config
      imagePullSecrets:
        - name: redhat-pull-secret
      restartPolicy: Always
      volumes:
        - name: config
          secret:
            secretName: clairv4-config-secret
---
apiVersion: v1
kind: Service
metadata:
  name: clairv4
    2 
    
  labels:
    quay-component: clair-combo
spec:
  ports:
    - name: clair-http
      port: 80
      protocol: TCP
      targetPort: 8080
    - name: clair-introspection
      port: 8089
      protocol: TCP
      targetPort: 8089
  selector:
    quay-component: clair-combo
  type: ClusterIP
    Copy to Clipboard Toggle word wrap

    1
    画像を最新のクレアの画像名とバージョンに変更します。
    2
    サービスを clairv4 に設定すると、Clair v4 のスキャナーエンドポイントは、Red Hat Quay の config.yaml のSECURITY_SCANNER_V4_ENDPOINTに以下のように入力します。 http://clairv4.

  3. 以下のようにClair v4の配置を作成します。 

    $ oc create -f ./clair-combo.yaml
    Copy to Clipboard Toggle word wrap

  4. Red Hat Quay 配置のconfig.yamlファイルを変更して、最後に以下のエントリを追加します。 

    FEATURE_SECURITY_SCANNER: true
SECURITY_SCANNER_V4_ENDPOINT: http://clairv4
    1
    Copy to Clipboard Toggle word wrap
    1
    Clair v4サービスのエンドポイントの特定

  5. 修正したconfig.yamlを、そのファイルを含むシークレット（例えば、quay-enterprise-config-secret）に再デプロイします。 

    $ oc delete secret quay-enterprise-config-secret
$ oc create secret generic quay-enterprise-config-secret --from-file=./config.yaml
    Copy to Clipboard Toggle word wrap
  6. 新しいconfig.yamlを有効にするには、Red Hat Quay のポッドを再起動する必要があります。quay-appのポッドを削除するだけで、更新された構成のポッドがデプロイされます。

この時点で、名前空間のホワイトリストで特定された組織の画像は、Clair v4によってスキャンされます。

6.3. OpenShiftではないRed Hat QuayのデプロイメントにClairをセットアップする
リンクのコピー

OpenShift上で稼働していないRed Hat Quayのデプロイメントでは、Clairのセキュリティスキャンを手動で設定することが可能です。すでにClair V2を実行しているRed Hat Quayのデプロイメントは、以下の手順でClair V4をデプロイメントに追加することができます。

  1. (フォールトトレラントが望ましい)Postgresデータベースサーバを導入します。なお、ClairはPostgresデータベースにuuid-osspエクステンションを追加する必要があります。Clairのconfig.yamlで指定されたユーザーが、拡張機能を作成するのに必要な権限を持っている場合、Clair自身によって自動的に追加されます。そうでない場合は、Clairを起動する前に拡張機能を追加する必要があります。この拡張子がない場合、Clairを起動しようとすると以下のエラーが表示されます。 

    ERROR: Please load the "uuid-ossp" extension. (SQLSTATE 42501)
    Copy to Clipboard Toggle word wrap

  2. 特定のフォルダにClairの設定ファイルを作成する（例/etc/clairv4/config/config.yaml）ファイルです。

    config.yaml

    introspection_addr: :8089
http_listen_addr: :8080
log_level: debug
indexer:
  connstring: host=clairv4-postgres port=5432 dbname=clair user=postgres password=postgres sslmode=disable
  scanlock_retry: 10
  layer_scan_concurrency: 5
  migrations: true
matcher:
  connstring: host=clairv4-postgres port=5432 dbname=clair user=postgres password=postgres sslmode=disable
  max_conn_pool: 100
  run: ""
  migrations: true
  indexer_addr: clair-indexer
notifier:
  connstring: host=clairv4-postgres port=5432 dbname=clair user=postgres password=postgres sslmode=disable
  delivery_interval: 1m
  poll_interval: 5m
  migrations: true

# tracing and metrics
trace:
  name: "jaeger"
  probability: 1
  jaeger:
    agent_endpoint: "localhost:6831"
    service_name: "clair"
metrics:
  name: "prometheus"
    Copy to Clipboard Toggle word wrap

Clairの設定フォーマットについての詳細は、upstream Clair documentationに記載されています。

  1. コンテナイメージ経由でClairを実行し、作成したファイルから設定をマウントします。 

    $ podman run -p 8080:8080 -p 8089:8089 -e CLAIR_CONF=/clair/config.yaml -e CLAIR_MODE=combo -v /etc/clair4/config:/clair -d registry.redhat.io/quay/clair-rhel8:v3.4.6
    Copy to Clipboard Toggle word wrap
  2. 新しいClair V4エンドポイントを使用するためにRed Hat Quayを設定するには、前のセクションの残りの指示に従ってください。

この形で複数のClairコンテナを実行することも可能ですが、1つのコンテナを超えるデプロイメントシナリオでは、KubernetesやOpenShiftなどのコンテナオーケストレーターの使用を強く推奨します。

6.4. クレールの使用
リンクのコピー

  1. Red Hat Quayクラスターにログインし、Clairスキャンを設定した組織を選択します。

  2. その組織からいくつかの画像を保持するリポジトリを選択し、左のナビゲーションから「タグ」を選択します。次の図は、2枚の画像がスキャンされたリポジトリの例です。

    Security scan information appears for scanned repository images

  3. 脆弱性が発見された場合、画像のセキュリティスキャン欄を選択すると、すべての脆弱性または修正可能な脆弱性が表示されます。次の図は、見つかったすべての脆弱性の情報を示しています。

    See all vulnerabilities or only those that are fixable

6.5. クレアの通知
リンクのコピー

Clairは、以前にインデックスされたマニフェストに影響を与える新たな脆弱性を受信すると、Red Hat Quayに通知し、新たなスキャンを要求できるようにします。過剰なスキャン要求を避けるため、最も深刻な脆弱性のみが通知のトリガーとなります。この通知メカニズムは、ClairがRed Hat Quayの構成で設定されると自動的に設定されます。

また、Clairの通知は、AMQPやSTOMPのプロトコルを使って外部に提供することもできます。設定方法の詳細については、upstream Clair documentationを参照してください。

6.6. 切断された環境のためのClairの設定
リンクのコピー

Clairは、アップデータと呼ばれる一連のコンポーネントを利用して、様々な脆弱性データベースからのデータのフェッチとパースを処理します。これらのアップデータは、インターネットから直接脆弱性データを取得するようにデフォルトで設定されており、すぐに使用することができます。インターネットに直接アクセスできない切断された環境にいるお客様にとっては、これは問題となります。クレアは、ネットワークの分離を考慮した様々なタイプのアップデートワークフローに対応することで、これらの環境をサポートします。clairctlコマンドラインユーティリティを使用すると、どのプロセスでも、オープンホスト経由でインターネットからアップデータを取得し、そのデータを隔離されたホストに安全に転送し、隔離されたホスト上のアップデータをClair本体にインポートすることが簡単にできます。

その手順は以下の通りです。

  1. まず、Clairの設定で、自動化されたアップデータの実行が無効になっていることを確認してください。

    config.yaml

    matcher:
  disable_updaters: true
    Copy to Clipboard Toggle word wrap

  2. 最新のアップデータをローカルのアーカイブに書き出します。このためには、バイナリとして直接実行するか、Clairコンテナイメージを介して実行できるclairctlツールが必要です。コンテナイメージ経由で実行するために、Clairの設定が/etc/clairv4/config/config.yamlにあるとします。 

    $ podman run -it --rm -v /etc/clairv4/config:/cfg:Z -v $(pwd):/updaters:Z --entrypoint /bin/clairctl registry.redhat.io/quay/clair-rhel8:v3.4.6 export-updaters --config /cfg/config.yaml /updaters/updaters.gz
    Copy to Clipboard Toggle word wrap

    なお、Clairの設定を細かく参照する必要があります。これにより、/etc/clairv4/updaters/updaters.gzにアップデータのアーカイブが作成されます。ソースデータベースからエラーなくアーカイブが作成されたことを確認したい場合は、clairctlに--strictフラグを指定します。アーカイブファイルは、Clairを起動している切断されたホストからアクセス可能なボリュームにコピーしてください。切断されたホストから、今度は同じ手順でClairにアーカイブをインポートします。 

    $ podman run -it --rm -v /etc/clairv4/config:/cfg:Z -v $(pwd):/updaters:Z --entrypoint /bin/clairctl registry.redhat.io/quay/clair-rhel8:v3.4.6 import-updaters --config /cfg/config.yaml /updaters/updaters.gz
    Copy to Clipboard Toggle word wrap

6.7. 追加情報
リンクのコピー

マイクロサービスがどのように構成されているかなど、Clairの内部に関する詳細なドキュメントは、Upstream ClairおよびClairCoreのドキュメントを参照してください。

第7章 Container Security Operator でポッドイメージをスキャン
リンクのコピー

Container Security Operator（CSO）を使用すると、OpenShift（4.2以降）やその他のKubernetesプラットフォーム上で動作するアクティブなポッドに関連するコンテナイメージをスキャンし、既知の脆弱性を確認することができます。CSV

  • すべての namespace または指定された namespace の Pod に関連付けられたコンテナーを監視します。
  • イメージのレジストリがイメージスキャンをサポートしている場合（Clairスキャンを備えたQuayレジストリなど）、コンテナの元となったコンテナレジストリに脆弱性情報を問い合わせます。
  • Kubernetes API の ImageManifestVuln オブジェクトを使用して脆弱性を公開します。

この手順を使用すると、CSO は marketplace-operators namespace にインストールされ、OpenShift クラスターのすべての namespace で利用可能になります。

注記

CSOをKubernetesにインストールする手順を見るには、Container Security OperatorHub.ioのページからInstallボタンを選択します。

7.1. OpenShiftでのCSOの実行
リンクのコピー

OpenShiftでCSOの使用を開始するには、次のようにします。

  1. Operators → OperatorHub（Securityを選択）で、利用可能なContainer SecurityOperatorが表示されます。
  2. Container Security Operator を選択し、Install を選択して Create Operator Subscriptionページに移動します。
  3. 設定（デフォルトでは、全ネームスペースと自動承認戦略）を確認し、Subscribeを選択します。しばらくすると、Installed Operators画面にContainer Securityが表示されます。

  4. オプションで、カスタム証明書を CSO に追加できます。以下の例では、現在のディレクトリーに quay.crt という名前の証明書を作成します。その後、次のコマンドを実行して、CSOに証明書を追加します（新しい証明書を有効にするために、Operatorポッドを再起動します）。 

    $ oc create secret generic container-security-operator-extra-certs --from-file=quay.crt -n openshift-operators
    Copy to Clipboard Toggle word wrap

  5. OpenShift Dashboardを開きます（Home → Dashboards）。Image Security へのリンクが status セクションに表示され、これまでに見つかった脆弱性の数の一覧が表示されます。リンクを選択すると、次の図のようにセキュリティの内訳が表示されます。

    Access SCO scanning data from OpenShift dashboard

  6. この時点で、検出された脆弱性をフォローするために以下の 2 つのいずれかの操作を実行できます。

    • 脆弱性へのリンクを選択します。コンテナのレジストリ、Red Hat Quay、またはコンテナが入ってきたその他のレジストリに移動し、脆弱性に関する情報が表示されます。以下の図は、Quay.io レジストリーから検出された脆弱性の例を示しています。

      The CSO points you to a registry containing the vulnerable image

    • namespacesのリンクを選択すると、ImageManifestVuln画面が表示され、選択したイメージの名前と、そのイメージが実行されているすべてのネームスペースが表示されます。次の図は、ある脆弱なイメージが2つのネームスペースで実行されていることを示しています。

      View namespaces a vulnerable image is running in

この時点では、脆弱性のあるイメージや、イメージの脆弱性を解決するために必要なこと、およびイメージが実行されたすべての namespace を確認できます。以下を実行することができます。

  • 脆弱性を修正する必要のあるイメージを実行しているユーザーに警告します。
  • イメージが置かれている Pod を起動したデプロイメントまたは他のオブジェクトを削除して、イメージの実行を停止します。

なお、ポッドを削除した場合、ダッシュボード上で脆弱性がリセットされるまでに数分かかることがあります。

7.2. CLIからイメージの脆弱性を問い合わせる
リンクのコピー

コマンドラインからセキュリティに関する情報を照会することができます。検出された脆弱性を照会するには、次のように入力します。 

$ oc get vuln --all-namespaces
NAMESPACE     NAME              AGE
default       sha256.ca90...    6m56s
skynet        sha256.ca90...    9m37s
Copy to Clipboard Toggle word wrap

特定の脆弱性の詳細を表示するには、脆弱性の1つを特定し、その名前空間とdescribeオプションを指定します。以下の例は、イメージに脆弱性のある RPM パッケージが含まれるアクティブなコンテナーを示しています。 

$ oc describe vuln --namespace mynamespace sha256.ac50e3752...
Name:         sha256.ac50e3752...
Namespace:    quay-enterprise
...
Spec:
  Features:
    Name:            nss-util
    Namespace Name:  centos:7
    Version:         3.44.0-3.el7
    Versionformat:   rpm
    Vulnerabilities:
      Description: Network Security Services (NSS) is a set of libraries...
Copy to Clipboard Toggle word wrap

第8章 Bridge Operator でRed Hat QuayをOpenShiftに統合する
リンクのコピー

Quay Bridge Operator を使用すると、OpenShift の統合コンテナレジストリを Red Hat Quay レジストリで置き換えることができます。これにより、統合されたOpenShiftレジストリは、ロールベースのアクセスコントロール（RBAC）機能が強化された、可用性の高いエンタープライズグレードのRed Hat Quayレジストリになります。

Bridge Operatorの主な目的は、統合されたOpenShiftレジストリの機能を、新しいRed Hat Quayレジストリに複製することです。このオペレーターで可能な機能は以下の通りです。

  • Red Hat Quay の組織として OpenShift の名前空間を同期させます。

    • デフォルトネームスペースのサービスアカウントごとのロボットアカウントの作成
    • 作成されたロボットアカウントごとにシークレットを作成（各ロボットシークレットをサービスアカウントにMountableとImage Pull Secretとして関連付ける）。
    • OpenShiftのImageStreamをQuayのリポジトリとして同期させる
  • Red Hat Quay に出力するために ImageStream を使用して新しいビルドを自動的に書き換えます。
  • ビルドが完了すると自動的にImageStreamタグをインポートする

この手順をQuay Bridge Operatorで使用すると、Red Hat QuayとOpenShiftクラスター間の双方向通信が可能になります。

警告

Quay Bridge Operator から同じ Red Hat Quay インスタンスを指している OpenShift Container Platform クラスタを複数にすることはできません。そうすると、2つのクラスターに同じ名前の名前空間を作ることができなくなります。

8.1. Quay Bridge Operator の実行
リンクのコピー

8.1.1. 前提条件
リンクのコピー

Bridge Operatorをセットアップする前に、以下のものを用意してください。

  • スーパーユーザー権限を持つ既存の Red Hat Quay 環境
  • クラスタ管理者権限を持つRed Hat OpenShift Container Platform環境（4.2以降を推奨）。
  • OpenShiftのコマンドラインツール(ocコマンド)

8.1.2. OpenShiftとRed Hat Quayのセットアップと設定
リンクのコピー

Red Hat QuayとOpenShiftの両方の設定が必要です。

8.1.2.1. Red Hat Quay のセットアップ
リンクのコピー

Red Hat Quay の専用組織を作成し、その組織内で作成した新規アプリケーションから、OpenShift の Quay Bridge Operator で使用する OAuth トークンを生成します。

  1. スーパーユーザー権限を持つユーザーとしてRed Hat Quayにログインし、外部アプリケーションを設定する組織を選択します。
  2. 左のナビゲーションで Applications を選択します。
  3. Create New Applicationを選択し、新しいアプリケーションの名前を入力します（例: openshift）。
  4. 新しいアプリケーションが表示された状態で、それを選択します。
  5. 左側のナビゲーションでGenerate Tokenを選択し、新しいOAuth2トークンを作成します。
  6. すべてのチェックボックスを選択して、統合に必要なアクセスを許可します。
  7. 割り当てられた権限を確認し、Authorize Applicationを選択して確認します。
  8. 生成されたAccess Tokenは、次のセクションで使用するためにコピーして保存します。
8.1.2.2. OpenShift のセットアップ
リンクのコピー

Quay Bridge OperatorにOpenShiftをセットアップするには、以下のようないくつかのステップが必要です。

  • OpenShiftシークレットの作成: Quayで先に作成したOAuthトークンを使って、OpenShiftシークレットを作成します。
  • MutatingWebhookConfiguration のサポートを追加: OpenShift と Red Hat Quay の統合をサポートするために、新しい Build リクエストをインターセプトして、OpenShift の統合レジストリではなく Red Hat Quay をターゲットにするように出力を変更できるようにします。

OpenShift の典型的なビルドプロセスの一部として実行される API リクエストの動的な傍受のサポートは、MutatingWebhookConfiguration によって促進されます。MutatingWebhookConfigurationは、特定のAPIリクエストを受信したときに、OpenShift上のプロジェクト内で実行されているAPIを起動することができます。

Kubernetesでは、Webhookエンドポイントがクラスタの証明機関を利用した証明書を用いてSSLで保護されている必要があります。幸いなことに、OpenShiftはクラスタで署名された証明書の生成をサポートしています。

  1. OpenShiftocコマンドラインツールを使用して、クラスタ管理者として OpenShift にログインします。
  2. openshift-operatorsなど、使用するOpenShiftネームスペースを選択するか、新しいネームスペースを作成します。

  3. OpenShiftのシークレットを作成し、<access_token>を先ほどRed Hat Quayから取得したAccess Tokenに置き換えます。例えば、これはあなたの<access_token>を使ってquay-integrationというシークレットをtokenというキーで作成します。 

    $ oc create secret generic quay-integration --from-literal=token=<access_token>
    Copy to Clipboard Toggle word wrap

    その結果、新たに作成された秘密鍵と証明書が、指定された秘密の中に配置されます。シークレットは、Operatorのデプロイメントでの宣言の通りに、オペレーター内の適切な場所にマウントされます。

  4. OperatorのWebhookエンドポイントのServiceを作成します。

    quay-webhook.yaml

    apiVersion: v1
kind: Service
metadata:
  labels:
    name: quay-bridge-operator
  name: quay-bridge-operator
  namespace: openshift-operators
spec:
  ports:
    - name: https
      port: 443
      protocol: TCP
      targetPort: 8443
  selector:
    name: quay-bridge-operator
  sessionAffinity: None
  type: ClusterIP
    Copy to Clipboard Toggle word wrap

  5. 次のようにWebhookサービスを作成します。 

    $ oc create -f quay-webhook.yaml
    Copy to Clipboard Toggle word wrap
  6. webhook-create-signed-cert.shスクリプトをダウンロードして、Kubernetes認証局で署名された証明書を生成するために使用できるようにします。

  7. 以下のコマンドを実行して、証明書を要求します。 

    $ ./webhook-create-signed-cert.sh --namespace openshift-operators \
   --secret quay-bridge-operator-webhook-certs \
   --service quay-bridge-operator
    Copy to Clipboard Toggle word wrap

  8. 以下のコマンドを実行してCAを取得し、その結果を1行にまとめてMutatingWebhookConfigurationリソースに入力できるようにします。 

    $ oc get configmap -n kube-system \
   extension-apiserver-authentication \
   -o=jsonpath='{.data.client-ca-file}' | base64 | tr -d '\n'
    Copy to Clipboard Toggle word wrap

  9. 以下のMutatingWebhookConfigurationのYAMLで、${CA_BUNDLE}変数を置き換えてください。

    quay-mutating-webhook.yaml

    apiVersion: admissionregistration.k8s.io/v1beta1
kind: MutatingWebhookConfiguration
metadata:
  name: quay-bridge-operator
webhooks:
  - name: quayintegration.redhatcop.redhat.io
    clientConfig:
      service:
        namespace: openshift-operators
        name: quay-bridge-operator
        path: "/admissionwebhook"
      caBundle: "${CA_BUNDLE}"
    1 
    
    rules:
    - operations:  [ "CREATE" ]
      apiGroups: [ "build.openshift.io" ]
      apiVersions: ["v1" ]
      resources: [ "builds" ]
    failurePolicy: Fail
    Copy to Clipboard Toggle word wrap

    1
    ${CA_BUNDLE}を前のステップの出力で置き換えます。これは、${CA_BUNDLE}を置き換えるためにコピー＆ペーストする1つの長い行として表示されます。

  10. 以下のようにMutatingWebhookConfigurationを作成します。 

    $ oc create -f quay-mutating-webhook.yaml
    Copy to Clipboard Toggle word wrap

    オペレータが動作するまでは、MutatingWebhookConfigurationが呼び出すWebサーバが利用できず、オブジェクトをetcdに永続化するために適切なisレスポンスが必要となるため、ビルドに対する新しいリクエストは失敗します。

  11. OpenShiftのコンソールに移動し、以下のようにQuay Bridge Operatorをインストールします。

    • OperatorHubを選択し、Quay Bridge Operatorを検索します。
    • インストールを選択します。
    • インストールモード（全ネームスペース）、アップデートチャンネル、承認方法（自動または手動）を選択します。
    • Subscribe を選択します。

  12. QuayIntegrationというカスタムリソース（CR）を作成します。例:

    quay-integration.yaml

    apiVersion: redhatcop.redhat.io/v1alpha1
kind: QuayIntegration
metadata:
  name: example-quayintegration
spec:
  clusterID: openshift
    1 
    
  credentialsSecretName: openshift-operators/quay-integration
    2 
    
  quayHostname: https://<QUAY_URL>
    3 
    
  whitelistNamespaces:
    4 
    
    - default
  insecureRegistry: false
    5
    Copy to Clipboard Toggle word wrap

    1
    clusterIDの値は、エコシステム全体で一意でなければなりません。この値はオプションで、デフォルトではopenshiftが使用されます。
    2
    credentialsSecretNameには、openshift-operators/quay-integrationを名前空間の名前と、先に作成したトークンを含むシークレットに置き換えます。
    3
    QUAY_URL を Red Hat Quay インスタンスのホスト名に置き換えてください。
    4
    whitelistNamespacesはオプションです。使用しない場合、Bridge Operatorはopenshiftの接頭辞を持つプロジェクトを除くすべての名前空間をRed Hat Quayに同期します。この例では、ホワイトリストのネームスペース（デフォルト）に、Red Hat Quay の組織が関連付けられています。ここでは、好きな名前空間を使用してください。
    5
    Quayが自己署名証明書を使用している場合、プロパティinsecureRegistry: trueを設定します。

    その結果、Red Hat Quay内の組織は、OpenShiftの関連する名前空間のために作成する必要があります。

  13. 以下のようにQuayIntegrationを作成します。 

    $ oc create -f quay-integration.yaml
    Copy to Clipboard Toggle word wrap

この時点でQuayの統合リソースが作成され、OpenShiftクラスタとRed Hat Quayインスタンスがリンクされます。

作成したホワイトリストの名前空間には、Red Hat Quay の組織があるはずです。oc new-appのようなコマンドを使用してその名前空間に新しいアプリケーションを作成すると、内部レジストリを使用する代わりに、新しい Red Hat Quay リポジトリが作成されます。

第9章 Red Hat Quayにおけるリポジトリミラーリング
リンクのコピー

Red Hat Quay のリポジトリミラーリングでは、外部のコンテナレジストリ（またはローカルレジストリ）からローカルの Red Hat Quay クラスタにイメージをミラーリングすることができます。リポジトリミラーリングを使用すると、リポジトリ名とタグに基づいてイメージを Red Hat Quay に同期させることができます。

9.1. リポジトリミラーリングの概要
リンクのコピー

リポジトリのミラーリングを有効にした Red Hat Quay クラスタから、以下のことができます。

  • 外部のレジストリからミラーリングするリポジトリを選択
  • 外部レジストリにアクセスするための認証情報の追加
  • リポジトリを同期する間隔の設定
  • 同期するコンテナイメージのリポジトリ名とタグを特定する
  • 現在の同期状態の確認

リポジトリミラーリングでは、2つ以上の異なるレジストリ間のコンテンツの特定のサブセットを、選択したデータセンター、クラスター、またはリージョンにミラーリングします。対照的に、Georeplicationは単一のグローバルに分散されたRed Hat Quayを提供し、ローカライズされたストレージからコンテナイメージを提供します。この2つのコンテンツ共有方法は、次のような点で異なります。

Expand
表9.1 Red Hat Quay リポジトリミラーリングとの比較ジオレプリーション

機能と性能

ジオレプリーション

リポジトリーのミラーリング

この機能は何のために設計されたのでしょうか?

グローバルに共有されるレジストリ

独立した異なるレジストレーション

レプリケーションやミラーリングがまだ完了していない場合はどうなりますか?

リモートコピーを使用する（遅くなります）

画像が表示されない

両地域のすべてのストレージバックエンドへのアクセスが必要ですか?

はい（すべてのRed Hat Quayノード）。

いいえ（個別のストレージ

ユーザーは両方のサイトの画像を同じリポジトリにプッシュできますか?

可

不可

すべてのレジストリの内容と構成がすべての地域で同一であるか（共有データベース

可

不可

ユーザーはミラーリングする個別の namespace またはリポジトリーを選択できるか?

デフォルトでは、いいえ。

可

ユーザーは同期ルールにフィルターを適用できますか?

不可

可

ここでは、Red Hat Quay のリポジトリミラーリングを使用するためのヒントをいくつか紹介します。

  • リポジトリミラーリングでは、リポジトリ全体をミラーリングしたり、タグのカンマ区切りリストやタグの範囲、あるいは正規表現やグロブを使ったタグの識別手段に基づいて、同期する画像を選択的に制限することができます。
  • ミラーリングされたリポジトリとして設定されると、そのリポジトリに他のイメージを手動で追加することはできません。
  • ミラーリングされたリポジトリは、設定されたリポジトリとタグに基づいているため、レポ/タグのペアで表されるコンテンツのみを保持します。つまり、タグを変更してリポジトリの一部の画像が一致しなくなった場合、その画像は削除されます。
  • 指定されたロボットだけが、ミラーリングされたリポジトリに画像をプッシュすることができ、リポジトリに設定されたロールベースのアクセスコントロール権限に優先します。
  • ミラーリングされたリポジトリでは、ユーザーは（読み取り権限を与えられて）リポジトリからイメージを引き出すことはできますが、リポジトリにイメージをプッシュすることはできません。
  • ミラーリングされたリポジトリーの設定の変更は、作成するミラーリングされたリポジトリーについてのRepositoriesページのMirrorsタブから行われます。
  • 画像は一定の間隔で同期されますが、必要に応じて同期することもできます。

9.2. 前提条件
リンクのコピー

リポジトリミラーリングを使用する前に、Red Hat Quay の構成画面からリポジトリミラーリングを有効にし、リポジトリミラーリングワーカーを起動する必要があります。このサービスを起動する方法は、Red Hat Quay のデプロイメントガイドに記載されています。

以下のセクションで示す手順は、すでにリポジトリミラーリングサービスが稼働しており、Red Hat Quay クラスタでリポジトリミラーリングが有効になっていることを前提としています。

9.3. ミラーリングされたリポジトリの作成
リンクのコピー

外部のコンテナレジストリから外部のリポジトリをミラーリングするには、次のようにします。

  1. Red Hat Quay のレジストリにログインします。

  2. ミラーリングされたリポジトリのイメージを引き出すためのロボットアカウントを作成します。

    • 右上のドロップダウンからAccount Settingsを選択します。
    • 左の列にあるRobot Accountsボタンを選択します。
    • Create Robot Accountを選択します。
    • ロボットアカウントの名前と説明を追加し、Create robot accountを選択します。
    • 追加するミラーリングされたリポジトリはまだ存在していないので、「閉じる」を選択します。
    • リストからROBOT ACCOUNT NAMEを選択します。
    • プロンプトが表示されたら、ロボットがミラーリングするリポジトリの外部レジストリにアクセスするために必要な認証情報を追加し、[認証情報]ウィンドウを閉じます。
  3. REPOSITORIESを選択します。
  4. Create New Repositoryを選択し、名前をつけます。
  5. リポジトリ名を入力し、パブリックまたはプライベートを選択して、Create Repositoryを選択します。
  6. 設定ボタンを選択し、リポジトリの状態をMIRRORに変更します。
  7. 新しいリポジトリを開き、左カラムのミラーリングボタンを選択します。

  8. 新しいリポジトリでミラーリングするリポジトリを識別するためのフィールドを入力します。

    • Registry URL: ミラーリングしたいコンテナレジストリの場所。
    • User or Organization: 通常は、ミラーリングするコンテンツに関連するアカウント名です。例えば、画像 registry.example.com/jsmith/myimage:latest の場合、jsmith はここに入力します。
    • Repository Name: 画像のセットの名前を識別する名前です。例えば、画像 registry.example.com/jsmith/myimage:latest の場合、myimage はここに入力します。
    • Sync Interval:デフォルトでは24時間ごとに同期します。時間や日にちに基づいて変更することができます。
    • Robot User: ミラーリングを行うために先に作成したロボットアカウントを選択します。
    • Username: ミラーリングするリポジトリを保持する外部レジストリにログインするためのユーザー名です。
    • Password: Usernameに関連するパスワードです。なお、パスワードには、エスケープ文字が必要な文字を含むことはできません（※）。
    • Start Date: ミラーリングを開始する日付です。デフォルトで使用される現在の日付と時刻。
    • Verify TLS: 外部レジストリの信頼性を検証する場合は、このボックスをチェックします。例えば、自己署名証明書や証明書なしでRed Hat Quayをテスト用にセットアップした場合は、このボックスをオフにします。
    • HTTP Proxy: リモートサイトへのアクセスにプロキシサーバーが必要な場合は、それを指定します。

    • Tags: このフィールドは必須です。個々のタグやタグパターンをカンマで区切って入力することができます。(詳細はTag Patternsの項を参照してください）。)

      注記

      少なくとも1つのタグが明示的に入力されている（タグパターンではない）か、またはlatestというタグがリモートリポジトリに存在している必要があります。これはQuayがリモートリポジトリのタグリストを取得し、ミラーリングするために指定したリストと比較するために必要です。

      リポジトリミラーリングの完了画面の例を示します。

      Create a new Red Hat Quay repo mirror

  9. Enable Mirror ボタンを選択します。リポジトリミラーリングのページが表示されます。

    Viewing a new Red Hat Quay repo mirror

    これらの設定は、後でこのページに戻って変更することができます。

9.4. ミラーリングされたリポジトリの操作
リンクのコピー

ミラーリングされたリポジトリを作成した後、そのリポジトリを操作する方法はいくつかあります。Repositoriesページからミラーリングしたリポジトリを選択し、以下のいずれかの操作を行います。

  • リポジトリの有効化／無効化: 左列のミラーリングボタンを選択し、「有効」のチェックボックスを切り替えて、リポジトリを一時的に有効または無効にします。

  • ミラーログの確認ミラーリングされたリポジトリが正常に動作していることを確認するために、ミラーログを確認することができます。そのためには、左カラムのUsage Logsボタンを選択します。以下に例を示します。

    View logs for your Red Hat Quay repo mirror

  • 今すぐミラーを同期リポジトリ内のイメージをすぐに同期するには、Sync Nowボタンを選択します。
  • クレデンシャルを変更する。ユーザー名とパスワードを変更するには、Credentialsの行からDELETEを選択します。その後、「なし」を選択し、プロンプトが表示されたら、外部レジストリにログインするために必要なユーザー名とパスワードを追加します。
  • ミラーリングをキャンセルする: ミラーリングを中止するには、CANCELボタンを選択します。これにより、現在の画像はそのまま利用できますが、新しい画像は同期されなくなります。

  • ロボットのパーミッションを設定: Red Hat Quay のロボットアカウントは、外部のリポジトリにアクセスするための認証情報を保持する名前付きのトークンです。ロボットに認証情報を割り当てることで、そのロボットは、同じ外部レジストリにアクセスする必要のある複数のミラーリングされたリポジトリで使用することができます。

    既存のロボットをリポジトリに割り当てるには、Account Settingsを開き、左カラムのRobot Accountsアイコンを選択します。ロボットアカウントの場合は、REPOSITORIES欄のリンクを選択します。ポップアップウィンドウから、以下のことができます。

    • そのロボットにどのリポジトリが割り当てられているかを確認します。
    • 図のPERMISSIONフィールドから、そのロボットにリード、ライト、アドミンの権限を割り当てます。 Assign a robot to mirrored repo

  • ロボット認証情報の変更: ロボットは、Kubernetesの秘密、Dockerのログイン情報、Mesosのバンドルなどの認証情報を保持することができます。ロボットの認証情報を変更するには、Robot Accounts ウィンドウのロボットのアカウント行にある Options ギアを選択し、View Credentials を選択します。ロボットがアクセスする必要のある外部リポジトリの適切な認証情報を追加します。

    Assign permission to a robot

  • 一般設定の確認と変更: ミラーリングされたリポジトリのページの左カラムから Settings ボタン（歯車のアイコン）を選択します。表示されるページでは、ミラーリングされたリポジトリに関連する設定を変更することができます。特に、ユーザーやロボットのパーミッションを変更して、どのユーザーやロボットがレポを読み書きできるかを正確に指定することができます。

9.5. タグパターン
リンクのコピー

上述のように、少なくとも1つのタグが明示的に入力されている（つまりタグパターンではない）、またはタグlatestがレポートリポジトリに存在している必要があります。(タグlatestは、タグリストで指定されていないと同期されません。)これはQuayがリモートリポジトリのタグリストを取得し、ミラーリングするために指定したリストと比較するために必要です。

パターン構文

Expand

パターン

説明

*

すべての文字にマッチする

?

任意の単一文字に一致します。

[seq]

seqに含まれる任意の文字にマッチ

[!seq]

seqに含まれない任意の文字にマッチ

タグのパターン例

Expand

パターン例

マッチの例

v3*

v32, v3.1, v3.2, v3.2-4beta, v3.3

v3.*

v3.1, v3.2, v3.2-4beta

v3.?

v3.1, v3.2, v3.3

v3.[12]

v3.1, v3.2

v3.[12]*

v3.1, v3.2, v3.2-4beta

v3.[!1]*

v3.2, v3.2-4beta, v3.3

第10章 Red Hat QuayのLDAP認証設定
リンクのコピー

LDAP (Lightweight Directory Access Protocol) は、IP ネットワークで分散ディレクトリー情報サービスにアクセスし、これを維持するために使用するオープンな、ベンダーに依存しない業界標準のアプリケーションプロトコルです。Red Hat Quay は ID プロバイダーとして LDAP の使用をサポートしています。

10.1. LDAP設定を行う
リンクのコピー

設定ツールで認証の項目を探し、ドロップダウンメニューからLDAPを選択します。必要に応じてLDAP設定項目を更新してください。

Fill in LDAP information

  • 以下は、config.yamlファイルの結果としてのエントリの例です。 
AUTHENTICATION_TYPE: LDAP
Copy to Clipboard Toggle word wrap

10.1.1. 完全なLDAP URI
リンクのコピー

LDAP server URI LDAP server SSL

  • ldap://またはldaps://のプレフィックスを含む、完全なLDAP URI。
  • ldaps://で始まるURIは、提供されたSSL証明書を使用してTLSの設定を行います。
  • 以下は、config.yamlファイルの結果としてのエントリの例です。 
LDAP_URI: ldaps://ldap.example.org
Copy to Clipboard Toggle word wrap

10.1.2. チームシンクロナイゼーション
リンクのコピー

Team synchronization

  • この機能を有効にすると、スーパーユーザーである組織管理者は、チームのメンバーシップをLDAPの下位グループと同期させるように設定できます。

Team synchronization

  • 再同期期間とは、チームを再同期させる必要がある期間のことです。継続時間の文字列形式で表現する必要があります。30m, 1h, 1d.
  • オプションとして、管理者である組織の下で、スーパーユーザー以外の人がチームの同期を有効にして管理できるようにします。
  • 以下は、config.yamlファイルの結果としてのエントリの例です。 
FEATURE_TEAM_SYNCING: true
TEAM_RESYNC_STALE_TIME: 60m
FEATURE_NONSUPERUSER_TEAM_SYNCING_SETUP: true
Copy to Clipboard Toggle word wrap

10.1.3. ベースおよび相対的な区別された名前
リンクのコピー

Distinguished Names

  • すべてのLDAPレコードを検索するための基本パスとなる識別名のパス。例: dc=my,dc=domain,dc=com
  • すべてのユーザーのLDAPレコードを検索するための第二のベースパスとなる、上記で定義したベースDNに相対する識別名パスのリスト（オプション）。これらのパスは、プライマリの相対的なDNでユーザーを見つけられなかった場合に試行されます。
  • User Relative DNはBaseDNからの相対的なものです。例: ou=NYC であり、ou=NYC,dc=example,dc=orgではない。
  • ユーザーオブジェクトが配置されているOrganizational Unitが複数ある場合は、Secondary User Relative DNを複数入力することができます。複数のRDNを追加するには、Organizational Unitを入力してAddボタンをクリックします。例: ou=Users,ou=NYC および ou=Users,ou=SFO
  • User Relative DN はサブツリーのスコープで検索します。例えば、組織がUsers OUの下にNYCとSFOのOrganizational Unitを持っている場合ou=SFO,ou=Usersおよびou=NYC,ou=Users)、User Relative DNがUsers(ou=Users)に設定されていれば、Red Hat QuayはNYCとSFOの両方のOrganizational Unitからユーザーを認証することができます。
  • 以下は、config.yamlファイルの結果としてのエントリの例です。 
LDAP_BASE_DN:
- dc=example
- dc=com
LDAP_USER_RDN:
- ou=users
LDAP_SECONDARY_USER_RDNS:
- ou=bots
- ou=external
Copy to Clipboard Toggle word wrap

10.1.4. ユーザーフィルターの追加
リンクのコピー

User filters

  • 指定された場合、すべてのユーザー検索クエリで使用される追加フィルタ。なお、フィルターで使用する識別名はすべて完全なパスでなければならず、ベースDNはここでは自動的に追加されません。括弧でくくる必要があります。例: (&(someFirstField=someValue)(someOtherField=someOtherValue))
  • 以下は、config.yamlファイルの結果としてのエントリの例です。 
LDAP_USER_FILTER: (memberof=cn=developers,ou=groups,dc=example,dc=com)
Copy to Clipboard Toggle word wrap

10.1.5. 管理者 DN
リンクのコピー

Administrator DN

  • 管理者アカウントのDistinguished Name（識別名）とPassword（パスワード）。このアカウントは、ログインしてすべてのユーザーアカウントの記録を閲覧できる必要があります。例: uid=admin,ou=employees,dc=my,dc=domain,dc=com
  • パスワードはconfig.yaml内に平文で保存されますので、専用のアカウントを設定するか、パスワードハッシュを使用することを強くお勧めします。
  • 以下は、config.yamlファイルの結果としてのエントリの例です。 
LDAP_ADMIN_DN: cn=admin,dc=example,dc=com
LDAP_ADMIN_PASSWD: changeme
Copy to Clipboard Toggle word wrap

10.1.6. UIDとメール属性
リンクのコピー

UID and Mail

  • UID属性は、ユーザー名として使用するLDAPユーザーレコードのプロパティフィールドの名前です。一般的には、uid です。
  • Mail属性は、LDAPユーザーレコードのプロパティフィールドの名前で、ユーザーの電子メールアドレスが格納されています。一般的には mailです。
  • いずれもログイン時に使用することができます。
  • ログインしたユーザー名がUser Relative DNに存在している必要があります。
  • sAMAccountNameは、Microsoft Active Directoryの設定に対するUID属性です。
  • 以下は、config.yamlファイルの結果としてのエントリの例です。 
LDAP_UID_ATTR: uid
LDAP_EMAIL_ATTR: mail
Copy to Clipboard Toggle word wrap

10.1.7. 検証
リンクのコピー

設定が完了したら、"Save Configuration Changes "ボタンをクリックして設定を有効にします。

Fill in LDAP information

すべての検証が成功しないと先に進めません。また、編集を続けるボタンを選択して追加の設定を行うこともできます。

10.2. 共通の課題
リンクのコピー

無効な認証情報

Administrator DNまたはAdministrator DN Passwordの値が正しくない

スーパーユーザー %USERNAME% の検証に失敗しました。ユーザー名が見つかりません ユーザーがリモート認証システムに存在しないか、LDAP認証の設定が間違っています。

Red Hat Quay は Administrator DN フィールドで指定された Username/Password で LDAP サーバーに接続できますが、User Relative DN Path の UID Attribute または Mail Attribute フィールドで現在ログインしているユーザーを見つけることができません。現在ログインしているユーザーがUser Relative DN Pathに存在しないか、Administrator DNのユーザーがこのLDAPパスを検索/閲覧する権限を持っていません。

10.3. LDAPユーザーをスーパーユーザーとして設定する
リンクのコピー

LDAPが設定されると、有効なLDAPユーザー名とパスワードでRed Hat Quayインスタンスにログインできるようになります。次の図のように、Red Hat Quay のユーザー名を確認するプロンプトが表示されます。

Confirm LDAP username for Red Hat Quay

LDAPユーザーにスーパーユーザー権限を付与するには、config.yamlファイルのユーザー名を変更します。例: 

SUPER_USERS:
- testadmin
Copy to Clipboard Toggle word wrap

更新された config.yaml ファイルで Red Hat Quay コンテナを再起動します。次回のログイン時には、そのユーザーはスーパーユーザーの権限を持つことになります。

第11章 Red Hat Quayの下でのPrometheusとGrafanaのメトリクス
リンクのコピー

Red Hat Quayは、各インスタンスにPrometheusとGrafanaに対応したエンドポイントをエクスポートし、簡単にモニタリングとアラートを行うことができます。

11.1. Prometheusエンドポイントの公開
リンクのコピー

Red Hat Quayインスタンス上のPrometheusとGrafanaに対応したエンドポイントは、ポート9091にあります。Quayのリポジトリカウントを監視するためのPrometheusとGrafanaの設定については、Monitoring Quay with Prometheus and Grafanaを参照してください。

11.1.1. Prometheusがメトリクスを消費するための設定
リンクのコピー

Prometheus は、クラスタ内で実行されているすべての Red Hat Quay インスタンスにアクセスする方法が必要です。典型的なセットアップでは、すべての Red Hat Quay インスタンスを単一の名前付き DNS エントリにリストアップし、それを Prometheus に渡すことで行われます。

11.1.2. KubernetesでのDNS設定
リンクのコピー

シンプルなKubernetes serviceを設定して、PrometheusのDNSエントリを提供することができます。PrometheusをKubernetes上で動作させるための詳細は、Prometheus and KubernetesとMonitoring Kubernetes with Prometheusを参照してください。

11.1.3. 手動クラスタのDNS設定
リンクのコピー

SkyDNSは、Kubernetesを使用していない場合に、このDNSレコードを管理するためのシンプルなソリューションです。SkyDNSは、etcdクラスタ上で動作させることができます。クラスタ内の各 Red Hat Quay インスタンスのエントリーを etcd ストアに追加、削除することができます。SkyDNSはそこから定期的に読み込んで、それに応じてDNSレコードのQuayインスタンスのリストを更新します。

第12章 Red Hat Quayにおけるストレージのジオレプリケーション
リンクのコピー

ジオレプリケーションにより、グローバルに分散された1つのRed Hat Quayが、ローカライズされたストレージからコンテナイメージを提供することができます。

ジオレプリケーションが設定されると、コンテナイメージのプッシュはそのRed Hat Quayインスタンスの優先ストレージエンジンに書き込まれます。最初のプッシュの後、画像データはバックグランドで他のストレージエンジンに複製されます。レプリケーションロケーションのリストは設定可能です。イメージプルでは、プルのパフォーマンスを最大化するために、常に利用可能な最も近いストレージエンジンを使用します。

12.1. 前提条件
リンクのコピー

ジオレプリケーションでは、各地域に高可用性のストレージエンジン（S3、GCS、RADOS、Swift）を設置する必要があります。さらに、レプリケーションの必要性から、各リージョンはすべてのストレージエンジンにアクセスできなければなりません。

注記

現時点では、ローカルディスクストレージはジオレプリーションに対応していません。

12.2. Config Tool を見る
リンクのコピー

Red Hat Quay Config Toolを開き、ジオレプリケーション用のストレージを設定します。

12.3. ストレージレプリケーションの有効化
リンクのコピー

  1. スクロールダウンして、Registry Storageというセクションに進みます。
  2. ストレージレプリケーションの有効化をクリックします。
  3. データを複製するストレージエンジンをそれぞれ追加します。使用するすべてのストレージエンジンをリストに載せる必要があります。
  4. すべてのイメージをすべてのストレージエンジンに完全にレプリケートする必要がある場合は、各ストレージエンジンの構成の下でReplicate to storage engine by defaultをクリックします。これにより、すべてのイメージがそのストレージエンジンにレプリケートされます。代わりに名前空間ごとのレプリケーションを有効にするには、サポートにお問い合わせください。
  5. 完了したら、Save Configuration Changesをクリックします。設定変更は、Red Hat Quayが次回再起動したときに有効になります。

  6. ストレージを追加し、ジオレプリケーションの「デフォルトでストレージエンジンにレプリケートする」を有効にした後、既存の画像データをすべてのストレージで同期する必要があります。そのためには、コンテナにoc exec（またはdocker/kubectl exec）して実行する必要があります。 

    # scl enable python27 bash
# python -m util.backfillreplication
    Copy to Clipboard Toggle word wrap

    この操作は、新しいストレージを追加した後にコンテンツを同期するための1回限りの操作です。

12.4. ストレージの環境設定によるRed Hat Quayの実行
リンクのコピー

  1. config.yaml を Red Hat Quay を実行しているすべてのマシンにコピーします。

  2. 各リージョンの各マシンには、マシンが稼働しているリージョンの優先ストレージエンジンを持つQUAY_DISTRIBUTED_STORAGE_PREFERENCE環境変数を追加します。

    例えば、ヨーロッパで稼働しているマシンで、ホスト上のconfigディレクトリが/mnt/quay/configから利用できる場合です。 

    # sudo podman login quay.io
Username: yourquayuser
Password: *****
# sudo podman run -d -p 443:8443 -p 8080:8080 -v /mnt/quay/config:/conf/stack:Z \
    -e QUAY_DISTRIBUTED_STORAGE_PREFERENCE=europestorage \
    registry.redhat.io/quay/quay-rhel8:v3.4.6
    Copy to Clipboard Toggle word wrap
    注記

    指定された環境変数の値は、コンフィグパネルで定義されたロケーションIDの名前と一致する必要があります。

  3. すべての Red Hat Quay コンテナを再起動します。

第13章 Red Hat Quay のトラブルシューティング
リンクのコピー

一般的な故障モードと復旧のためのベストプラクティス

第14章 Red Hat Quay の設定用スキーマ
リンクのコピー

ほとんどの Red Hat Quay 構成情報は、Red Hat Quay が最初に展開されたときにブラウザベースの config ツールを使用して作成されるconfig.yamlファイルに保存されます。この章では、config.yaml ファイルで使用可能なそれらの設定のスキーマについて説明します。

以下の項目は必須です（その他はすべて任意）。 

AUTHENTICATION_TYPE
BUILDLOGS_REDIS
DATABASE_SECRET_KEY
DB_URI
DEFAULT_TAG_EXPIRATION
DISTRIBUTED_STORAGE_CONFIG
DISTRIBUTED_STORAGE_PREFERENCE
PREFERRED_URL_SCHEME
SECRET_KEY
SERVER_HOSTNAME
TAG_EXPIRATION_OPTIONS
USER_EVENTS_REDIS
Copy to Clipboard Toggle word wrap

  • ACTION_LOG_ARCHIVE_LOCATION[文字列]:アクションログのアーカイブが有効な場合、アーカイブされたデータを配置するストレージエンジンです。

    • 例: s3_us_east

  • ACTION_LOG_ARCHIVE_PATH[文字列]:アクションログのアーカイブが有効な場合、アーカイブされたデータを配置するストレージ内のパスです。

    • 例: archives/actionlogs

  • ACTION_LOG_ROTATION_THRESHOLD[文字列]:ACTION_LOG_ROTATION_THRESHOLD [文字列] アクションログのアーカイブが有効な場合、ログを回転させる時間間隔を指定します。

    • 例 30d

  • ALLOW_PULLS_WITHOUT_STRICT_LOGGING[ブール]:trueの場合、pull監査ログのエントリが書き込めないプルも成功します。データベースが読み取り専用の状態にフォールバックすることができ、その間もプルを継続したい場合に有効です。デフォルトは false です。

    • 例: True

  • APP_SPECIFIC_TOKEN_EXPIRATION[文字列,null]:外部アプリのトークンの有効期限です。デフォルトは None です。

    • パターン: ^[0-9]+(w|m|d|h|s)$

  • AUTHENTICATION_TYPE[文字列] 必須。クレデンシャル認証に使用する認証エンジンを指定します。

    • enum: Database, LDAP, JWT, Keystone, OIDC.
    • 例 Database

  • AVATAR_KIND[文字列]:表示するアバターの種類。インラインで生成されたもの（local）か、Gravatar（gravatar）か。

    • enum: local, gravatar

  • BITBUCKET_TRIGGER_CONFIG['object', 'null']:ビルドトリガーにBitBucketを使用するための設定です。

    • consumer_key[文字列] 必須。この Red Hat Quay インスタンスに登録されているコンシューマーキー（クライアント ID）です。

      • 例: 0e8dbe15c4c7630b6780

  • BLACKLISTED_EMAIL_DOMAINS[array]:FEATURE_BLACKLISTED_EMAILSがtrueに設定されている場合に使用される電子メールアドレスドメインの配列です。

    • 例: "example.com", "example.org"

  • BLACKLIST_V2_SPEC[文字列]:Red Hat Quay が V2 はunsupportedと応答する Docker CLI のバージョンです。デフォルトは <1.6.0.です。

  • BRANDING[オブジェクト]。Red Hat Quay UI でのロゴや URL のカスタムブランディング。

    • Required: ロゴ

    • properties:

      • logo [文字列] : メインのロゴイメージURL

        • 例: /static/img/quay-horizontal-color.svg

      • footer_img[文字列] :UIフッター用のロゴ。

        • 例: /static/img/RedHat.svg

      • footer_url[文字列] :フッター画像のリンク。

  • BROWSER_API_CALLS_XHR_ONLY［ブール値］。有効にすると、XHRによって行われるとマークされたAPIコールのみがブラウザから許可されます。デフォルトは True です。

    • 例: False

  • BUILDLOGS_REDIS[オブジェクト] 必須。ビルドログをキャッシュするためのRedisの接続情報です。

    • HOST[文字列] 必須。Redisにアクセスするためのホスト名。

      • 例: my.redis.cluster

    • PASSWORD[文字列]: Redisインスタンスに接続するためのパスワードです。

      • 例: mypassword

    • PORT［番号］。Redisにアクセスするためのポートです。

      • 例: 1234

  • CONTACT_INFO[配列]:指定された場合は、連絡先ページに表示する連絡先情報。連絡先が1つしか指定されていない場合は、連絡先のフッターが直接リンクされます。

    • Min Items: 1

    • Unique Items: True

      • array item 0[文字列] :メールを送信するためのリンクを追加する
      • パターン: ^mailto:(.)+$
      • 例: mailto:support@quay.io

    • array item 1[文字列] :IRCチャットルームを訪問するためのリンクを追加する

    • array item 2 [文字列] : Adds a link to call a phone number

      • パターン: ^tel:(.)+$
      • 例: tel:+1-888-930-3475

    • array item 3[文字列] :定義されたURLへのリンクを追加する

  • DB_CONNECTION_ARGS[オブジェクト]:指定された場合、タイムアウトやSSLなどのデータベースの接続引数。

    • threadlocals[ブール] 必須。スレッドローカルな接続を使用するかどうか。常にtrueである必要があります。
    • autorollback[ブール] 必須。自動ロールバック接続を使用するかどうか。常にtrueである必要があります。

    • ssl[オブジェクト]: SSL接続の設定

      • ca[文字列] 必須。SSL接続に使用するCA証明書の絶対コンテナパス。
      • 例: conf/stack/ssl-ca-cert.pem

  • DATABASE_SECRET_KEY[文字列] 必須。データベース内の機密フィールドを暗号化するために使用するキー。一度設定した値は絶対に変更してはいけません。これを変更すると、関連するすべてのフィールド（例えば、リポジトリミラーのユーザー名とパスワードの設定など）が無効になります。

    • 例: 40157269433064266822674401740626984898972632465622168464725100311621640999470

  • DB_URI[文字列] 必須。データベースにアクセスするためのURI（認証情報を含む）。

  • DEFAULT_NAMESPACE_MAXIMUM_BUILD_COUNT: [数値、null]: Noneでない場合、ネームスペースでキューに入れることができるビルドのデフォルトの最大数です。

    • 例: 20

  • DEFAULT_TAG_EXPIRATION[文字列] 必須。タイムマシンのデフォルトの、設定可能なタグの有効期限です。デフォルトは2wです。

    • パターン: ^[0-9]+(w|m|d|h|s)$

  • DIRECT_OAUTH_CLIENTID_WHITELIST[配列]。ユーザーの承認なしに直接 OAuth 承認を実行することが許可されているRed Hat Quay 管理アプリケーションのクライアント ID のリスト。

  • DISTRIBUTED_STORAGE_CONFIG[オブジェクト] 必須。Red Hat Quay で使用するストレージエンジンの構成。各キーはストレージエンジンのユニークなIDで、値はそのエンジンのタイプと構成のタプルです。

    • 例: {"local_storage": ["LocalStorage", {"storage_path": "some/path/"}]}

  • DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS[配列]:DISTRIBUTED_STORAGE_CONFIGのIDで指定されたストレージエンジンのリストで、そのイメージはデフォルトで他のすべてのストレージエンジンに完全に複製されます。

    • Min Items: None

    • 例: s3_us_east, s3_us_west

      • array item[文字列] .

  • DISTRIBUTED_STORAGE_PREFERENCE[配列] 必須。使用する優先的なストレージエンジン（DISTRIBUTED_STORAGE_CONFIGのIDによる）。優先されるエンジンとは、プルのチェックが行われ、画像がプッシュされることを意味します。

    • Min Items: None

      • 例: [u’s3_us_east', u’s3_us_west']
      • array item[文字列] .

    • preferred_url_scheme[文字列] 必須。Red Hat Quayにアクセスする際に使用するURLスキームです。Red Hat Quay が SSL を一部的にでも使用している場合、これはhttps でなければなりません。

      • enum:http, https
      • 例: https
  • DOCUMENTATION_ROOT[文字列]:ドキュメントへのリンクのルート URL。

  • ENABLE_HEALTH_DEBUG_SECRET[string,null]:指定された場合、スーパーユーザとして認証されていないときに、完全なデバッグ情報を見るためにヘルスエンドポイントに与えることができるシークレットです。

    • 例: somesecrethere

  • EXPIRED_APP_SPECIFIC_TOKEN_GC[string,null]:期限切れの外部アプリのトークンがガベージコレクションされるまでの期間です。デフォルトは 1dです。

    • パターン: ^[0-9]+(w|m|d|h|s)$

  • EXTERNAL_TLS_TERMINATION[ブール]。TLS がサポートされているが、Red Hat Quay より前のレイヤーで終了している場合、true にする必要があります。

    • 例: True

  • FEATURE_ACI_CONVERSION[ブール]:ACIへの変換を有効にするかどうか。デフォルトは false です。

    • 例: False

  • FEATURE_ACTION_LOG_ROTATION[ブール]:古いアクションログをストレージに回転させるかどうか。デフォルトは false です。

    • 例: False

  • FEATURE_ADVERTISE_V2[ブール]:v2/のエンドポイントを表示するかどうか。デフォルトは True です。

    • 例: True

  • FEATURE_AGGREGATED_LOG_COUNT_RETRIEVAL[ブール]:集約されたログカウントの検索を許可するかどうか。デフォルトは True です。

    • 例: True

  • FEATURE_ANONYMOUS_ACCESS[ブール]:匿名ユーザーによるパブリックリポジトリの閲覧やプルを許可するかどうか。デフォルトは True です。

    • 例: True

  • FEATURE_APP_REGISTRY[ブール]:Appのリポジトリへの対応を有効にするかどうか。デフォルトは false です。

    • 例: False

  • FEATURE_APP_SPECIFIC_TOKENS［ブール値］。有効にすると、ユーザーはDocker CLIで使用するトークンを作成できます。デフォルトは True です。

    • 例: False

  • FEATURE_BITBUCKET_BUILD[ブール]:Bitbucketのビルドトリガーをサポートするかどうか。デフォルトは false です。

    • 例: False
  • FEATURE_BLACKLISTED_EMAIL

  • FEATURE_BUILD_SUPPORT[ブール]:Dockerfileのビルドをサポートするかどうか。デフォルトは True です。

    • 例: True

  • FEATURE_CHANGE_TAG_EXPIRARTION[ブール]:ユーザーや組織が、自分の名前空間にあるタグの有効期限を変更できるかどうか。デフォルトは True です。

    • 例: False

  • FEATURE_DIRECT_LOGIN[ブール]:ユーザーがUIに直接ログインできるかどうか。デフォルトは True です。

    • 例: True

  • FEATURE_GARBAGE_COLLECTION[ブール]:リポジトリのガベージコレクションを有効にするかどうか。デフォルトは True です。

    • 例: True

  • FEATURE_GITHUB_BUILD[ブール]:GitHubのビルドトリガーをサポートするかどうか。デフォルトは false です。

    • 例: False

  • FEATURE_GITHUB_LOGIN[ブール]:GitHubのログインに対応しているかどうか。デフォルトは false です。

    • 例: False

  • FEATURE_GITLAB_BUILD[ブール]:GitLabのビルドトリガーをサポートするかどうか。デフォルトは false です。

    • 例: False

  • FEATURE_GOOGLE_LOGIN[ブール]:Googleログインがサポートされているかどうか。デフォルトは false です。

    • 例: False

  • FEATURE_INVITE_ONLY_USER_CREATION[ブール]:作成されるユーザーが他のユーザーによって招待されなければならないかどうか。デフォルトは false です。

    • 例: False

  • FEATURE_LIBRARY_SUPPORT[ブール]:Dockerからのプルプッシュ時に「名前空間のない」リポジトリを許可するかどうか。デフォルトは True です。

    • 例: True

  • FEATURE_LOG_EXPORT[ブール]:アクションログのエクスポートを許可するかどうか。デフォルトは True です。

    • 例: True

  • FEATURE_MAILING[ブール]:メールが有効であるかどうか。デフォルトは True です。

    • 例: True

  • FEATURE_NONSUPERUSER_TEAM_SYNCING_SETUP［ブール値］。有効にすると、スーパーユーザーではない人でも、LDAPやKeystoneをバックにチームの同期を設定できます。デフォルトは False です。

    • 例: True

  • FEATURE_PARTIAL_USER_AUTOCOMPLETE［ブール値］。trueに設定すると、オートコンプリートは部分的なユーザー名にも適用されます。デフォルトは True です。

    • 例: True

  • FEATURE_PERMANENT_SESSIONS[ブール]:セッションが永続的であるかどうか。デフォルトは True です。

    • 例: True

  • FEATURE_PROXY_STORAGE[ブール]:ストレージ内のすべての直接ダウンロードURLをレジストリのnginx経由でプロキシするかどうかを指定します。デフォルトは false です。

    • 例: False

  • FEATURE_PUBLIC_CATALOG［ブール値］。trueに設定すると、_catalogエンドポイントは公開リポジトリを返します。それ以外では、プライベートリポジトリのみが返されます。デフォルトは false です。

    • 例: False

  • FEATURE_RATE_LIMITS[ブール]:APIとレジストリのエンドポイントでレート制限を有効にするかどうか。デフォルトは false です。

    • 例: False

  • FEATURE_READER_BUILD_LOGS[ブール]:trueに設定すると、ビルドログは書き込みアクセスや管理者アクセスだけではなく、レポへの読み取りアクセスを持つ人が読むことができます。デフォルトは false です。

    • 例: False

  • FEATURE_READONLY_APP_REGISTRY[ブール]:Appのリポジトリを読み取り専用にするかどうか。デフォルトは false です。

    • 例: True

  • FEATURE_RECAPTCHA[ブール]:ユーザーのログインとリカバリーにRecaptchaが必要かどうか。デフォルトは false です。

  • FEATURE_REPO_MIRROR[ブール]:ミラーリング時にHTTPSを要求し、Quayレジストリの証明書を検証します。デフォルトは True です。

    • 例: True

  • FEATURE_REQUIRE_ENCRYPTED_BASIC_AUTH[ブール]:基本認証に暗号化されていないパスワード（暗号化されたトークンではなく）を使用できるかどうか。デフォルトは false です。

    • 例: False

  • FEATURE_REQUIRE_TEAM_INVITE[ブール]:ユーザーをチームに追加する際に招待状を要求するかどうか。デフォルトは True です。

    • 例: True

  • FEATURE_RESTRICTED_V1_PUSH[ブール]:trueに設定すると、V1_PUSH_WHITELISTに記載されている名前空間のみがV1プッシュをサポートします。デフォルトは True です。

    • 例: True

  • FEATURE_SECURITY_NOTIFICATIONS[ブール]:セキュリティスキャナが有効な場合、セキュリティ通知をオン/オフするかどうかを指定します。デフォルトは false です。

    • 例: False

  • FEATURE_SECURITY_SCANNER[ブール]:セキュリティスキャナをオン/オフするかどうか。デフォルトは false です。

  • FEATURE_STORAGE_REPLICATION[ブール]:ストレージエンジン間で自動的にレプリケーションを行うかどうか。デフォルトは false です。

    • 例: False

  • FEATURE_SUPER_USERS[ブール]:スーパーユーザーをサポートするかどうか。デフォルトは True です。

    • 例: True

  • FEATURE_TEAM_SYNCING[ブール]:認証エンジン（LDAPまたはKeystone）のバッキンググループからチームメンバーを同期させることを許可するかどうか。

    • 例: True

  • FEATURE_USER_CREATION[ブール]:スーパーユーザーではない人が）ユーザーを作成できるかどうか。デフォルトは True です。

    • 例: True

  • FEATURE_USER_LAST_ACCESSED[ブール]:ユーザーが最後にアクセスした時間を記録するかどうか。デフォルトは True です。

    • 例: True

  • FEATURE_USER_LOG_ACCESS［ブール値］。trueに設定すると、ユーザーは自分のネームスペースの監査ログにアクセスできます。デフォルトは false です。

    • 例: True

  • FEATURE_USER_METADATA[ブール]:ユーザのメタデータを収集してサポートするかどうか。デフォルトは false です。

    • 例: False

  • FEATURE_USERNAME_CONFIRMATION［ブール値］。trueに設定すると、ユーザは生成されたユーザ名を確認できます。デフォルトは True です。

    • 例: False

  • FEATURE_USER_RENAME［ブール値］。trueに設定すると、ユーザーは自分のネームスペースの名前を変更できます。デフォルトは false です。

    • 例: True

  • FRESH_LOGIN_TIMEOUT[文字列]:フレッシュログインでユーザーがパスワードの再入力を要求される時間

    • 例 5m

  • GITHUB_LOGIN_CONFIG[オブジェクト, 'null']:GitHub (Enterprise)を外部ログインプロバイダーとして使用するための設定です。

    • 参考: https://coreos.com/quay-enterprise/docs/latest/github-auth.html

    • allowed_organizations[配列]:ORG_RESTRICTオプションで動作するようにホワイトリストされたGitHub (Enterprise)の組織の名前。

      • Min Items: None

      • Unique Items: True

        • array item[文字列] .

    • API_ENDPOINT[文字列]:使用するGitHub (Enterprise) APIのエンドポイントです。github.comにオーバーライドされる必要があります。

    • CLIENT_ID[文字列] 必須。GITHUB_TRIGGER_CONFIGとは共有できません。

    • CLIENT_SECRET[文字列] 必須。この Red Hat Quay インスタンスに登録されているクライアントシークレットです。

    • GITHUB_ENDPOINT[文字列] 必須。ヒットしているGitHub（Enterprise）のエンドポイントです。

    • ORG_RESTRICT[ブール]。trueの場合、組織のホワイトリスト内のユーザのみがこのプロバイダを使用してログインできます。
    • 例: True

  • GITHUB_TRIGGER_CONFIGオブジェクト、null:ビルドトリガーにGitHub (Enterprise)を使用するための設定です。

  • GITLAB_TRIGGER_CONFIG[オブジェクト]:Gitlab (Enterprise)を外部認証で使用するための設定。

    • CLIENT_ID[文字列] 必須。この Red Hat Quay インスタンスの登録済みクライアント ID です。

      • 例: 0e8dbe15c4c7630b6780

    • CLIENT_SECRET[文字列] 必須。この Red Hat Quay インスタンスに登録されているクライアントシークレットです。

      • 例: e4a58ddd3d7408b7aec109e85564a0d153d3e846

      • gitlab_endpoint[文字列] 必須。Gitlab(Enterprise)が動作しているエンドポイントです。

  • GOOGLE_LOGIN_CONFIGオブジェクト,null:外部認証にGoogleを利用するための設定

    • CLIENT_ID[文字列] 必須。この Red Hat Quay インスタンスの登録済みクライアント ID です。

      • 例: 0e8dbe15c4c7630b6780

    • CLIENT_SECRET[文字列] 必須。この Red Hat Quay インスタンスに登録されているクライアントシークレットです。

      • 例: e4a58ddd3d7408b7aec109e85564a0d153d3e846

  • GPG2_PRIVATE_KEY_FILENAME[文字列]。ACIの解読に使用する秘密鍵のファイル名です。

    • 例: /path/to/file

  • GPG2_PRIVATE_KEY_NAME[文字列]。ACIの署名に使用する秘密鍵の名前です。

    • 例: gpg2key

  • GPG2_PUBLIC_KEY_FILENAME[文字列]。ACIの暗号化に使用する公開鍵のファイル名です。

    • 例: /path/to/file

  • HEALTH_CHECKER[文字列]:設定されたヘルスチェック。

    • 例: ('RDSAwareHealthCheck', {'access_key': 'foo', 'secret_key': 'bar'})

  • JWT_AUTH_ISSUER[文字列] :JWT ユーザーのエンドポイント。

  • JWT_GETUSER_ENDPOINT [文字列] : The endpoint for JWT users.

  • JWT_QUERY_ENDPOINT[文字列] :JWT クエリのエンドポイントです。

  • JWT_VERIFY_ENDPOINT[文字列] :JWTの検証を行うエンドポイント。

  • LDAP_ADMIN_DN[文字列]:LDAP認証のアドミンDNです。
  • LDAP_ADMIN_PASSWD[文字列]:LDAP認証の管理者パスワードです。
  • LDAP_ALLOW_INSECURE_FALLBACK[ブール]:LDAP認証において、SSL insecure fallbackを許可するかどうかを指定します。
  • LDAP_BASE_DN[文字列]:LDAP認証のベースDNです。
  • LDAP_EMAIL_ATTR[文字列]:LDAP認証のメール属性です。
  • LDAP_UID_ATTR[文字列]:LDAP認証のuid属性です。
  • LDAP_URI[文字列]:LDAP URIです。
  • LDAP_USER_FILTER[文字列]:LDAP認証のためのユーザーフィルターです。
  • LDAP_USER_RDN[配列]:LDAP認証のユーザーRDNです。

  • LOGS_MODEL[文字列]:アクションログのログモデル。

    • enum: database, transition_reads_both_writes_es, elasticsearch
    • 例: database

  • LOGS_MODEL_CONFIG[オブジェクト]:アクションログ用のログモデル設定

    • elasticsearch_config[オブジェクト]:Elasticsearchクラスタの設定

      • access_key[文字列] :Elasticsearch のユーザー（AWS ES の場合は IAM キー）。

        • 例: some_string

      • ホスト[文字列]:Elasticsearch クラスタのエンドポイント

        • 例: host.elasticsearch.example

      • index_prefix[文字列]。Elasticsearch のインデックスのプレフィックス

        • 例: logentry_
      • index_settings[オブジェクト]:Elasticsearchのインデックス設定

      • use_ssl[ブール]。Elasticsearchにsslを使用します。デフォルトは true です。

        • 例: True

      • secret_key[文字列] :Elasticsearchのパスワード（またはAWS ESの場合はIAMシークレット

        • 例: some_secret_string

      • aws_region[文字列]:アマゾンウェブサービスの地域

        • 例: us-east-1

      • ポート[番号]:Elasticsearchクラスタのエンドポイントポート

        • 例: 1234

    • kinesis_stream_config[オブジェクト]:AWS Kinesis ストリームの設定

      • aws_secret_key[文字列] :AWSの秘密鍵

        • 例: some_secret_key

      • stream_name [文字列] : [文字列]:アクションログの送信先となるKinesisストリーム

        • 例: logentry-kinesis-stream

      • aws_access_key [文字列] : AWS access key

        • 例: some_access_key

      • retries[番号] :一回のリクエストに対する最大試行回数

        • 例: 5

      • read_timeout[番号]:コネクションからの読み込み時にタイムアウトするまでの秒数

        • 例: 5

      • max_pool_connections[番号] :コネクションプールに保持するコネクションの最大数

        • 例: 10

      • aws_region [文字列] : AWS のリージョン

        • 例: us-east-1

      • connect_timeout[番号]:接続を試みる際のタイムアウトまでの秒数

        • 例: 5

    • producer[文字列] :Elasticsearchにロギングする場合、producerを記録します。

      • enum: kafka, elasticsearch, kinesis_stream
      • 例: kafka

    • kafka_config[オブジェクト]:Kafkaクラスターの設定

      • topic [文字列] : Kafka topic to publish log entries to

        • 例: logentry
      • bootstrap_servers[配列]:クライアントをブートストラップさせる Kafka ブローカーのリスト

      • max_block_seconds[番号]:send()の実行中に、バッファがいっぱいになったり、メタデータが利用できないなどの理由でブロックする最大秒数

        • 例: 10

  • LOG_ARCHIVE_LOCATION[文字列]。ビルドが有効な場合、アーカイブされたビルドログを配置するストレージエンジンです。

    • 例: s3_us_east

  • LOG_ARCHIVE_PATH[文字列]:ビルドが有効な場合、アーカイブされたビルドログを保存するストレージ内のパス。

    • 例: archives/buildlogs
  • LOGS_MODEL[文字列]:アクションログのログモデル。
  • enum: database, transition_reads_both_writes_es, elasticsearch
  • 例: database

  • MAIL_DEFAULT_SENDER[文字列、null]。指定された場合、Red Hat Quay が電子メールを送信する際にfromとして使用される電子メールアドレスです。何もない場合、デフォルトはsupport@quay.io です。

    • 例: support@myco.com

  • MAIL_PASSWORD[文字列,null]:電子メールの送信時に使用するSMTPパスワード。

    • 例: mypassword

  • MAIL_PORT［番号］。使用するSMTPポートを指定します。指定されていない場合、デフォルトでは587になります。

    • 例: 588

  • MAIL_SERVER[文字列]:電子メールの送信に使用するSMTPサーバーです。FEATURE_MAILINGがtrueに設定されている場合のみ必要です。

    • 例: smtp.somedomain.com

  • MAIL_USERNAME[文字列, 'null']:電子メールの送信時に使用するSMTPユーザー名。

    • 例: myuser

  • MAIL_USE_TLS［ブール値］。指定された場合、電子メールの送信にTLSを使用するかどうか。

    • 例: True

  • MAXIMUM_LAYER_SIZE[文字列]:画像レイヤーの最大許容サイズ。デフォルトは20Gです。

    • パターン: ^[0-9]+(G|M)$
    • 例: 100G

  • PREFERRED_URL_SCHEME[文字列]。Red Hat Quay にアクセスする際に使用する URL スキームです。Red Hat Quay が SSL を一部的にでも使用している場合、これはhttpsでなければなりません。

    • enum:httpまたはhttps
    • 例: https

  • PROMETHEUS_NAMESPACE［文字列］。公開されているすべてのPrometheusメトリクスに適用されるプレフィックスです。デフォルトはquay です。

    • 例: myregistry

  • PUBLIC_NAMESPACES[配列]:名前空間が公共の名前空間リストで定義されている場合、そのユーザーが名前空間のメンバーであるかどうかにかかわらず、すべてのユーザーのリポジトリリストページに表示されます。一般的には、企業のお客様が「よく知られた」名前空間のセットを構成する際に使用されます。

    • Min Items: None

    • Unique Items: True

      • array item[文字列] .
  • RECAPTCHA_SECRET_KEY[文字列]:recaptcha が有効な場合、Recaptcha サービスの秘密鍵。
  • RECAPTCHA_SITE_KEY[文字列]:recaptcha が有効な場合、Recaptcha サービスのサイトキー。

  • REGISTRY_STATE[文字列]:レジストリの状態です。

    • enum:ノーマルまたはリードオンリー
    • 例: read-only

  • REGISTRY_TITLE[文字列]:指定された場合は、レジストリの長い形式のタイトルです。デフォルトはQuay Enterpriseです。

    • 例: Corp Container Service

  • REGISTRY_TITLE_SHORT[文字列]:指定された場合、レジストリの短い形式のタイトル。デフォルトはQuay Enterpriseです。

    • 例: CCS

  • REPO_MIRROR_INTERVAL［数値］。リポジトリのミラー候補をチェックする間隔を秒単位で指定します。デフォルトは 30 です。

    • 例: 30

  • REPO_MIRROR_SERVER_HOSTNAME[文字列]を指定します。ミラーリング先の SERVER_HOSTNAME を置き換えます。デフォルトは unset です。

    • 例: openshift-quay-service

  • REPO_MIRROR_TLS_VERIFY[ブール]:ミラーリング中にHTTPSを要求し、Quayレジストリの証明書を検証します。デフォルトは True です。

    • 例: True

  • SEARCH_MAX_RESULT_PAGE_COUNT[番号]:ユーザーが検索でページングする際に、制限されるまでの最大ページ数。デフォルトは10です。

    • 例: 10

  • SEARCH_RESULTS_PER_PAGE[番号]:検索ページごとに返される結果の数。デフォルトは10です。

    • 例: 10

  • SECRET_KEY[文字列] 必須。データベースやランタイムで機密性の高いフィールドを暗号化するために使用されるキー。一度設定した値は絶対に変更してはいけません。これを変更すると、依存するすべてのフィールド（たとえば、暗号化されたパスワードの認証情報）が無効になります。

    • 例: 40157269433064266822674401740626984898972632465622168464725100311621640999470

  • SECURITY_SCANNER_ENDPOINT[文字列] :セキュリティスキャナのエンドポイントです。

  • SECURITY_SCANNER_INDEXING_INTERVAL［番号］。セキュリティスキャナのインデキシング間隔の秒数です。デフォルトは 30 です。

    • 例: 30

  • SECURITY_SCANNER_NOTIFICATIONS[ブール]:セキュリティスキャナの通知機能を行うかどうか

    • 例: false

  • SECURITY_SCANNER_V4_ENDPOINT[文字列]:V4セキュリティスキャナーのエンドポイントです。

  • SERVER_HOSTNAME[文字列] 必須。Red Hat Quay にアクセスするための URL で、スキームは含まれません。

    • 例: quay.io

  • SESSION_COOKIE_SECURE[ブール]:セッションクッキーにsecureプロパティを設定するかどうか。デフォルトは false です。SSLを使用するすべてのインストールでTrueにすることを推奨します。

  • SSL_CIPHERS[配列]:指定された場合、有効または無効にするSSL暗号のnginx定義のリストです。

    • 例: CAMELLIA, !3DES

  • SSL_PROTOCOLS[配列]:指定された場合、nginxはリストで定義されたSSLプロトコルを有効にするように設定されます。リストから SSL プロトコルを削除すると、Red Hat Quay の起動時にそのプロトコルが無効になります。

    • SSL_PROTOCOLS: ['TLSv1','TLSv1.1','TLSv1.2']

  • SUCCESSIVE_TRIGGER_FAILURE_DISABLE_THRESHOLD[番号]:Noneではない場合、ビルドトリガーが自動的に無効になるまでに発生する連続した失敗の回数を指定します。デフォルトは 100 です。

    • 例: 50
  • SUCCESSIVE_TRIGGER_INTERNAL_ERROR_DISABLE_THRESHOLD[番号]:Noneでない場合、ビルドトリガーが自動的に無効になるまでに発生する連続した内部エラーの数を指定します。デフォルトは 5 です。

  • SUPER_USERS[配列]:スーパーユーザー権限を付与されるユーザーの Red Hat Quay ユーザー名。

    • Min Items: None

    • Unique Items: True

      • array item[文字列] .

  • TAG_EXPIRATION_OPTIONS[配列] 必須。ネームスペースのタグの有効期限について、ユーザーが選択できるオプション（有効な場合）。

    • Min Items: None
    • array item[文字列] .
    • パターン: ^[0-9]+(w|m|d|h|s)$

  • TEAM_RESYNC_STALE_TIME[文字列]:チームの同期が有効な場合、そのチームのメンバーシップをチェックし、必要に応じて再同期する頻度を指定します（デフォルト: 30m）。

    • パターン: ^[0-9]+(w|m|d|h|s)$
    • 例: 2h

  • USERFILES_LOCATION[文字列]:ユーザーがアップロードしたファイルを配置するストレージエンジンの ID。

    • 例: s3_us_east

  • USERFILES_PATH[文字列]:ユーザーがアップロードしたファイルを配置するストレージ下のパス

    • 例: userfiles

  • USER_EVENTS_REDIS[オブジェクト] 必須。ユーザーイベント処理用のRedisへの接続情報です。

    • HOST[文字列] 必須。Redisにアクセスするためのホスト名。

      • 例: my.redis.cluster

    • PASSWORD[文字列]: Redisインスタンスに接続するためのパスワードです。

      • 例: mypassword

    • PORT［番号］。Redisにアクセスするためのポートです。

      • 例: 1234

    • CONSUMER_SECRET[文字列] 必須。この Red Hat Quay インスタンスに登録されているコンシューマーシークレット（クライアントシークレット）です。

      • 例: e4a58ddd3d7408b7aec109e85564a0d153d3e846

  • USERFILES_LOCATION[文字列]:ユーザーがアップロードしたファイルを配置するストレージ エンジンの ID。

    • 例: s3_us_east

  • USERFILES_PATH[文字列]:ユーザーがアップロードしたファイルを配置するストレージ下のパス。

    • 例: userfiles

  • USER_RECOVERY_TOKEN_LIFETIME[文字列]:ユーザーアカウントを回復するためのトークンが有効な期間です。デフォルトでは30mです。

    • 例: 10m
    • パターン: ^[0-9]+(w|m|d|h|s)$

  • V1_PUSH_WHITELIST[配列]:FEATURE_RESTRICTED_V1_PUSHがtrueに設定されている場合、V1プッシュをサポートする名前空間名の配列です。

    • 例: some, namespaces

  • V2_PAGINATION_SIZE［数値］。V2 レジストリ API で 1 ページあたりに返される結果の数を指定します。

    • 例: 100

  • WEBHOOK_HOSTNAME_BLACKLIST[配列]: ウェブフックの検証時に許可しないホスト名のセット（localhost以外）。

    • 例: someexternaldomain.com

追加リソース

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2026 Red Hatトップに戻る