Red Hat Quay の設定
設定オプションを使用した Red Hat Quay のカスタマイズ
概要
第1章 Red Hat Quay 設定の開始
Red Hat Quay は、独立したスタンドアロン設定によって、または OpenShift Container Platform Red Hat Quay Operator を使用してデプロイできます。
Red Hat Quay 設定を作成、取得、更新、および検証する方法は、使用しているデプロイメントのタイプによって異なります。ただし、コア設定オプションはどちらのデプロイメントタイプでも同じです。コア設定は、次のオプションのいずれかで設定できます。
-
config.yamlファイルを編集して直接実行する。詳細は、設定ファイルの編集を参照してください。 - プログラムでコンフィグレーション API を使用する。詳細は、設定 API の使用を参照してください。
- 視覚的に設定ツール UI を使用する。詳細は、「設定ツールの使用」を参照してください。
Red Hat Quay のスタンドアロンデプロイメントの場合は、レジストリーを開始する前に、最低限必要な設定パラメーターを指定する必要があります。Red Hat Quay レジストリーを開始するための最小要件は、「現在の設定の取得」セクションに記載されています。
Red Hat Quay Operator を使用して OpenShift Container Platform に Red Hat Quay をインストールする場合、Red Hat Quay Operator はレジストリーをデプロイするためのデフォルト情報を提供するため、設定パラメーターを指定する必要はありません。
目的の設定で Red Hat Quay をデプロイしたら、デプロイから完全な設定を取得して保存する必要があります。完全な設定には、システムの再始動またはアップグレード時に必要になる可能性がある追加の生成値が含まれています。
第2章 Red Hat Quay 設定の免責事項
Red Hat Quay エンタープライズでは、特定の機能および設定パラメーターは積極的に使用または実装されていません。そのため、特定の機能を有効または無効にするフラグなどの機能フラグや、明示的に文書化されていない、または Red Hat サポートによって文書化が要求されていない設定パラメーターは、慎重に変更する必要があります。未使用の機能やパラメーターは完全にテスト、サポートされていない、または Red Hat Quay との互換性がない可能性があり、それを変更すると、予期しない問題やデプロイメントの中断が発生する可能性があります。
2.1. Red Hat Quay 3.9 の設定の更新
以下のセクションでは、Red Hat Quay 3.9 で追加された新しい設定フィールドについて詳しく説明します。
2.1.1. Splunk アクションログの追加
Red Hat Quay 3.9 では、Splunk を LOGS_MODEL パラメーターで設定できます。
表2.1 Splunk 設定フィールド
| フィールド | タイプ | 説明 |
|---|---|---|
| LOGS_MODEL | String |
ログデータを処理するための推奨される方法を指定します。 |
2.1.1.1. LOGS_MODEL_CONFIG の追加
Splunk を設定する場合は、次の LOGS_MODEL_CONFIG オプションを使用できます。
LOGS_MODEL_CONFIG [オブジェクト]: アクションログ用のログモデル設定
-
producer [string]:
splunk splunk_config オブジェクト: Splunk アクションログのログモデル設定または Splunk クラスター設定
- host [文字列]: Splunk クラスターのエンドポイント。
- port [整数]: Splunk 管理クラスターのエンドポイントポート。
- bearer_token [文字列]: Splunk のベアラートークン。
-
verify_ssl [ブール値]: HTTPS 接続の TLS/SSL 検証を有効 (
True) または無効 (False) にする。 - Index_prefix [文字列]: Splunk のインデックス接頭辞。
-
ssl_ca_path [文字列]: SSL 検証用の認証局 (CA) を含む単一の
.pemファイルへの相対コンテナーパス。
-
producer [string]:
2.1.1.2. Splunk の設定例
次の YAML エントリーは、Splunk の設定例を示しています。
Splunk config.yaml の例
---
LOGS_MODEL: splunk
LOGS_MODEL_CONFIG:
producer: splunk
splunk_config:
host: http://<user_name>.remote.csb
port: 8089
bearer_token: <bearer_token>
url_scheme: <http/https>
verify_ssl: False
index_prefix: <splunk_log_index_name>
ssl_ca_path: <location_to_ssl-ca-cert.pem>
---
2.1.2. クォータ管理設定フィールド
Red Hat Quay クォータ管理機能を強化するために、次の設定フィールドが追加されました。
表2.2 Red Hat Quay 3.9 クォータ管理設定フィールド
| フィールド | タイプ | 説明 |
|---|---|---|
| QUOTA_BACKFILL | Boolean |
クォータバックフィルワーカーが既存の BLOB のサイズを計算できるようにします。 |
| QUOTA_TOTAL_DELAY_SECONDS | String |
クォータバックフィルを開始するまでの遅延時間。ローリングデプロイメントでは、合計が不正確になる可能性があります。このフィールドは、ローリングデプロイメントが完了するまでにかかる時間よりも長い時間を設定する 必要があります。 |
| PERMANENTLY_DELETE_TAGS | Boolean |
タイムマシンウィンドウからのタグの削除に関連する機能を有効にします。 |
| RESET_CHILD_MANIFEST_EXPIRATION | Boolean |
子マニフェストを対象とする一時タグの有効期限をリセットします。この機能を |
2.1.2.1. 可能なクォータ管理設定
次の表は、Red Hat Quay 3.9 で可能なクォータ管理設定を説明しています。
表2.3 クォータ管理設定オプション
| FEATURE_QUOTA_MANAGEMENT | QUOTA_BACKFILL | 結果 |
|---|---|---|
|
|
|
これらの機能を |
|
|
|
|
|
|
|
これらの機能を |
|
|
|
|
2.1.2.2. 推奨されるクォータ管理設定
次の YAML は、クォータ管理を有効にするときに推奨される設定です。
推奨されるクォータ管理設定
FEATURE_QUOTA_MANAGEMENT: true FEATURE_GARBAGE_COLLECTION: true PERMANENTLY_DELETE_TAGS: true QUOTA_TOTAL_DELAY_SECONDS: 1800 RESET_CHILD_MANIFEST_EXPIRATION: true
2.1.3. PostgreSQL PVC バックアップ環境変数
バージョン 3.8 → 3.9 にアップグレードするときに、Red Hat Quay が古い Persistent Volume Claim (PVC) を自動的に削除するかどうかを設定するために、次の環境変数が追加されました。
表2.4 Red Hat Quay 3.9 PostgreSQL バックアップ環境変数
| フィールド | タイプ | 説明 |
|---|---|---|
| POSTGRES_UPGRADE_RETAIN_BACKUP | Boolean |
デフォルト: |
2.1.3.1. PostgreSQL PVC バックアップの設定例
以下の Subscription オブジェクトは、PostgreSQL 10 PVC をバックアップする設定例を提供します。
PostgreSQL 10 PVC の Subscription オブジェクト
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: quay-operator
namespace: quay-enterprise
spec:
channel: stable-3.8
name: quay-operator
source: redhat-operators
sourceNamespace: openshift-marketplace
config:
env:
- name: POSTGRES_UPGRADE_RETAIN_BACKUP
value: "true"
2.2. 設定ファイルの編集
Red Hat Quay のスタンドアロンインスタンスをデプロイするには、最小限の設定情報を提供する必要があります。最小設定の要件は、「Red Hat Quay の最小設定」に記載されています。
必須フィールドに入力したら、設定を検証できます。問題がある場合は強調表示されます。
設定 API を使用して設定を検証することもできますが、検証するには Quay コンテナーを設定モードで起動する必要があります。詳細は、「設定ツールの使用」を参照してください。
変更を有効にするには、レジストリーを再起動する必要があります。
2.3. スタンドアロンデプロイメントにおける設定ファイルの場所
Red Hat Quay のスタンドアロンデプロイメントの場合、Red Hat Quay レジストリーを開始するときに config.yaml ファイルを指定する必要があります。このファイルは設定ボリュームにあります。たとえば、次のコマンドで Red Hat Quay をデプロイする場合、設定ファイルは $QUAY/config/config.yaml にあります。
$ sudo podman run -d --rm -p 80:8080 -p 443:8443 \ --name=quay \ -v $QUAY/config:/conf/stack:Z \ -v $QUAY/storage:/datastorage:Z \ registry.redhat.io/quay/quay-rhel8:v3.9.0
2.4. 最小設定
Red Hat Quay のスタンドアロンデプロイメントには、以下の設定オプションが必要です。
- サーバーのホスト名
- HTTP または HTTPS
- 認証タイプ (データベースや LDAP (Lightweight Directory Access Protocol) など)
- データ暗号化用の秘密鍵
- イメージのストレージ
- メタデータ用のデータベース
- ビルドログおよびユーザーイベント用の Redis
- タグの有効期限オプション
2.4.1. 最小設定ファイルの例
次の例は、イメージにローカルストレージを使用する最小限の設定ファイルの例を示しています。
AUTHENTICATION_TYPE: Database
BUILDLOGS_REDIS:
host: quay-server.example.com
password: strongpassword
port: 6379
ssl: false
DATABASE_SECRET_KEY: 0ce4f796-c295-415b-bf9d-b315114704b8
DB_URI: postgresql://quayuser:quaypass@quay-server.example.com:5432/quay
DEFAULT_TAG_EXPIRATION: 2w
DISTRIBUTED_STORAGE_CONFIG:
default:
- LocalStorage
- storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
- default
PREFERRED_URL_SCHEME: http
SECRET_KEY: e8f9fe68-1f84-48a8-a05f-02d72e6eccba
SERVER_HOSTNAME: quay-server.example.com
SETUP_COMPLETE: true
TAG_EXPIRATION_OPTIONS:
- 0s
- 1d
- 1w
- 2w
- 4w
USER_EVENTS_REDIS:
host: quay-server.example.com
port: 6379
ssl: false
SETUP_COMPLETE フィールドは、設定が検証されたことを示します。レジストリーを起動する前に、設定エディターツールを使用して設定を検証する必要があります。
2.4.2. ローカルストレージ
イメージへのローカルストレージの使用は、概念実証の目的のためにレジストリーをデプロイする場合に限り推奨されます。
ローカルストレージを設定する場合は、レジストリーの起動時にコマンドラインでストレージを指定します。次のコマンドは、ローカルディレクトリー $QUAY/storage をコンテナー内の datastorage ストレージパスにマップします。
$ sudo podman run -d --rm -p 80:8080 -p 443:8443 \ --name=quay \ -v $QUAY/config:/conf/stack:Z \ -v $QUAY/storage:/datastorage:Z \ registry.redhat.io/quay/quay-rhel8:v3.9.0
2.4.3. クラウドストレージ
ストレージの設定は、イメージストレージ セクションを参照してください。一部のユーザーにとっては、Google Cloud Platform とローカルストレージ設定の違いを比較すると役立つ場合があります。たとえば、次の YAML は Google Cloud Platform のストレージ設定を表しています。
$QUAY/config/config.yaml
DISTRIBUTED_STORAGE_CONFIG:
default:
- GoogleCloudStorage
- access_key: GOOGQIMFB3ABCDEFGHIJKLMN
bucket_name: quay_bucket
secret_key: FhDAYe2HeuAKfvZCAGyOioNaaRABCDEFGHIJKLMN
storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
- default
クラウドストレージを使用してレジストリーを起動する場合は、コマンドラインでの設定が必要ありません。以下に例を示します。
$ sudo podman run -d --rm -p 80:8080 -p 443:8443 \ --name=quay \ -v $QUAY/config:/conf/stack:Z \ registry.redhat.io/quay/quay-rhel8:v3.9.0
第3章 設定フィールド
このセクションでは、Red Hat Quay のデプロイ時に必須および任意の設定フィールドの両方を説明します。
3.1. 必須の設定フィールド
Red Hat Quay の設定で必須のフィールドは、以下のセクションで説明されています。
3.2. 自動化オプション
以下のセクションでは、Red Hat Quay デプロイメントで利用可能な自動化オプションを説明します。
3.3. 任意の設定フィールド
Red Hat Quay の任意のフィールドは、以下のセクションで説明します。
3.4. 一般的な必須フィールド
以下の表は、Red Hat Quay デプロイメントの必須設定フィールドを説明しています。
表3.1 一般的な必須フィールド
| フィールド | タイプ | 説明 |
|---|---|---|
|
AUTHENTICATION_TYPE | String |
認証情報の認証に使用する認証エンジン。 |
|
PREFERRED_URL_SCHEME | String |
Red Hat Quay へのアクセスに使用する URL スキーム。 |
|
SERVER_HOSTNAME | String |
スキームなしで Red Hat Quay にアクセスできる URL。 |
|
DATABASE_SECRET_KEY | String | データベース内で機密フィールドを暗号化するのに使用されるキー。この値は、一度設定したら変更しないでください。変更すると、リポジトリーのミラーユーザー名やパスワード設定など、すべての信頼できるフィールドが無効になります。 |
|
SECRET_KEY | String | データベース内および実行時に機密フィールドを暗号化するために使用されるキー。この値は一度設定したら決して変更しないでください。そうしないと、暗号化されたパスワード資格情報などのすべての依存フィールドが無効になります。 |
|
SETUP_COMPLETE | Boolean |
これは、以前のバージョンのソフトウェアからそのまま残っているアーティファクトで、現時点では値を |
3.5. データベースの設定
このセクションでは、Red Hat Quay デプロイメントで利用可能なデータベース設定フィールドを説明します。
3.5.1. データベース URI
Red Hat Quay では、必要な DB_URI フィールドを使用してデータベースへの接続を設定します。
以下の表は DB_URI 設定フィールドを説明します。
表3.2 データベース URI
| フィールド | タイプ | 説明 |
|---|---|---|
|
DB_URI | String | 認証情報を含む、データベースにアクセスするための URI。
postgresql://quayuser:quaypass@quay-server.example.com:5432/quay |
3.5.2. データベース接続引数
オプションの接続引数は、DB_CONNECTION_ARGS パラメーターで設定されます。DB_CONNECTION_ARGS で定義されたキーと値のペアの一部は汎用的なものも、データベース固有のものもあります。
以下の表は、データベース接続引数を説明します。
表3.3 データベース接続引数
| フィールド | タイプ | 説明 |
|---|---|---|
| DB_CONNECTION_ARGS | Object | タイムアウトや SSL/TLS などのデータベースの任意の接続引数。 |
| .autorollback | Boolean |
スレッドローカル接続を使用するかどうか。 |
| .threadlocals | Boolean |
自動ロールバック接続を使用するかどうか。 |
3.5.2.1. PostgreSQL SSL/TLS 接続引数
SSL/TLS では、設定はデプロイするデータベースによって異なります。次の例は、PostgreSQL SSL/TLS 設定を示しています。
DB_CONNECTION_ARGS: sslmode: verify-ca sslrootcert: /path/to/cacert
sslmode オプションは、セキュアな SSL/TLS TCP/IP 接続がサーバーにネゴシエートされるかどうか、またはその優先度を決定します。モードは 6 つあります。
表3.4 SSL/TLS オプション
| Mode | 説明 |
|---|---|
| disable | この設定では、非 SSL/TLS 接続のみが試行されます。 |
| allow | 設定では、まず非 SSL/TLS 接続が試行されます。失敗すると、SSL/TLS 接続が試行されます。 |
|
prefer | 設定では、まず SSL/TLS 接続が試行されます。失敗すると、非 SSL/TLS 接続が試行されます。 |
| require | 設定では SSL/TLS 接続のみが試行されます。ルート CA ファイルが存在する場合は、verify-ca が指定されているのと同じ方法で証明書が検証されます。 |
| verify-ca | 設定では SSL/TLS 接続のみが試行され、サーバー証明書が信頼された認証局 (CA) によって発行されたかどうかが検証されます。 |
| verify-full | SSL/TLS 接続のみを試行し、サーバー証明書が信頼できる CA によって発行されていること、および要求されたサーバーのホスト名が証明書内のホスト名と一致することが確認されます。 |
PostgreSQL の有効な引数の詳細は、Database Connection Control Functions を参照してください。
3.5.2.2. MySQL SSL/TLS 接続引数
次の例は、MySQL SSL/TLS 設定のサンプルを示しています。
DB_CONNECTION_ARGS:
ssl:
ca: /path/to/cacertMySQL の有効な接続引数に関する情報は、Connecting to the Server Using URI-Like Strings or Key-Value Pairs を参照してください。
3.6. イメージストレージ
このセクションでは、Red Hat Quay で利用可能なイメージストレージ機能と設定フィールドを説明します。
3.6.1. イメージストレージ機能
以下の表は、Red Hat Quay のイメージストレージ機能を説明しています。
表3.5 ストレージ設定機能
| フィールド | タイプ | 説明 |
|---|---|---|
| FEATURE_REPO_MIRROR | Boolean |
true に設定されている場合は、リポジトリーのミラーリングを有効にします。 |
| FEATURE_PROXY_STORAGE | Boolean |
NGINX を使用してストレージ内のすべての直接ダウンロード URL をプロキシーするかどうか。 |
| FEATURE_STORAGE_REPLICATION | Boolean |
ストレージエンジン間で自動的にレプリケートするかどうか。 |
3.6.2. イメージストレージ設定フィールド
以下の表は、Red Hat Quay のイメージストレージ設定フィールドを説明しています。
表3.6 ストレージ設定フィールド
| フィールド | タイプ | 説明 |
|---|---|---|
|
DISTRIBUTED_STORAGE_CONFIG | Object |
Red Hat Quay で使用するストレージエンジンの設定。各キーは、ストレージエンジンの一意の ID を表します。この値は、ストレージエンジンパラメーターを記述するオブジェクトのタプル (キー、値) で設定されます。 |
|
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS | Array of string |
イメージをデフォルトで他のすべてのストレージエンジンに対して完全にレプリケートする必要のあるストレージエンジンの一覧 ( |
|
DISTRIBUTED_STORAGE_PREFERENCE | Array of string |
使用する優先ストレージエンジン ( |
| MAXIMUM_LAYER_SIZE | String |
イメージレイヤーの最大許容サイズ。 |
3.6.3. ローカルストレージ
以下の YAML は、ローカルストレージを使用した設定のサンプルを示しています。
DISTRIBUTED_STORAGE_CONFIG:
default:
- LocalStorage
- storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
- default3.6.4. OCS/NooBaa
以下の YAML は、Open Container Storage/NooBaa インスタンスを使用した設定例を示しています。
DISTRIBUTED_STORAGE_CONFIG:
rhocsStorage:
- RHOCSStorage
- access_key: access_key_here
secret_key: secret_key_here
bucket_name: quay-datastore-9b2108a3-29f5-43f2-a9d5-2872174f9a56
hostname: s3.openshift-storage.svc.cluster.local
is_secure: 'true'
port: '443'
storage_path: /datastorage/registry3.6.5. Ceph / RadosGW Storage / Hitachi HCP:
以下の YAML は、Ceph/RadosGW および Hitachi HCP ストレージを使用した設定例を示しています。
DISTRIBUTED_STORAGE_CONFIG:
radosGWStorage:
- RadosGWStorage
- access_key: access_key_here
secret_key: secret_key_here
bucket_name: bucket_name_here
hostname: hostname_here
is_secure: 'true'
port: '443'
storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
- default3.6.6. AWS S3 ストレージ
以下の YAML は、AWS S3 ストレージを使用した設定のサンプルを示しています。
DISTRIBUTED_STORAGE_CONFIG:
s3Storage:
- S3Storage
- host: s3.us-east-2.amazonaws.com
s3_access_key: ABCDEFGHIJKLMN
s3_secret_key: OL3ABCDEFGHIJKLMN
s3_bucket: quay_bucket
storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
- s3Storage3.6.7. Google Cloud Storage
以下の YAML は、Google Cloud Storage を使用した設定例を示しています。
DISTRIBUTED_STORAGE_CONFIG:
googleCloudStorage:
- GoogleCloudStorage
- access_key: GOOGQIMFB3ABCDEFGHIJKLMN
bucket_name: quay-bucket
secret_key: FhDAYe2HeuAKfvZCAGyOioNaaRABCDEFGHIJKLMN
storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
- googleCloudStorage3.6.8. Azure Storage
以下の YAML は、Azure Storage を使用した設定のサンプルを示しています。
DISTRIBUTED_STORAGE_CONFIG:
azureStorage:
- AzureStorage
- azure_account_name: azure_account_name_here
azure_container: azure_container_here
storage_path: /datastorage/registry
azure_account_key: azure_account_key_here
sas_token: some/path/
endpoint_url: https://[account-name].blob.core.usgovcloudapi.net 1
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
- azureStorage- 1
- Azure ストレージの
endpoint_urlパラメーターは任意であり、Microsoft Azure Government (MAG) エンドポイントで使用できます。空白のままにすると、endpoint_urlは通常の Azure リージョンに接続します。Red Hat Quay 3.7 以降では、MAG Blob サービスのプライマリーエンドポイントを使用する必要があります。MAG Blob サービスのセカンダリーエンドポイントを使用すると、
AuthenticationErrorDetail:Cannot find the claimed account when trying to GetProperties for the account whusc8-secondaryエラーが発生します。
3.6.9. Swift ストレージ:
以下の YAML は、Swift ストレージを使用した設定のサンプルを示しています。
DISTRIBUTED_STORAGE_CONFIG:
swiftStorage:
- SwiftStorage
- swift_user: swift_user_here
swift_password: swift_password_here
swift_container: swift_container_here
auth_url: https://example.org/swift/v1/quay
auth_version: 1
ca_cert_path: /conf/stack/swift.cert"
storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
- swiftStorage3.6.10. Nutanix オブジェクトストレージ
以下の YAML は、Nutanix オブジェクトストレージを使用した設定例を示しています。
DISTRIBUTED_STORAGE_CONFIG:
nutanixStorage: #storage config name
- RadosGWStorage #actual driver
- access_key: access_key_here #parameters
secret_key: secret_key_here
bucket_name: bucket_name_here
hostname: hostname_here
is_secure: 'true'
port: '443'
storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE: #must contain name of the storage config
- nutanixStorage3.7. Redis 設定フィールド
このセクションでは、Redis デプロイメントで利用可能な設定フィールドを説明します。
3.7.1. ビルドログ
Redis デプロイメントには、以下のビルドログ設定フィールドを利用できます。
表3.7 ビルドログの設定
| フィールド | タイプ | 説明 |
|---|---|---|
|
BUILDLOGS_REDIS | Object | ビルドログキャッシュ用の Redis 接続の詳細。 |
|
.host | String |
Redis にアクセスできるホスト名。 |
|
.port | Number |
Redis にアクセスできるポート。 |
| .password | String |
Redis インスタンスに接続するためのパスワード。 |
|
.ssl | Boolean | Redis と Quay 間の TLS 通信を有効にするかどうか。デフォルトは false です。 |
3.7.2. ユーザーイベント
Redis デプロイメントには、以下のユーザーイベントフィールドを使用できます。
表3.8 ユーザーイベント設定
| フィールド | タイプ | 説明 |
|---|---|---|
|
USER_EVENTS_REDIS | Object | ユーザーイベント処理の Redis 接続の詳細。 |
|
.host | String |
Redis にアクセスできるホスト名。 |
|
.port | Number |
Redis にアクセスできるポート。 |
| .password | String |
Redis インスタンスに接続するためのパスワード。 |
| .ssl | Boolean | Redis と Quay 間の TLS 通信を有効にするかどうか。デフォルトは false です。 |
|
.ssl_keyfile | String |
使用するクライアント証明書を格納する鍵データベースファイルの名前。 |
|
.ssl_certfile | String |
SSL 証明書のファイルパスを指定するために使用されます。 |
|
.ssl_cert_reqs | String |
SSL/TLS ハンドシェーク中に実行される証明書検証のレベルを指定するために使用されます。 |
|
.ssl_ca_certs | String |
信頼された認証局 (CA) 証明書のリストを含むファイルへのパスを指定するために使用されます。 |
|
.ssl_ca_data | String |
信頼できる CA 証明書を含む文字列を PEM 形式で指定するために使用されます。 |
|
.ssl_check_hostname | Boolean |
サーバーへの SSL/TLS 接続をセットアップするときに使用されます。サーバーの SSL/TLS 証明書のホスト名が、接続先のサーバーのホスト名と一致することをクライアントが確認する必要があるかどうかを指定します。 |
3.7.3. redis の設定例
次の YAML は、オプションの SSL/TLS フィールドを持つ Redis を使用したサンプル設定を示しています。
BUILDLOGS_REDIS: host: quay-server.example.com password: strongpassword port: 6379 ssl: true USER_EVENTS_REDIS: host: quay-server.example.com password: strongpassword port: 6379 ssl: true ssl_*: <path_location_or_certificate>
デプロイで Azure Cache for Redis を使用し、ssl が true に設定されていると、ポートは既定で 6380 になります。
3.8. ModelCache 設定オプション
以下のオプションは、ModelCache を設定するために Red Hat Quay で利用できます。
3.8.1. memcache 設定オプション
memcache は、デフォルトの ModelCache 設定オプションです。memcache を使用すると、追加の設定は必要ありません。
3.8.2. 単一の Redis 設定オプション
以下の設定は、オプションの読み取り専用レプリカを持つ単一の Redis インスタンス用です。
DATA_MODEL_CACHE_CONFIG:
engine: redis
redis_config:
primary:
host: <host>
port: <port>
password: <password if ssl is true>
ssl: <true | false >
replica:
host: <host>
port: <port>
password: <password if ssl is true>
ssl: <true | false >3.8.3. クラスター化された Redis 設定オプション
クラスター化された Redis インスタンスには、次の設定を使用します。
DATA_MODEL_CACHE_CONFIG:
engine: rediscluster
redis_config:
startup_nodes:
- host: <cluster-host>
port: <port>
password: <password if ssl: true>
read_from_replicas: <true|false>
skip_full_coverage_check: <true | false>
ssl: <true | false >3.9. タグの有効期限の設定フィールド
以下のタグの有効期限設定フィールドは Red Hat Quay で利用できます。
表3.9 タグの有効期限の設定フィールド
| フィールド | タイプ | 説明 |
|---|---|---|
| FEATURE_GARBAGE_COLLECTION | Boolean |
リポジトリーのガベージコレクションを有効にするかどうか。 |
|
TAG_EXPIRATION_OPTIONS | Array of string |
有効にすると、名前空間内のタグの有効期限についてユーザーが選択できるオプション。 |
|
DEFAULT_TAG_EXPIRATION | String |
タイムマシンのデフォルトの設定可能なタグの有効期限。 |
| FEATURE_CHANGE_TAG_EXPIRATION | Boolean |
ユーザーおよび組織が namespace のタグの有効期限を変更できるかどうか。 |
3.9.1. タグの有効期限の設定例
以下の YAML は、タグの有効期限の設定例を示しています。
DEFAULT_TAG_EXPIRATION: 2w
TAG_EXPIRATION_OPTIONS:
- 0s
- 1d
- 1w
- 2w
- 4w3.10. クォータ管理設定フィールド
表3.10 クォータ管理設定
| フィールド | タイプ | 説明 |
|---|---|---|
| FEATURE_QUOTA_MANAGEMENT | Boolean | クォータ管理機能の設定、キャッシュ、検証を有効にします。 **Default:** `False` |
| DEFAULT_SYSTEM_REJECT_QUOTA_BYTES | String | すべての組織に対してシステムのデフォルトクォータ拒否バイト許容量を有効にします。 デフォルトでは、制限は設定されていません。 |
| QUOTA_BACKFILL | Boolean | クォータバックフィルワーカーが既存の BLOB のサイズを計算できるようにします。
デフォルト: |
| QUOTA_TOTAL_DELAY_SECONDS | String | クォータバックフィルを開始するまでの遅延時間。ローリングデプロイメントでは、合計が不正確になる可能性があります。このフィールドは、ローリングデプロイメントが完了するまでにかかる時間よりも長い時間を設定する 必要があります。
デフォルト: |
| PERMANENTLY_DELETE_TAGS | Boolean | タイムマシンウィンドウからのタグの削除に関連する機能を有効にします。
デフォルト: |
| RESET_CHILD_MANIFEST_EXPIRATION | Boolean |
子マニフェストを対象とする一時タグの有効期限をリセットします。この機能を
デフォルト: |
3.10.1. クォータ管理設定の例
次の YAML は、クォータ管理を有効にするときに推奨される設定です。
クォータ管理 YAML 設定
FEATURE_QUOTA_MANAGEMENT: true FEATURE_GARBAGE_COLLECTION: true PERMANENTLY_DELETE_TAGS: true QUOTA_TOTAL_DELAY_SECONDS: 1800 RESET_CHILD_MANIFEST_EXPIRATION: true
3.11. プロキシーキャッシュ設定フィールド
表3.11 プロキシー設定
| フィールド | タイプ | 説明 |
|---|---|---|
| FEATURE_PROXY_CACHE | Boolean | Red Hat Quay がアップストリームレジストリーのプルスルーキャッシュとして機能できるようにします。
デフォルト: |
3.12. 自動化のための Red Hat Quay の事前設定
Red Hat Quay は、自動化を可能にするいくつかの設定オプションをサポートします。ユーザーはデプロイメント前にこれらのオプションを設定して、ユーザーインターフェイスとの対話の必要性を減らすことができます。
3.12.1. API による最初のユーザー作成の許可
最初のユーザーを作成するには、ユーザーは FEATURE_USER_INITIALIZE パラメーターを true に設定し、/api/v1/user/initialize API を呼び出す必要があります。既存の組織の OAuth アプリケーションによって生成された OAuth トークンを必要とする他のすべてのレジストリー API 呼び出しとは異なり、API エンドポイントは認証を必要としません。
他のユーザーが作成されていない場合、ユーザーは Red Hat Quay のデプロイ後に API を使用して quayadmin などのユーザーを作成できます。詳細は、API を使用して最初のユーザーを作成する を参照してください。
3.12.2. API 一般アクセスの有効化
Red Hat Quay レジストリー API への一般的なアクセスを許可するには、ユーザーは BROWSER_API_CALLS_XHR_ONLY 設定オプションを false に設定する必要があります。
3.12.3. スーパーユーザーの追加
Red Hat Quay をデプロイした後、ユーザーはユーザーを作成し、最初のユーザーに完全な権限を持つ管理者権限を与えることができます。ユーザーは、SUPER_USER 設定オブジェクトを使用して、事前に完全な権限を設定できます。以下に例を示します。
... SERVER_HOSTNAME: quay-server.example.com SETUP_COMPLETE: true SUPER_USERS: - quayadmin ...
3.12.4. ユーザー作成の制限
スーパーユーザーを設定した後、FEATURE_USER_CREATION を false に設定することで、新しいユーザーを作成できる権限をスーパーユーザーグループに制限できます。以下に例を示します。
... FEATURE_USER_INITIALIZE: true BROWSER_API_CALLS_XHR_ONLY: false SUPER_USERS: - quayadmin FEATURE_USER_CREATION: false ...
3.12.5. Red Hat Quay 3.8 での新機能の有効化
新しい Red Hat Quay 3.8 の機能を使用するには、次の機能の一部またはすべてを有効にします。
...
FEATURE_UI_V2: true
FEATURE_LISTEN_IP_VERSION:
FEATURE_SUPERUSERS_FULL_ACCESS: true
GLOBAL_READONLY_SUPER_USERS:
-
FEATURE_RESTRICTED_USERS: true
RESTRICTED_USERS_WHITELIST:
-
...3.12.6. Red Hat Quay 3.7 での新機能の有効化
新しい Red Hat Quay 3.7 の機能を使用するには、次の機能の一部またはすべてを有効にします。
... FEATURE_QUOTA_MANAGEMENT: true FEATURE_BUILD_SUPPORT: true FEATURE_PROXY_CACHE: true FEATURE_STORAGE_REPLICATION: true DEFAULT_SYSTEM_REJECT_QUOTA_BYTES: 102400000 ...
3.12.7. 自動化の推奨設定
自動化には、以下の config.yaml パラメーターが推奨されます。
... FEATURE_USER_INITIALIZE: true BROWSER_API_CALLS_XHR_ONLY: false SUPER_USERS: - quayadmin FEATURE_USER_CREATION: false ...
3.12.8. 初期設定を使用した Red Hat Quay Operator のデプロイ
以下の手順に従って、初期設定を使用して OpenShift Container Platform に Red Hat Quay をデプロイします。
前提条件
-
ocCLI がインストールされている。
手順
設定ファイルを使用してシークレットを作成します。
$ oc create secret generic -n quay-enterprise --from-file config.yaml=./config.yaml init-config-bundle-secret
quayregistry.yamlファイルを作成します。以下のように、管理対象外のコンポーネントを特定し、作成されたシークレットを参照します。apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: example-registry namespace: quay-enterprise spec: configBundleSecret: init-config-bundle-secret
Red Hat Quay レジストリーをデプロイします。
$ oc create -n quay-enterprise -f quayregistry.yaml
次のステップ
3.12.8.1. API を使用した最初のユーザーの作成
以下の手順に従って、Red Hat Quay 組織で最初のユーザーを作成します。
前提条件
-
設定オプション
FEATURE_USER_INITIALIZEはtrueに設定する。 - データベースにユーザーが存在していない。
この手順では、"access_token": true を指定して OAuth トークンを要求します。
root ユーザーとして、次のコマンドを入力して
python39をインストールします。$ sudo yum install python39
Python 3.9 の
pipパッケージマネージャーをアップグレードします。$ python3.9 -m pip install --upgrade pip
pipパッケージマネージャーを使用してbcryptパッケージをインストールします。$ pip install bcrypt
次のコマンドを入力して、Python 3.9 の
bcryptパッケージを使用して、安全なハッシュ化されたパスワードを生成します。$ python3.9 -c 'import bcrypt; print(bcrypt.hashpw(b"subquay12345", bcrypt.gensalt(12)).decode("utf-8"))'Red Hat Quay 設定ファイルを開き、以下の設定フィールドを更新します。
FEATURE_USER_INITIALIZE: true SUPER_USERS: - quayadmin次のコマンドを入力して、Red Hat Quay サービスを停止します。
$ sudo podman stop quay
次のコマンドを入力して、Red Hat Quay サービスを開始します。
$ sudo podman run -d -p 80:8080 -p 443:8443 --name=quay -v $QUAY/config:/conf/stack:Z -v $QUAY/storage:/datastorage:Z {productrepo}/{quayimage}:{productminv}次の
CURLコマンドを実行して、ユーザー名、パスワード、電子メール、およびアクセストークンを使用して新しいユーザーを生成します。$ curl -X POST -k http://quay-server.example.com/api/v1/user/initialize --header 'Content-Type: application/json' --data '{ "username": "quayadmin", "password":"quaypass12345", "email": "quayadmin@example.com", "access_token": true}'成功すると、このコマンドはユーザー名、メール、および暗号化されたパスワードが含まれるオブジェクトを返します。以下に例を示します。
{"access_token":"6B4QTRSTSD1HMIG915VPX7BMEZBVB9GPNY2FC2ED", "email":"quayadmin@example.com","encrypted_password":"1nZMLH57RIE5UGdL/yYpDOHLqiNCgimb6W9kfF8MjZ1xrfDpRyRs9NUnUuNuAitW","username":"quayadmin"} # gitleaks:allowデータベースにユーザーが存在している場合は、エラーが返されます。
{"message":"Cannot initialize user in a non-empty database"}パスワードが 8 文字以上でない場合や、空白が含まれている場合には、エラーが返されます。
{"message":"Failed to initialize user: Invalid password, password must be at least 8 characters and contain no whitespace."}以下のコマンドを入力して、Red Hat Quay デプロイメントにログインします。
$ sudo podman login -u quayadmin -p quaypass12345 http://quay-server.example.com --tls-verify=false
出力例
Login Succeeded!
3.12.8.2. OAuth トークンの使用
API の呼び出し後に、返される OAuth コードを指定して残りの Red Hat Quay API を呼び出すことができます。
前提条件
-
/api/v1/user/initializeAPI を呼び出し、ユーザー名、パスワード、およびメールアドレスに渡している。
手順
以下のコマンドを入力して、現在のユーザーの一覧を取得します。
$ curl -X GET -k -H "Authorization: Bearer 6B4QTRSTSD1HMIG915VPX7BMEZBVB9GPNY2FC2ED" https://example-registry-quay-quay-enterprise.apps.docs.quayteam.org/api/v1/superuser/users/
出力例:
{ "users": [ { "kind": "user", "name": "quayadmin", "username": "quayadmin", "email": "quayadmin@example.com", "verified": true, "avatar": { "name": "quayadmin", "hash": "3e82e9cbf62d25dec0ed1b4c66ca7c5d47ab9f1f271958298dea856fb26adc4c", "color": "#e7ba52", "kind": "user" }, "super_user": true, "enabled": true } ] }このインスタンスでは、これまで作成した唯一のユーザーであるため、
quayadminユーザーの詳細が返されます。
3.12.8.3. API を使用した組織の作成
以下の手順では、API を使用して Red Hat Quay 組織を作成する方法を説明します。
前提条件
-
/api/v1/user/initializeAPI を呼び出し、ユーザー名、パスワード、およびメールアドレスに渡している。 - 返された OAuth コードを指定して、残りの Red Hat Quay API を呼び出している。
手順
組織を作成するには、
api/v1/organization/エンドポイントへの POST 呼び出しを使用します。$ curl -X POST -k --header 'Content-Type: application/json' -H "Authorization: Bearer 6B4QTRSTSD1HMIG915VPX7BMEZBVB9GPNY2FC2ED" https://example-registry-quay-quay-enterprise.apps.docs.quayteam.org/api/v1/organization/ --data '{"name": "testorg", "email": "testorg@example.com"}'出力例:
"Created"
以下のコマンドを入力して、作成した組織の詳細を取得できます。
$ curl -X GET -k --header 'Content-Type: application/json' -H "Authorization: Bearer 6B4QTRSTSD1HMIG915VPX7BMEZBVB9GPNY2FC2ED" https://min-registry-quay-quay-enterprise.apps.docs.quayteam.org/api/v1/organization/testorg
出力例:
{ "name": "testorg", "email": "testorg@example.com", "avatar": { "name": "testorg", "hash": "5f113632ad532fc78215c9258a4fb60606d1fa386c91b141116a1317bf9c53c8", "color": "#a55194", "kind": "user" }, "is_admin": true, "is_member": true, "teams": { "owners": { "name": "owners", "description": "", "role": "admin", "avatar": { "name": "owners", "hash": "6f0e3a8c0eb46e8834b43b03374ece43a030621d92a7437beb48f871e90f8d90", "color": "#c7c7c7", "kind": "team" }, "can_view": true, "repo_count": 0, "member_count": 1, "is_synced": false } }, "ordered_teams": [ "owners" ], "invoice_email": false, "invoice_email_address": null, "tag_expiration_s": 1209600, "is_free_account": true }
3.13. 基本設定フィールド
表3.12 基本設定
| フィールド | タイプ | 説明 |
|---|---|---|
| REGISTRY_TITLE | String |
指定されている場合、レジストリーの長いタイトル。Red Hat Quay デプロイメントのフロントエンド (組織のサインインページなど) に表示されます。35 文字を超えないようにしてください。 |
| REGISTRY_TITLE_SHORT | String |
指定されている場合は、省略形式のレジストリーのタイトル。タイトルは、組織のさまざまなページに表示されます。たとえば、組織の Tutorial ページのチュートリアルのタイトルとして表示されます。 |
| CONTACT_INFO | Array of string | 指定されている場合は、連絡先ページに表示される連絡先情報。連絡先が 1 つしか指定されていない場合は、連絡先のフッターが直接リンクされます。 |
| [0] | String |
電子メールを送信するためのリンクを追加します。 |
| [1] | String |
IRC チャットルームにアクセスするためのリンクを追加します。 |
| [2] | String |
電話番号を呼び出すためのリンクを追加します。+ |
| [3] | String |
定義された URL へのリンクを追加します。 |
3.14. SSL 設定フィールド
表3.13 SSL 設定
| フィールド | タイプ | 説明 |
|---|---|---|
| PREFERRED_URL_SCHEME | String |
+ TLS を終了するロードバランサー、リバースプロキシー (Nginx など) を使用する場合、またはカスタム SSL 証明書で Quay を直接使用する場合、ユーザーは |
|
SERVER_HOSTNAME | String |
スキームなしで Red Hat Quay にアクセスできる URL。 |
| SSL_CIPHERS | Array of string |
指定されている場合は、有効化および無効化する SSL 暗号の nginx 定義の一覧。 |
| SSL_PROTOCOLS | Array of string |
指定されている場合、nginx は、一覧で定義される SSL プロトコルの一覧を有効にするように設定されます。リストから SSL プロトコルを削除すると、Red Hat Quay の起動時にそのプロトコルが無効になります。 |
| SESSION_COOKIE_SECURE | Boolean |
セッションクッキーに |
3.14.1. SSL の設定
証明書ファイルとプライマリーキーファイルを設定ディレクトリーにコピーして、それぞれ
ssl.certとssl.keyという名前が付けられていることを確認します。$ cp ~/ssl.cert $QUAY/config $ cp ~/ssl.key $QUAY/config $ cd $QUAY/config
config.yamlファイルを編集し、Quay で TLS を処理できるように指定します。config.yaml
... SERVER_HOSTNAME: quay-server.example.com ... PREFERRED_URL_SCHEME: https ...
-
Quayコンテナーを停止し、レジストリーを再起動します。
3.15. Red Hat Quay コンテナーへの TLS 証明書の追加
カスタム TLS 証明書を Red Hat Quay に追加するには、Red Hat Quay の config ディレクトリーの下に extra_ca_certs/ という名前の新しいディレクトリーを作成します。必要なサイト固有の TLS 証明書をこの新しいディレクトリーにコピーします。
3.15.1. TLS 証明書を Red Hat Quay に追加
コンテナーに追加される証明書を表示します。
$ cat storage.crt -----BEGIN CERTIFICATE----- MIIDTTCCAjWgAwIBAgIJAMVr9ngjJhzbMA0GCSqGSIb3DQEBCwUAMD0xCzAJBgNV [...] -----END CERTIFICATE-----
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
QuayコンテナーのCONTAINER IDをpodman psで取得します。$ sudo podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS 5a3e82c4a75f <registry>/<repo>/quay:v3.9.0 "/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
その ID でコンテナーを再起動します。
$ sudo podman restart 5a3e82c4a75f
コンテナーの名前空間にコピーされた証明書を調べます。
$ sudo podman exec -it 5a3e82c4a75f cat /etc/ssl/certs/storage.pem -----BEGIN CERTIFICATE----- MIIDTTCCAjWgAwIBAgIJAMVr9ngjJhzbMA0GCSqGSIb3DQEBCwUAMD0xCzAJBgNV
3.16. LDAP 設定フィールド
表3.14 LDAP の設定
| フィールド | タイプ | 説明 |
|---|---|---|
|
AUTHENTICATION_TYPE | String |
|
| FEATURE_TEAM_SYNCING | Boolean |
認証エンジン (LDAP または Keystone) のバッキンググループからのチームメンバーシップの同期を許可するかどうか。 |
| FEATURE_NONSUPERUSER_TEAM_SYNCING_SETUP | Boolean |
有効にすると、スーパーユーザー以外も LDAP を使用してチームでの同期をセットアップできます。 |
| LDAP_ADMIN_DN | String | LDAP 認証の管理 DN。 |
| LDAP_ADMIN_PASSWD | String | LDAP 認証の管理パスワード。 |
| LDAP_ALLOW_INSECURE_FALLBACK | Boolean | LDAP 認証で SSL の非セキュアなフォールバックを許可するかどうか。 |
| LDAP_BASE_DN | Array of string | LDAP 認証のベース DN。 |
| LDAP_EMAIL_ATTR | String | LDAP 認証のメール属性。 |
| LDAP_UID_ATTR | String | LDAP 認証の uid 属性。 |
| LDAP_URI | String | LDAP URI。 |
| LDAP_USER_FILTER | String | LDAP 認証のユーザーフィルター。 |
| LDAP_USER_RDN | Array of string | LDAP 認証のユーザー RDN。 |
| TEAM_RESYNC_STALE_TIME | String |
チームでチーム同期が有効になっている場合は、そのメンバーシップを確認し、必要に応じて再同期する頻度。 |
| LDAP_SUPERUSER_FILTER | String |
このフィールドを使用すると、管理者は Red Hat Quay 設定ファイルを更新してデプロイメントを再起動することなく、スーパーユーザーを追加または削除できます。
このフィールドでは、 |
| LDAP_RESTRICTED_USER_FILTER | String |
このフィールドでは、 |
| LDAP_TIMEOUT | Integer |
LDAP (Lightweight Directory Access Protocol) サーバーへの接続を確立するのに許可される最大時間を秒単位で指定します。
デフォルト: |
| LDAP_NETWORK_TIMEOUT | Integer |
Red Hat Quay がネットワーク操作中に LDAP (Lightweight Directory Access Protocol)サーバーからの応答を待つ最大時間を秒単位で定義します。
デフォルト: |
3.16.1. LDAP 設定リファレンス
次の参照を使用して、目的の設定フィールドで config.yaml ファイルを更新します。
3.16.1.1. 基本的な LDAP 設定
---
AUTHENTICATION_TYPE: LDAP
---
LDAP_ADMIN_DN: uid=<name>,ou=Users,o=<organization_id>,dc=<example_domain_component>,dc=com
LDAP_ADMIN_PASSWD: ABC123
LDAP_ALLOW_INSECURE_FALLBACK: false
LDAP_BASE_DN:
- o=<organization_id>
- dc=<example_domain_component>
- dc=com
LDAP_EMAIL_ATTR: mail
LDAP_UID_ATTR: uid
LDAP_URI: ldaps://<ldap_url_domain_name>
LDAP_USER_FILTER: (memberof=cn=developers,ou=Users,dc=<domain_name>,dc=com)
LDAP_USER_RDN:
- ou=<example_organization_unit>
- o=<organization_id>
- dc=<example_domain_component>
- dc=com3.16.1.2. LDAP 制限付きユーザー設定
---
AUTHENTICATION_TYPE: LDAP
---
LDAP_ADMIN_DN: uid=<name>,ou=Users,o=<organization_id>,dc=<example_domain_component>,dc=com
LDAP_ADMIN_PASSWD: ABC123
LDAP_ALLOW_INSECURE_FALLBACK: false
LDAP_BASE_DN:
- o=<organization_id>
- dc=<example_domain_component>
- dc=com
LDAP_EMAIL_ATTR: mail
LDAP_UID_ATTR: uid
LDAP_URI: ldap://<example_url>.com
LDAP_USER_FILTER: (memberof=cn=developers,ou=Users,o=<example_organization_unit>,dc=<example_domain_component>,dc=com)
LDAP_RESTRICTED_USER_FILTER: (<filterField>=<value>)
LDAP_USER_RDN:
- ou=<example_organization_unit>
- o=<organization_id>
- dc=<example_domain_component>
- dc=com
---3.16.1.3. LDAP スーパーユーザー設定リファレンス
---
AUTHENTICATION_TYPE: LDAP
---
LDAP_ADMIN_DN: uid=<name>,ou=Users,o=<organization_id>,dc=<example_domain_component>,dc=com
LDAP_ADMIN_PASSWD: ABC123
LDAP_ALLOW_INSECURE_FALLBACK: false
LDAP_BASE_DN:
- o=<organization_id>
- dc=<example_domain_component>
- dc=com
LDAP_EMAIL_ATTR: mail
LDAP_UID_ATTR: uid
LDAP_URI: ldap://<example_url>.com
LDAP_USER_FILTER: (memberof=cn=developers,ou=Users,o=<example_organization_unit>,dc=<example_domain_component>,dc=com)
LDAP_SUPERUSER_FILTER: (<filterField>=<value>)
LDAP_USER_RDN:
- ou=<example_organization_unit>
- o=<organization_id>
- dc=<example_domain_component>
- dc=com3.17. 設定フィールドのミラーリング
表3.15 ミラーリング設定
| フィールド | タイプ | 説明 |
|---|---|---|
| FEATURE_REPO_MIRROR | Boolean |
リポジトリーミラーリングを有効または無効にします。 |
| REPO_MIRROR_INTERVAL | Number |
次にリポジトリーミラー候補をチェックするまでの秒数。 |
| REPO_MIRROR_SERVER_HOSTNAME | String |
|
| REPO_MIRROR_TLS_VERIFY | Boolean |
HTTPS を必要とし、ミラー時に Quay レジストリーの証明書を検証します。 |
| REPO_MIRROR_ROLLBACK | Boolean |
デフォルト: |
3.18. セキュリティースキャナー設定フィールド
表3.16 セキュリティースキャナーの設定
| フィールド | タイプ | 説明 |
|---|---|---|
| FEATURE_SECURITY_SCANNER | Boolean |
セキュリティースキャナー。 |
| FEATURE_SECURITY_NOTIFICATIONS | Boolean |
セキュリティースキャナーが有効になっている場合は、セキュリティー通知を有効にするか、オフにします。 |
| SECURITY_SCANNER_V4_REINDEX_THRESHOLD | String |
このパラメーターは、最終のインデックス作成から状態が変更されたか、以前に失敗したマニフェストのインデックスをもう一度作成するまで待機する最小時間を判断するのに使用します。データは manifestsecuritystatus テーブルの |
| SECURITY_SCANNER_V4_ENDPOINT | String |
V4 セキュリティースキャナーのエンドポイント。 |
| SECURITY_SCANNER_V4_PSK | String | Clair 用に生成された共有キー (PSK)。 |
| SECURITY_SCANNER_ENDPOINT | String |
V2 セキュリティースキャナーのエンドポイント。 |
| SECURITY_SCANNER_INDEXING_INTERVAL | Integer |
このパラメーターは、セキュリティースキャナーのインデックス作成の間隔 (秒単位) を決定するために使用されます。インデックスのトリガーが発生すると、Red Hat Quay は、Clair でインデックス化する必要のあるマニフェストに対してそのデータベースをクエリーします。これには、インデックス付けされていないマニフェストや、以前にインデックス付けに失敗したマニフェストが含まれます。 + デフォルト: 30 |
| FEATURE_SECURITY_SCANNER_NOTIFY_ON_NEW_INDEX | Boolean | 新しいプッシュの脆弱性に関する通知の送信を許可するかどうか。
+ デフォルト*: |
3.18.1. Clair v4 によるインデックスの再作成
Clair v4 がマニフェストをインデックス化する場合は、結果として、決定論的なものである必要があります。たとえば、同じマニフェストが同じインデックスレポートを生成する必要があります。これは、異なるスキャナーを使用するとレポートで返される特定のマニフェストに関連して異なる情報を生成するため、スキャナーが変更されるまで True となります。そのため、Clair v4 はインデックスエンジン (/indexer/api/v1/index_state) の状態表現を公開し、スキャナー設定が変更されたかどうかを判別します。
Red Hat Quay は、Quay のデータベースの解析時にこれをインデックスレポートに保存し、このインデックス状態を活用します。以前にスキャンされてからこの状態が変更された場合、Red Hat Quay は定期的なインデックスプロセス時にマニフェストの再作成を試行します。
デフォルトでは、このパラメーターは 30 秒に設定されています。インデックス作成のプロセスをより頻繁に実行する場合は、時間を短縮します。たとえば、新規タグをプッシュしてから、30 秒待たずに、UI でセキュリティースキャンの結果を表示する場合などです。また、ユーザーは要求パターンを Clair に制御し、Red Hat Quay データベースで実行されるデータベース操作のパターンをより詳細に制御する必要がある場合にパラメーターを変更することもできます。
3.18.2. セキュリティースキャナーの設定の例
次の YAML は、セキュリティースキャナー機能を有効にする場合の推奨設定です。
セキュリティースキャナーの YAML 設定
FEATURE_SECURITY_NOTIFICATIONS: true FEATURE_SECURITY_SCANNER: true FEATURE_SECURITY_SCANNER_NOTIFY_ON_NEW_INDEX: true ... SECURITY_SCANNER_INDEXING_INTERVAL: 30 SECURITY_SCANNER_V4_ENDPOINT: http://quay-server.example.com:8081 SECURITY_SCANNER_V4_PSK: MTU5YzA4Y2ZkNzJoMQ== SERVER_HOSTNAME: quay-server.example.com ...
3.19. Helm 設定フィールド
表3.17 Helm 設定フィールド
| フィールド | タイプ | 説明 |
|---|---|---|
| FEATURE_GENERAL_OCI_SUPPORT | Boolean |
OCI アーティファクトのサポートを有効にします。 |
次の Open Container Initiative (OCI) アーティファクトタイプは、デフォルトで Red Hat Quay に組み込まれており、FEATURE_GENERAL_OCI_SUPPORT 設定フィールドを通じて有効になります。
| フィールド | メディアタイプ | サポートされているコンテンツタイプ |
|---|---|---|
| Helm |
|
|
| Cosign |
|
|
| SPDX |
|
|
| Syft |
|
|
| CycloneDX |
|
|
| In-toto |
|
|
| Unknown |
|
|
3.19.1. Helm の設定
次の YAML は、Helm を有効にする場合の設定例です。
Helm YAML 設定
FEATURE_GENERAL_OCI_SUPPORT: true
3.20. Open Container Initiative 設定フィールド
表3.18 追加の OCI アーティファクト設定フィールド
| フィールド | タイプ | 説明 |
|---|---|---|
| ALLOWED_OCI_ARTIFACT_TYPES | Object | 許可される OCI アーティファクト MIME タイプと関連するレイヤータイプのセット。 |
3.20.1. 追加のアーティファクトタイプの設定
デフォルトでサポートされていない他の OCI アーティファクトタイプは、ALLOWED_OCI_ARTIFACT_TYPES 設定フィールドを使用して Red Hat Quay デプロイメントに追加できます。
追加の OCI アーティファクトタイプを追加するには、次のリファレンスを使用します。
OCI アーティファクトタイプの設定
FEATURE_GENERAL_OCI_SUPPORT: true ALLOWED_OCI_ARTIFACT_TYPES: <oci config type 1>: - <oci layer type 1> - <oci layer type 2> <oci config type 2>: - <oci layer type 3> - <oci layer type 4>
たとえば、以下を config.yaml に追加して Singularity (SIF) サポートを追加できます。
OCI アーティファクトタイプの設定例
ALLOWED_OCI_ARTIFACT_TYPES: application/vnd.oci.image.config.v1+json: - application/vnd.dev.cosign.simplesigning.v1+json application/vnd.cncf.helm.config.v1+json: - application/tar+gzip application/vnd.sylabs.sif.config.v1+json: - application/vnd.sylabs.sif.layer.v1+tar
デフォルトで設定されていない OCI アーティファクトタイプを追加する場合、Red Hat Quay 管理者は、必要に応じて cosign と Helm のサポートを手動で追加する必要もあります。
3.21. 不明なメディアタイプ
表3.19 不明なメディアタイプ設定フィールド
| フィールド | タイプ | 説明 |
|---|---|---|
| IGNORE_UNKNOWN_MEDIATYPES | Boolean | 有効にすると、コンテナーレジストリープラットフォームは、サポートされているアーティファクトタイプに関する特定の制限を無視し、認識されないメディアタイプまたは未知のメディアタイプを受け入れることができます。
デフォルト: |
3.21.1. 不明なメディアタイプの設定
次の YAML は、不明なメディアタイプまたは認識されないメディアタイプを有効にする場合の設定例です。
不明なメディアタイプの YAML 設定
IGNORE_UNKNOWN_MEDIATYPES: true
3.22. アクションログ設定フィールド
3.22.1. アクションログストレージ設定
表3.20 アクションログストレージ設定
| フィールド | タイプ | 説明 |
|---|---|---|
| FEATURE_LOG_EXPORT | Boolean |
アクションログのエクスポートを許可するかどうか。 |
| LOGS_MODEL | String |
ログデータを処理するための推奨される方法を指定します。 |
| LOGS_MODEL_CONFIG | Object | アクションログのログモデル設定。 |
LOGS_MODEL_CONFIG [オブジェクト]: アクションログ用のログモデル設定。
elasticsearch_config [オブジェクト]: Elasticsearch クラスターの設定。
access_key [文字列] :Elasticsearch のユーザー (AWS ES の場合は IAM キー)。
-
例:
some_string
-
例:
host [文字列]: 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 [文字列]: Amazon Web サービスの地域。
-
例:
us-east-1
-
例:
port [番号]: Elasticsearch クラスターのエンドポイントポート。
-
例:
1234
-
例:
kinesis_stream_config [オブジェクト]: AWS Kinesis ストリームの設定。
aws_secret_key [文字列]: AWS の秘密鍵。
-
例:
some_secret_key
-
例:
stream_name [文字列]: アクションログの送信先となる Kinesis ストリーム。
-
例:
logentry-kinesis-stream
-
例:
aws_access_key [文字列]: AWS アクセスキー。
-
例:
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 トピック。
-
例:
logentry
-
例:
- bootstrap_servers [配列]: クライアントをブートストラップさせる Kafka ブローカーのリスト。
max_block_seconds [番号]:
send()の実行中に、バッファーがいっぱいになったり、メタデータが利用できないなどの理由でブロックする最大秒数。-
例:
10
-
例:
-
producer [string]:
splunk splunk_config オブジェクト: Splunk アクションログのログモデル設定または Splunk クラスター設定。
- host [文字列]: Splunk クラスターのエンドポイント。
- port [整数]: Splunk 管理クラスターのエンドポイントポート。
- bearer_token [文字列]: Splunk のベアラートークン。
-
verify_ssl [ブール値]: HTTPS 接続の TLS/SSL 検証を有効 (
True) または無効 (False) にする。 - Index_prefix [文字列]: Splunk のインデックス接頭辞。
-
ssl_ca_path [文字列]: SSL 検証用の認証局 (CA) を含む単一の
.pemファイルへの相対コンテナーパス。
3.22.2. アクションログのローテーションおよびアーカイブ設定
表3.21 アクションログのローテーションおよびアーカイブ設定
| フィールド | タイプ | 説明 |
|---|---|---|
| FEATURE_ACTION_LOG_ROTATION | Boolean |
ログローテーションおよび archival を有効にすると、30 日以上経過したすべてのログをストレージに移動します。 |
| ACTION_LOG_ARCHIVE_LOCATION | String |
アクションログのアーカイブが有効な場合は、アーカイブされたデータを配置するストレージエンジン。 |
| ACTION_LOG_ARCHIVE_PATH | String |
アクションログのアーカイブが有効な場合は、アーカイブされたデータを配置するストレージのパス。 |
| ACTION_LOG_ROTATION_THRESHOLD | String |
ログをローテーションする間隔。 |
3.23. ビルドログ設定フィールド
表3.22 ビルドログ設定フィールド
| フィールド | タイプ | 説明 |
|---|---|---|
| FEATURE_READER_BUILD_LOGS | Boolean |
true に設定されている場合、書き込みアクセスや管理アクセスがある場合だけでなく、リポジトリーへの読み取りアクセスを持つユーザーがビルドログを読み取ることができます。 |
| LOG_ARCHIVE_LOCATION | String |
アーカイブされたビルドログを配置する、 DISTRIBUTED_STORAGE_CONFIG で定義されたストレージの場所。 |
| LOG_ARCHIVE_PATH | String |
アーカイブされたビルドログを JSON 形式で配置する、設定されたストレージエンジンの下のパス。 |
3.24. Dockerfile ビルドトリガーフィールド
表3.23 Dockerfile ビルドのサポート
| フィールド | タイプ | 説明 |
|---|---|---|
| FEATURE_BUILD_SUPPORT | Boolean |
Dockerfile ビルドをサポートするかどうか。 |
| SUCCESSIVE_TRIGGER_FAILURE_DISABLE_THRESHOLD | Number |
None ではない場合に、ビルドトリガーが自動的に無効にされる前に、連続で失敗できる回数。 |
| SUCCESSIVE_TRIGGER_INTERNAL_ERROR_DISABLE_THRESHOLD | Number |
None ではない場合に、ビルドトリガーが自動的に無効にされる前に、連続で発生可能な内部エラーの回数。 |
3.24.1. GitHub ビルドトリガー
表3.24 GitHub ビルドトリガー
| フィールド | タイプ | 説明 |
|---|---|---|
| FEATURE_GITHUB_BUILD | Boolean |
GitHub ビルドトリガーをサポートしているかどうか。 |
|
|
|
|
| GITHUB_TRIGGER_CONFIG | Object | ビルドトリガーに GitHub (Enterprise) を使用するための設定。 |
|
.GITHUB_ENDPOINT | String |
GitHub (Enterprise) のエンドポイント。 |
| .API_ENDPOINT | String |
使用する GitHub (Enterprise) API のエンドポイント。 |
|
.CLIENT_ID | String | この Red Hat Quay インスタンスの登録されたクライアント ID。GITHUB_LOGIN_CONFIG と共有にすることはできません。 |
|
.CLIENT_SECRET | String | この Red Hat Quay インスタンスの登録されたクライアントシークレット。 |
3.24.2. Bitbucket ビルドトリガー
表3.25 Bitbucket ビルドトリガー
| フィールド | タイプ | 説明 |
|---|---|---|
| FEATURE_BITBUCKET_BUILD | Boolean |
Bitbucket ビルドトリガーをサポートしているかどうか |
|
|
|
|
| BITBUCKET_TRIGGER_CONFIG | Object | ビルドトリガーに BitBucket を使用するための設定 |
|
.CONSUMER_KEY | String | この Quay インスタンスの登録されたコンシューマーキー (クライアント ID) |
|
.CONSUMER_SECRET | String | この Quay インスタンスの、登録されたコンシューマーシークレット (クライアントシークレット) |
3.24.3. GitLab ビルドトリガー
表3.26 GitLab ビルドトリガー
| フィールド | タイプ | 説明 |
|---|---|---|
| FEATURE_GITLAB_BUILD | Boolean |
GitLab ビルドトリガーをサポートしているかどうか |
|
|
|
|
| GITLAB_TRIGGER_CONFIG | Object | ビルドトリガーに Gitlab を使用するための設定 |
|
.GITLAB_ENDPOINT | String | Gitlab (Enterprise) が実行されているエンドポイント |
|
.CLIENT_ID | String | この Quay インスタンスの、登録されたクライアント ID |
|
.CLIENT_SECRET | String | この Quay インスタンスの、登録されたクライアントシークレット |
3.25. OAuth 設定フィールド
表3.27 OAuth フィールド
| フィールド | タイプ | 説明 |
|---|---|---|
| DIRECT_OAUTH_CLIENTID_WHITELIST | Array of string | ユーザーの承認なしに直接 OAuth 承認を実行できる Red Hat Quay 管理 アプリケーションのクライアント ID の一覧。 |
3.25.1. GitHub OAuth 設定フィールド
表3.28 GitHub OAuth フィールド
| フィールド | タイプ | 説明 |
|---|---|---|
| FEATURE_GITHUB_LOGIN | Boolean |
GitHub ログインがサポートされるかどうか。 |
| GITHUB_LOGIN_CONFIG | Object | 外部ログインプロバイダーとして GitHub (Enterprise) を使用するための設定。 |
| .ALLOWED_ORGANIZATIONS | Array of string | ORG_RESTRICT オプションを使用するためにホワイトリスト化された GitHub (Enterprise) 組織の名前。 |
| .API_ENDPOINT | String |
使用する GitHub (Enterprise) API のエンドポイント。github.com に対してオーバーライドする必要があります。 |
|
.CLIENT_ID | String |
この Red Hat Quay インスタンスの登録されたクライアント ID。GITHUB_TRIGGER_CONFIG とは共有できません。 |
|
.CLIENT_SECRET | String |
Red Hat Quay インスタンスの登録クライアントシークレット。 |
|
.GITHUB_ENDPOINT | String |
GitHub (Enterprise) のエンドポイント。 |
| .ORG_RESTRICT | Boolean | true の場合は、組織のホワイトリスト内のユーザーのみが、このプロバイダーを使用してログインできます。 |
3.25.2. Google OAuth 設定フィールド
表3.29 Google OAuth フィールド
| フィールド | タイプ | 説明 |
|---|---|---|
| FEATURE_GOOGLE_LOGIN | Boolean |
Google ログインがサポートされるかどうか。 |
| GOOGLE_LOGIN_CONFIG | Object | 外部認証に Google を使用するための設定。 |
|
.CLIENT_ID | String |
この Red Hat Quay インスタンスの登録されたクライアント ID。 |
|
.CLIENT_SECRET | String |
Red Hat Quay インスタンスの登録クライアントシークレット。 |
3.26. OIDC 設定フィールド
表3.30 OIDC フィールド
| フィールド | タイプ | 説明 |
|
<文字列>_LOGIN_CONFIG | String |
OIDC 設定を保持する親キー。通常は、OIDC プロバイダーの名前 ( |
|
.CLIENT_ID | String |
この Red Hat Quay インスタンスの登録されたクライアント ID。 |
|
.CLIENT_SECRET | String |
Red Hat Quay インスタンスの登録クライアントシークレット。 |
| .DEBUGLOG | Boolean | デバッグを有効にするかどうか。 |
| .LOGIN_BINDING_FIELD | String | 内部承認が LDAP に設定されている場合に使用されます。Red Hat Quay はこのパラメーターを読み取り、このユーザー名でユーザーの LDAP ツリーで検索を試みます。存在する場合は、その LDAP アカウントへのリンクが自動的に作成されます。 |
| .LOGIN_SCOPES | Object | Red Hat Quay が OIDC プロバイダーとの通信に使用するスコープを追加します。 |
| .OIDC_ENDPOINT_CUSTOM_PARAMS | String |
OIDC エンドポイントでのカスタムクエリーパラメーターのサポートを追加しました。エンドポイント |
| .OIDC_ISSUER | String |
ユーザーが検証する発行者を定義できます。たとえば、JWT トークンは、トークンを発行したユーザーを定義する |
|
.OIDC_SERVER | String |
認証に使用される OIDC サーバーのアドレス。 |
| .PREFERRED_USERNAME_CLAIM_NAME | String | 優先ユーザー名をトークンのパラメーターに設定します。 |
| .SERVICE_ICON | String | ログイン画面のアイコンを変更します。 |
|
.SERVICE_NAME | String |
認証されているサービスの名前。 |
| .VERIFIED_EMAIL_CLAIM_NAME | String | ユーザーの電子メールアドレスを確認するために使用されるクレームの名前。 |
3.26.1. OIDC 設定
以下の例は、OIDC 設定のサンプルを示しています。
OIDC 設定の例
AZURE_LOGIN_CONFIG:
CLIENT_ID: <client_id>
CLIENT_SECRET: <client_secret>
OIDC_SERVER: <oidc_server_address_>
DEBUGGING: true
SERVICE_NAME: Azure AD
VERIFIED_EMAIL_CLAIM_NAME: <verified_email>
OIDC_ENDPOINT_CUSTOM_PARAMS":
"authorization_endpoint":
"some": "param",
3.27. ネストされたリポジトリー設定フィールド
ネストされたリポジトリーパス名のサポートが FEATURE_EXTENDED_REPOSITORY_NAMES プロパティーに追加されました。このオプションの設定は、デフォルトで config.yaml に追加されます。有効にすると、リポジトリー名で / を使用できます。
表3.31 OCI およびネストされたリポジトリー設定フィールド
| フィールド | タイプ | 説明 |
|---|---|---|
| FEATURE_EXTENDED_REPOSITORY_NAMES | Boolean |
ネストされたリポジトリーのサポートを有効にします。 |
OCI とネストされたリポジトリーの設定例
FEATURE_EXTENDED_REPOSITORY_NAMES: true
3.28. メール設定フィールド
表3.32 メール設定フィールド
| フィールド | タイプ | 説明 |
|---|---|---|
| FEATURE_MAILING | Boolean |
メールが有効かどうか |
| MAIL_DEFAULT_SENDER | String |
指定されている場合、Red Hat Quay がメールを送信する際の |
| MAIL_PASSWORD | String | メールの送信時に使用する SMTP パスワード。 |
| MAIL_PORT | Number | 使用する SMTP ポート。指定されていない場合は、デフォルトの 587 になります。 |
| MAIL_SERVER | String |
メールの送信に使用する SMTP サーバー。FEATURE_MAILING が true に設定されている場合にのみ必要です。 |
| MAIL_USERNAME | String | メールの送信時に使用する SMTP ユーザー名。 |
| MAIL_USE_TLS | Boolean |
指定されている場合は、電子メールの送信に TLS を使用するかどうか。 |
3.29. ユーザー設定フィールド
表3.33 ユーザー設定フィールド
| フィールド | タイプ | 説明 |
|---|---|---|
| FEATURE_SUPER_USERS | Boolean |
スーパーユーザーがサポートされるかどうか。 |
| FEATURE_USER_CREATION | Boolean |
ユーザーを作成できるようにするかどうか (スーパーユーザー以外が)。 |
| FEATURE_USER_LAST_ACCESSED | Boolean |
ユーザーが最後にアクセスした時間を記録するかどうか。 |
| FEATURE_USER_LOG_ACCESS | Boolean |
true に設定すると、ユーザーは namespace の監査ログにアクセスできます |
| FEATURE_USER_METADATA | Boolean |
ユーザーメタデータを収集してサポートするかどうか。 |
| FEATURE_USERNAME_CONFIRMATION | Boolean |
true に設定すると、OpenID Connect (OIDC) または LDAP などのデータベース以外の認証プロバイダーでログインする場合に、初期ユーザー名を確認および変更できます。 |
| FEATURE_USER_RENAME | Boolean |
true に設定すると、ユーザーは独自の namespace の名前を変更できます。 |
| FEATURE_INVITE_ONLY_USER_CREATION | Boolean |
作成するユーザーは別のユーザーから招待を受ける必要があります。 |
| FRESH_LOGIN_TIMEOUT | String |
新規ログイン時にユーザーがパスワードの再入力を要求されるまでの時間。 |
| USERFILES_LOCATION | String |
ユーザーがアップロードしたファイルを配置するストレージエンジンの ID。 |
| USERFILES_PATH | String |
ユーザーがアップロードしたファイルを配置するストレージの下のパス。 |
| USER_RECOVERY_TOKEN_LIFETIME | String |
ユーザーアカウントを復元するためのトークンが有効な期間。 |
| FEATURE_SUPERUSERS_FULL_ACCESS | Boolean | スーパーユーザーが所有していない名前空間、または明示的なアクセス許可を持っていない名前空間内の他のリポジトリーからコンテンツを読み取り、書き込み、削除する機能をスーパーユーザーに付与します。
デフォルト: |
| FEATURE_RESTRICTED_USERS | Boolean |
デフォルト: |
| RESTRICTED_USERS_WHITELIST | String |
|
| GLOBAL_READONLY_SUPER_USERS | String | 設定すると、公開リポジトリーかどうかに関係なく、このリストのユーザーにすべてのリポジトリーへの読み取りアクセスが許可されます。 |
3.29.1. ユーザー設定フィールドのリファレンス
次の参照を使用して、目的の設定フィールドで config.yaml ファイルを更新します。
3.29.1.1. FEATURE_SUPERUSERS_FULL_ACCESS 設定リファレンス
--- SUPER_USERS: - quayadmin FEATURE_SUPERUSERS_FULL_ACCESS: True ---
3.29.1.2. GLOBAL_READONLY_SUPER_USERS 設定リファレンス
---
GLOBAL_READONLY_SUPER_USERS:
- user1
---3.29.1.3. FEATURE_RESTRICTED_USERS 設定リファレンス
--- AUTHENTICATION_TYPE: Database --- --- FEATURE_RESTRICTED_USERS: true ---
3.29.1.4. RESTRICTED_USERS_WHITELIST 設定リファレンス
前提条件
-
FEATURE_RESTRICTED_USERSはconfig.yamlファイルでtrueに設定されています。
---
AUTHENTICATION_TYPE: Database
---
---
FEATURE_RESTRICTED_USERS: true
RESTRICTED_USERS_WHITELIST:
- user1
---
このフィールドが設定されていると、ホワイトリストに登録されたユーザーは、FEATURE_RESTRICTED_USERS が true に設定されていても、組織を作成したり、リポジトリーからコンテンツを読み書きしたりできます。user2、user3、user4 などの他のユーザーは、組織の作成、コンテンツの読み取りまたは書き込みが制限されています。
3.30. reCAPTCHA 設定フィールド
表3.34 reCAPTCHA 設定フィールド
| フィールド | タイプ | 説明 |
|---|---|---|
| FEATURE_RECAPTCHA | Boolean |
ユーザーログインおよびリカバリーに Recaptcha が必要かどうか |
| RECAPTCHA_SECRET_KEY | String | recaptcha が有効になっている場合は、Recaptcha サービスのシークレットキー |
| RECAPTCHA_SITE_KEY | String | recaptcha が有効になっている場合は、Recaptcha サービスのサイトキー |
3.31. ACI 設定フィールド
表3.35 ACI 設定フィールド
| フィールド | タイプ | 説明 |
|---|---|---|
| FEATURE_ACI_CONVERSION | Boolean |
ACI への変換を有効にするかどうか |
| GPG2_PRIVATE_KEY_FILENAME | String | ACI の復号化に使用される秘密鍵のファイル名 |
| GPG2_PRIVATE_KEY_NAME | String | ACI に署名するために使用されるプライベートキーの名前 |
| GPG2_PUBLIC_KEY_FILENAME | String | ACI の暗号化に使用する公開鍵のファイル名 |
3.32. JWT 設定フィールド
表3.36 JWT 設定フィールド
| フィールド | タイプ | 説明 |
|---|---|---|
| JWT_AUTH_ISSUER | String |
JWT ユーザーのエンドポイント |
| JWT_GETUSER_ENDPOINT | String |
JWT ユーザーのエンドポイント |
| JWT_QUERY_ENDPOINT | String |
JWT クエリーのエンドポイント |
| JWT_VERIFY_ENDPOINT | String |
JWT 検証のエンドポイント |
3.33. アプリケーショントークン設定フィールド
表3.37 アプリケーショントークン設定フィールド
| フィールド | タイプ | 説明 |
|---|---|---|
| FEATURE_APP_SPECIFIC_TOKENS | Boolean |
有効な場合、ユーザーは Docker CLI で使用するトークンを作成できます。 |
| APP_SPECIFIC_TOKEN_EXPIRATION | String |
外部アプリトークンの有効期限。 |
| EXPIRED_APP_SPECIFIC_TOKEN_GC | String |
期限切れとなった外部アプリケーションがガべージコレクションが行われるまでに留まる期間。 |
3.34. その他の設定フィールド
表3.38 その他の設定フィールド
| フィールド | タイプ | 説明 |
|---|---|---|
| ALLOW_PULLS_WITHOUT_STRICT_LOGGING | String |
true に指定すると、プルの監査ログのエントリーに書き込みできない場合でも、プルは成功します。これは、データベースが読み取り専用の状態にフォールバックし、その間プルを続行する必要がある場合に便利です。 |
| AVATAR_KIND | String |
表示する avatar のタイプ。インライン (local) または Gravatar (gravatar)。 |
| BROWSER_API_CALLS_XHR_ONLY | Boolean |
有効になっていると、ブラウザーから XHR による呼び出しとしてマークが付けられた API のみが許可されます。 |
| DEFAULT_NAMESPACE_MAXIMUM_BUILD_COUNT | Number |
namespace でキューに入れることができるデフォルトの最大ビルド数です。 |
| ENABLE_HEALTH_DEBUG_SECRET | String | 指定していると、スーパーユーザーとして認証されていない場合に詳細なデバッグ情報を表示するために正常性エンドポイントに指定できるシークレット。 |
| EXTERNAL_TLS_TERMINATION | Boolean |
TLS がサポートされていても、Quay の前の層で終了する場合は |
| FRESH_LOGIN_TIMEOUT | String |
新規ログイン時にユーザーがパスワードの再入力を要求されるまでの時間。 |
| HEALTH_CHECKER | String |
設定済みのヘルスチェック。 |
| PROMETHEUS_NAMESPACE | String |
公開されているすべての Prometheus メトリクスに適用される接頭辞。 |
| PUBLIC_NAMESPACES | Array of string | namespace がパブリック namespace 一覧に定義されている場合に、それはユーザーが namespace のメンバーであるかどうかに関係なく、すべての ユーザーのリポジトリー一覧ページに表示されます。一般的には、企業のお客様がよく知られた名前空間のセットを設定する際に使用されます。 |
| REGISTRY_STATE | String |
レジストリーの状態 |
| SEARCH_MAX_RESULT_PAGE_COUNT | Number |
ユーザーが検索で表示できる最大ページ数。 |
| SEARCH_RESULTS_PER_PAGE | Number |
検索ページでページごとに返される結果数。 |
| V2_PAGINATION_SIZE | Number |
V2 レジストリー API において、1 ページあたりに返される結果の数。 |
| WEBHOOK_HOSTNAME_BLACKLIST | Array of string | 検証時に、ローカルホスト以外に Webhook から禁止するホスト名のセット。 |
| CREATE_PRIVATE_REPO_ON_PUSH | Boolean |
プッシュで作成された新規リポジトリーがプライベート表示に設定されているかどうか。 |
| CREATE_NAMESPACE_ON_PUSH | Boolean |
既存の組織への新規プッシュで namespace を作成するかどうか。 |
| NON_RATE_LIMITED_NAMESPACES | Array of string |
|
| Boolean | 設定すると、ユーザーはベータ UI 環境を試すことができます。
デフォルト: | |
| FEATURE_REQUIRE_TEAM_INVITE | Boolean |
ユーザーをチームに追加するときに招待を必要とするかどうか。 |
| FEATURE_REQUIRE_ENCRYPTED_BASIC_AUTH | Boolean |
(暗号化されたトークンではなく) 暗号化されていないパスワードを Basic 認証に使用できるかどうか |
| FEATURE_RATE_LIMITS | Boolean |
API およびレジストリーエンドポイントでレート制限を有効にするかどうか。FEATURE_RATE_LIMITS を |
| FEATURE_FIPS | Boolean |
true に設定すると、Red Hat Quay は FIPS 準拠のハッシュ関数を使用して実行されます。 |
| FEATURE_AGGREGATED_LOG_COUNT_RETRIEVAL | Boolean |
集計されたログ数の取得を許可するかどうか。 |
| FEATURE_ANONYMOUS_ACCESS | Boolean |
匿名ユーザーにパブリックリポジトリーの参照とプルを許可するかどうか。 |
| FEATURE_DIRECT_LOGIN | Boolean |
ユーザーが UI に直接ログインできるかどうか |
| FEATURE_LIBRARY_SUPPORT | Boolean |
Docker からプルおよびプッシュするときに名前空間のないリポジトリーを許可するかどうか。 |
| FEATURE_PARTIAL_USER_AUTOCOMPLETE | Boolean |
true に設定すると、オートコンプリートは部分的なユーザー名に適用されます。 |
| FEATURE_PERMANENT_SESSIONS | Boolean |
セッションが永続的かどうか。 |
| FEATURE_PUBLIC_CATALOG | Boolean |
true に設定すると、 |
3.35. レガシー設定フィールド
次のフィールドは非推奨または廃止されました。
表3.39 レガシー設定フィールド
| フィールド | タイプ | 説明 |
|---|---|---|
| FEATURE_BLACKLISTED_EMAILS | Boolean | true に設定すると、メールドメインがブラックリストに指定されている場合に新しいユーザーアカウントが作成されません。 |
| BLACKLISTED_EMAIL_DOMAINS | Array of string |
FEATURE_BLACKLISTED_EMAILS が true に設定されている場合に使用されるメールアドレスドメインの一覧。 |
| BLACKLIST_V2_SPEC | String |
Red Hat Quay が V2 は サポート対象外 であることを示す応答を返す Docker CLI バージョン。 |
| DOCUMENTATION_ROOT | String | ドキュメントリンクのルート URL。 |
| SECURITY_SCANNER_V4_NAMESPACE_WHITELIST | String | セキュリティースキャナーを有効にする namespace。 |
| FEATURE_RESTRICTED_V1_PUSH | Boolean |
true に設定すると、V1_PUSH_WHITELIST にリストされている名前空間のみが V1 プッシュをサポートします。 |
| V1_PUSH_WHITELIST | Array of string | FEATURE_RESTRICTED_V1_PUSH が true に設定されている場合に V1 push をサポートする namespace 名の配列。 |
| FEATURE_HELM_OCI_SUPPORT | Boolean |
Helm アーティファクトのサポートを有効にします。 |
3.36. ユーザーインターフェイス v2 設定フィールド
表3.40 ユーザーインターフェイス v2 設定フィールド
| フィールド | タイプ | 説明 |
|---|---|---|
| FEATURE_UI_V2 | Boolean | 設定すると、ユーザーはベータ UI 環境を試すことができます。
デフォルト: |
3.36.1. v2 ユーザーインターフェイス設定
FEATURE_UI_V2 を有効にすると、現在のバージョンのユーザーインターフェイスと新しいバージョンのユーザーインターフェイスを切り替えることができます。
- この UI は現在ベータ版であり、変更される可能性があります。現在の状態では、ユーザーは組織、リポジトリー、およびイメージタグのみを作成、表示、および削除できます。
- 古い UI で Red Hat Quay を実行している場合にセッションがタイムアウトになると、ユーザーはポップアップウィンドウでパスワードを再度入力する必要がありました。新しい UI では、ユーザーはメインページに戻り、ユーザー名とパスワードの認証情報を入力する必要があります。これは既知の問題であり、新しい UI の今後のバージョンで修正される予定です。
- 従来の UI と新しい UI の間で、イメージマニフェストのサイズが報告される方法に違いがあります。従来の UI では、イメージマニフェストはメビバイト単位で報告されていました。新しい UI では、Red Hat Quay はメガバイト (MB) の標準定義を使用して、イメージマニフェストのサイズを報告します。
手順
デプロイメントの
config.yamlファイルで、FEATURE_UI_V2パラメーターを追加し、trueに設定します。次に例を示します。--- FEATURE_TEAM_SYNCING: false FEATURE_UI_V2: true FEATURE_USER_CREATION: true ---
- Red Hat Quay デプロイメントにログインします。
Red Hat Quay デプロイメントのナビゲーションペインに、現在の UI と 新しい UI を切り替えるオプションが表示されます。切り替えボタンをクリックして新しい UI に設定し、次に Use Beta Environment をクリックします。次に例を示します。
3.37. IPv6 設定フィールド
表3.41 IPv6 設定フィールド
| フィールド | タイプ | 説明 |
|---|---|---|
| FEATURE_LISTEN_IP_VERSION | String | IPv4、IPv6、またはデュアルスタックプロトコルファミリーを有効にします。この設定フィールドは正しく設定する必要があります。そうしないと、Red Hat Quay は起動に失敗します。
デフォルト:
追加設定: |
3.38. ブランディング設定フィールド
表3.42 ブランディング設定フィールド
| フィールド | タイプ | 説明 |
|---|---|---|
| BRANDING | Object | Red Hat Quay UI のロゴおよび URL のカスタムブランディング |
|
.logo | String |
メインのロゴイメージ URL。
ヘッダーロゴのデフォルトは 205x30 PX です。Web UI の Red Hat Quay サインイン画面のフォームロゴは、デフォルトで 356.5x39.7 PX です。 |
| .footer_img | String |
UI フッターのロゴ。デフォルトは 144x34 ピクセルです。 |
| .footer_url | String |
フッターイメージへのリンク。 |
3.38.1. Red Hat Quay ブランディングの設定例
ブランディング config.yaml の例
BRANDING:
logo: https://www.mend.io/wp-content/media/2020/03/5-tips_small.jpg
footer_img: https://www.mend.io/wp-content/media/2020/03/5-tips_small.jpg
footer_url: https://opensourceworld.org/
3.39. セッションタイムアウト設定フィールド
次の設定フィールドは、同じ名前の Flask API 設定フィールドに依存しています。
表3.43 セッションログアウト設定フィールド
| フィールド | タイプ | 説明 |
|---|---|---|
| PERMANENT_SESSION_LIFETIME | Integer |
永続セッションの有効期限を設定するために使用される
デフォルト: |
3.39.1. 設定セッションタイムアウトの設定例
次の YAML は、セッションの有効期間を有効にする場合の推奨設定です。
セッションの有効期間を変更することは推奨できません。管理者は、セッションタイムアウトを設定するときに、割り当てられた時間を認識する必要があります。時間が早すぎると、ワークフローが中断する可能性があります。
セッションタイムアウトの YAML 設定
PERMANENT_SESSION_LIFETIME: 3000
第4章 環境変数
Red Hat Quay は、動的に設定する多数の環境変数をサポートします。
4.1. Geo レプリケーション
ストレージバックエンド以外のすべてのリージョンで同じ設定を使用する必要があります。これは、QUAY_DISTRIBUTED_STORAGE_PREFERENCE 環境変数を使用して明示的に設定できます。
表4.1 Geo レプリケーションの設定
| 変数 | タイプ | 説明 |
|---|---|---|
| QUAY_DISTRIBUTED_STORAGE_PREFERENCE | String | 使用する優先されるストレージ (DISTRIBUTED_STORAGE_CONFIG の ID 別) |
4.2. データベース接続プール
Red Hat Quay は、すべてが同じコンテナー内で実行する多くの異なるプロセスで設定されています。これらのプロセスの多くは、データベースと連動しています。
有効にすると、データベースと対話する各プロセスには、コネクションプールが含まれます。これらのプロセスごとのコネクションプールは、最大 20 個の接続を維持するように設定されています。高負荷時には、Red Hat Quay コンテナー内のすべてのプロセスの接続プールを満たすことが可能です。特定のデプロイメントおよび負荷では、Red Hat Quay が設定されたデータベースの最大接続数を超えないようにするための分析が必要になる場合があります。
時間が経つと、接続プールはアイドル接続を解放します。すべての接続をすぐに解除するには、Red Hat Quay の再起動が必要です。
データベース接続プーリングは、環境変数 DB_CONNECTION_POOLING を true または false に設定することで切り替えることができます。
表4.2 データベース接続プールの設定
| 変数 | タイプ | 説明 |
|---|---|---|
| DB_CONNECTION_POOLING | Boolean | データベース接続プールの有効化または無効化 |
データベース接続プーリングが有効な場合は、接続プールの最大サイズを変更することができます。これは、以下の config.yaml オプションを使用して実行できます。
config.yaml
... DB_CONNECTION_ARGS: max_connections: 10 ...
4.3. HTTP 接続回数
環境変数を使用して、HTTP の同時接続数を指定することができます。これらは、全体として、または特定のコンポーネントに対して指定できます。それぞれのデフォルトは、プロセスあたり 50 の 並列接続です。
表4.3 HTTP 接続数の設定
| 変数 | タイプ | 説明 |
|---|---|---|
| WORKER_CONNECTION_COUNT | Number |
同時 HTTP 接続 |
| WORKER_CONNECTION_COUNT_REGISTRY | Number |
レジストリーの同時 HTTP 接続 |
| WORKER_CONNECTION_COUNT_WEB | Number |
Web UI の同時 HTTP 接続 |
| WORKER_CONNECTION_COUNT_SECSCAN | Number |
Clair の同時 HTTP 接続 |
4.4. ワーカーカウント変数
表4.4 ワーカーカウント変数
| 変数 | タイプ | 説明 |
|---|---|---|
| WORKER_COUNT | Number | プロセス数の汎用上書き |
| WORKER_COUNT_REGISTRY | Number |
|
| WORKER_COUNT_WEB | Number |
コンテナー内の UI/Web リクエストを処理するプロセス数を指定します |
| WORKER_COUNT_SECSCAN | Number |
コンテナー内のセキュリティースキャン (Clair など) の統合を処理するプロセス数を指定します。 |
4.5. デバッグ変数
次のデバッグ変数は Red Hat Quay で利用できます。
表4.5 デバッグ設定変数
| 変数 | タイプ | 説明 |
|---|---|---|
| DEBUGLOG | Boolean | デバッグログを有効または無効にするかどうか。 |
| USERS_DEBUG |
整数 |
パスワードを含むクリアテキストで LDAP 操作をデバッグするために使用されます。 重要
|
第5章 Red Hat Quay の Clair
Clair v4 (Clair) は、静的コード分析を活用してイメージコンテンツを解析し、コンテンツに影響を与える脆弱性を報告するオープンソースアプリケーションです。Clair は Red Hat Quay にパッケージ化されており、スタンドアロンと Operator デプロイメントの両方で使用できます。エンタープライズ環境に合わせてコンポーネントを個別にスケーリングできる、非常にスケーラブルな設定で実行できます。
5.1. Clair 設定の概要
Clair は、構造化された YAML ファイルによって設定されます。各 Clair ノードは、CLI フラグまたは環境変数を使用して、実行するモードと設定ファイルへのパスを指定する必要があります。以下に例を示します。
$ clair -conf ./path/to/config.yaml -mode indexer
または
$ clair -conf ./path/to/config.yaml -mode matcher
前述のコマンドはそれぞれ、同じ設定ファイルを使用して 2 つの Clair ノードを開始します。1 つはインデックス作成機能を実行し、もう 1 つはマッチング機能を実行します。
Go 標準ライブラリーが尊重する環境変数は、必要に応じて指定できます。次に例を示します。
-
HTTP_PROXY -
HTTPS_PROXY -
SSL_CERT_DIR
Clair を combo モードで実行している場合は、設定でインデクサー、マッチャー、通知設定ブロックを指定する必要があります。
5.1.1. Clair 設定リファレンス
次の YAML は、Clair 設定の例を示しています。
http_listen_addr: ""
introspection_addr: ""
log_level: ""
tls: {}
indexer:
connstring: ""
scanlock_retry: 0
layer_scan_concurrency: 0
migrations: false
scanner: {}
airgap: false
matcher:
connstring: ""
indexer_addr: ""
migrations: false
period: ""
disable_updaters: false
update_retention: 2
matchers:
names: nil
config: nil
updaters:
sets: nil
config: nil
notifier:
connstring: ""
migrations: false
indexer_addr: ""
matcher_addr: ""
poll_interval: ""
delivery_interval: ""
disable_summary: false
webhook: null
amqp: null
stomp: null
auth:
psk: nil
trace:
name: ""
probability: null
jaeger:
agent:
endpoint: ""
collector:
endpoint: ""
username: null
password: null
service_name: ""
tags: nil
buffer_max: 0
metrics:
name: ""
prometheus:
endpoint: null
dogstatsd:
url: ""上記の YAML ファイルには、万全を期すためにすべてのキーがリストされています。この設定ファイルをそのまま使用すると、一部のオプションがデフォルトで正常に設定されない場合があります。
5.1.2. Clair の一般的なフィールド
次のセクションでは、Clair デプロイメントで使用できる一般的な設定フィールドを説明します。
| フィールド | Typhttp_listen_ae | 説明 |
|---|---|---|
| http_listen_addr | String | HTTP API が公開される場所を設定します。
デフォルト: |
| introspection_addr | String | Clair のメトリックと正常性エンドポイントが公開される場所を設定します。 |
| log_level | String | ログレベルを設定します。文字列 debug-color、debug、info、warn、error、fatal、panic のいずれかが必要です。 |
| tls | String | TLS/SSL および HTTP/2 の HTTP API を提供するための設定を含むマップ。 |
| .cert | String | 使用する TLS 証明書。フルチェーン証明書である必要があります。 |
5.1.3. Clair インデクサー設定フィールド
Clair では、次のインデクサー設定フィールドを使用できます。
| フィールド | タイプ | 説明 |
|---|---|---|
| indexer | Object | Clair インデクサーノード設定を提供します。 |
| .airgap | Boolean | インデクサーとフェッチャーのインターネットへの HTTP アクセスを無効にします。プライベート IPv4 および IPv6 アドレスが許可されます。データベース接続は影響を受けません。 |
| .connstring | String | Postgres 接続文字列。URL または libpq 接続文字列として形式を受け入れます。 |
| .index_report_request_concurrency | Integer |
レートは、インデックスレポート作成リクエストの数を制限します。これを
同時実行数を超えた場合、API はステータスコード |
| .scanlock_retry | Integer | 秒を表す正の整数。並行インデクサーは、マニフェストスキャンをロックして、上書きを回避します。この値は、待機中のインデクサーがロックをポーリングする頻度をチューニングします。 |
| .layer_scan_concurrency | Integer | レイヤーの同時スキャン数を制限する正の整数。インデクサーは、マニフェストのレイヤーを同時にマッチングします。この値は、インデクサーが並行してスキャンするレイヤーの数をチューニングします。 |
| .migrations | Boolean | インデクサーノードがデータベースへの移行を処理するかどうか。 |
| .scanner | String | インデクサー設定。 Scanner を使用すると、設定オプションをレイヤースキャナーに渡すことができます。スキャナーは、そのように設計されていると、構築時にこの設定を渡します。 |
| .scanner.dist | String | 特定のスキャナーの名前と値として任意の YAML を持つマップ。 |
| .scanner.package | String | 特定のスキャナーの名前と値として任意の YAML を持つマップ。 |
| .scanner.repo | String | 特定のスキャナーの名前と値として任意の YAML を持つマップ。 |
5.1.4. Clair マッチャー設定フィールド
Clair では、次のマッチャー設定フィールドを使用できます。
matchers 設定フィールドとは異なります。
| フィールド | タイプ | 説明 |
|---|---|---|
| matcher | Object | Clair マッチャーノード設定を提供します。 |
| .cache_age | String | レスポンスをキャッシュするように、ユーザーに通知する期間を制御します。 |
| .connstring | String | Postgres 接続文字列。URL または libpq 接続文字列として形式を受け入れます。 |
| .max_conn_pool | Integer | データベース接続プールのサイズを制限します。 Clair では、カスタムの接続プールサイズを使用できます。この数は、同時に許可されるアクティブなデータベース接続の数を直接設定します。 このパラメーターは、将来のバージョンでは無視されます。ユーザーは、接続文字列を使用して、これを設定する必要があります。 |
| .indexer_addr | String |
マッチャーはインデクサーに接続して
デフォルトは |
| .migrations | Boolean | マッチャーノードがデータベースへの移行を処理するかどうか。 |
| .period | String | 新しいセキュリティーアドバイザリーの更新頻度を決定します。
デフォルトは |
| .disable_updaters | Boolean | バックグラウンド更新を実行するかどうか。 |
| .update_retention | Integer | ガベージコレクションサイクル間で保持する更新操作の数を設定します。これは、データベースサイズの制約に基づいて安全な MAX 値に設定する必要があります。
デフォルトは
|
5.1.5. Clair マッチャー設定フィールド
Clair では、次のマッチャー設定フィールドを使用できます。
matcher 設定フィールドとは異なります。
| フィールド | タイプ | 説明 |
|---|---|---|
| matchers | 文字列の配列。 |
in-tree |
| .names | String |
有効なマッチャーについてマッチャーファクトリーに通知する文字列値のリスト。値が |
| .config | String | 特定のマッチャーに設定を提供します。 マッチャーファクトリーコンストラクターに提供されるサブオブジェクトを含むマッチャーの名前をキーとするマップ。以下に例を示します。 config:
python:
ignore_vulns:
- CVE-XYZ
- CVE-ABC
|
5.1.6. Clair アップデーター設定フィールド
Clair では、次のアップデーター設定フィールドを使用できます。
| フィールド | タイプ | 説明 |
|---|---|---|
| updaters | Object | マッチャーの更新マネージャーの設定を提供します。 |
| .sets | String | どのアップデーターを実行するかを更新マネージャーに通知する値のリスト。
値が 空白のままにすると、更新プログラムは実行されません。 |
| .config | String | 特定のアップデーターセットに設定を提供します。 アップデーターセットのコンストラクターに提供されるサブオブジェクトを含むアップデーターセットの名前をキーとするマップ。以下に例を示します。 config:
ubuntu:
security_tracker_url: http://security.url
ignore_distributions:
- cosmic
|
5.1.7. Clair ノーティファイアー設定フィールド
Clair では、次のノーティファイアー設定フィールドを使用できます。
| フィールド | タイプ | 説明 |
|---|---|---|
| notifier | Object | Clair ノーティファイアーノード設定を提供します。 |
| .connstring | String | Postgres 接続文字列。形式を URL または libpq 接続文字列として受け入れます。 |
| .migrations | Boolean | ノーティファイアーノードがデータベースへの移行を処理するかどうか。 |
| .indexer_addr | String | ノーティファイアーはインデクサーに連絡して、脆弱性の影響を受けるマニフェストを作成または取得します。このインデクサーの場所は必須です。 |
| .matcher_addr | String | ノーティファイアーはマッチャーに連絡して、更新操作をリストし、差分を取得します。このマッチャーの場所は必須です。 |
| .poll_interval | String | ノーティファイアーがマッチャーに更新操作をクエリーする頻度。 |
| .delivery_interval | String | ノーティファイアーが、作成された通知または以前に失敗した通知の配信を試行する頻度。 |
| .disable_summary | Boolean | 通知をマニフェストごとに 1 つに要約するかどうかを制御します。 |
| .webhook | Object | Webhook 配信のノーティファイアーを設定します。 |
| .webhook.target | String | Webhook が配信される URL。 |
| .webhook.callback | String | 通知を取得できるコールバック URL。この URL に通知 ID が追加されます。 これは通常、Clair ノーティファイアーがホスティングされている場所です。 |
| .webhook.headers | String | ヘッダー名を値のリストに関連付けるマップ。 |
| .amqp | Object | AMQP 配信のノーティファイアーを設定します。 注記 Clair は、独自に AMQP コンポーネントを宣言しません。交換またはキューを使用しようとする試みはすべて受動的であり、失敗します。ブローカー管理者は、事前に交換とキューをセットアップする必要があります。 |
| .amqp.direct | Boolean |
|
| .amqp.rollup | Integer |
|
| .amqp.exchange | Object | 接続先の AMQP 交換。 |
| .amqp.exchange.name | String | 接続先の交換の名前。 |
| .amqp.exchange.type | String | 交換のタイプ。通常は、direct、fanout、topic、headers のいずれかです。 |
| .amqp.exchange.durability | Boolean | 設定されたキューが永続的かどうか。 |
| .amqp.exchange.auto_delete | Boolean |
設定されたキューが |
| .amqp.routing_key | String | 各通知が送信されるルーティングキーの名前。 |
| .amqp.callback | String |
|
| .amqp.uris | String | 接続先の 1 つ以上の AMQP ブローカーのリスト (優先順位順)。 |
| .amqp.tls | Object | AMQP ブローカーへの TLS/SSL 接続を設定します。 |
| .amqp.tls.root_ca | String | ルート CA を読み取ることができるファイルシステムパス。 |
| .amqp.tls.cert | String | TLS/SSL 証明書を読み取ることができるファイルシステムパス。 注記
Go |
| .amqp.tls.key | String | TLS/SSL 秘密鍵を読み取ることができるファイルシステムパス。 |
| .stomp | Object | STOMP 配信のノーティファイアーを設定します。 |
| .stomp.direct | Boolean |
|
| .stomp.rollup | Integer |
|
| .stomp.callback | String |
|
| .stomp.destination | String | 通知を配信する STOMP の宛先。 |
| .stomp.uris | String | 接続先の 1 つ以上の STOMP ブローカーのリスト (優先順位順)。 |
| .stomp.tls | Object | STOMP ブローカーへの TLS/SSL 接続を設定しました。 |
| .stomp.tls.root_ca | String | ルート CA を読み取ることができるファイルシステムパス。 注記
Go |
| .stomp.tls.cert | String | TLS/SSL 証明書を読み取ることができるファイルシステムパス。 |
| .stomp.tls.key | String | TLS/SSL 秘密鍵を読み取ることができるファイルシステムパス。 |
| .stomp.user | String | STOMP ブローカーのログインの詳細を設定します。 |
| .stomp.user.login | String | 接続に使用する STOMP ログイン。 |
| .stomp.user.passcode | String | 接続に使用する STOMP パスコード。 |
5.1.8. Clair 承認設定フィールド
Clair では、次の承認設定フィールドを使用できます。
| フィールド | タイプ | 説明 |
|---|---|---|
| auth | Object |
Clair の外部およびサービス内 JWT ベースの認証を定義します。複数の |
| .psk | String | 事前共有キー認証を定義します。 |
| .psk.key | String | JWT の署名と検証を行うすべての当事者間で配布される、base64 でエンコードされた共有キー。 |
| .psk.iss | String | 確認する JWT 発行者のリスト。空のリストは、JWT クレームで任意の発行者を受け入れます。 |
5.1.9. Clair トレース設定フィールド
Clair では、次のトレース設定フィールドを使用できます。
| フィールド | タイプ | 説明 |
|---|---|---|
| trace | Object | OpenTelemetry に基づいて分散トレース設定を定義します。 |
| .name | String | トレースが属するアプリケーションの名前。 |
| .probability | Integer | トレースが発生する確率。 |
| .jaeger | Object | Jaeger トレースの値を定義します。 |
| .jaeger.agent | Object | Jaeger エージェントへの配信を設定するための値を定義します。 |
| .jaeger.agent.endpoint | String |
トレースを送信できる |
| .jaeger.collector | Object | Jaeger コレクターへの配信を設定するための値を定義します。 |
| .jaeger.collector.endpoint | String |
トレースを送信できる |
| .jaeger.collector.username | String | Jaeger ユーザー名。 |
| .jaeger.collector.password | String | Jaeger パスワード。 |
| .jaeger.service_name | String | Jaeger に登録されているサービス名。 |
| .jaeger.tags | String | 追加のメタデータを提供するキーと値のペア。 |
| .jaeger.buffer_max | Integer | 保管および分析のために Jaeger バックエンドに送信される前にメモリーにバッファーできるスパンの最大数。 |
5.1.10. Clair メトリック設定フィールド
Clair では、次のメトリック設定フィールドを使用できます。
| フィールド | タイプ | 説明 |
|---|---|---|
| metrics | Object | OpenTelemetry に基づいて分散トレース設定を定義します。 |
| .name | String | 使用中のメトリックの名前。 |
| .prometheus | String | Prometheus メトリックエクスポーターの設定。 |
| .prometheus.endpoint | String | メトリックが提供されるパスを定義します。 |