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

Red Hat Quay の設定

download PDF
Red Hat Quay 3.8

設定オプションを使用した Red Hat Quay のカスタマイズ

Red Hat OpenShift Documentation Team

概要

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 をデプロイしたら、デプロイから完全な設定を取得して保存する必要があります。完全な設定には、システムの再始動またはアップグレード時に必要になる可能性がある追加の生成値が含まれています。

1.1. Quay 3.8 の設定更新

以下の設定フィールドが Red Hat Quay 3.8 で導入されました。

表1.1 Red Hat Quay 3.8 設定フィールド
フィールドタイプ説明

FEATURE_UI_V2

Boolean

設定すると、ユーザーはベータ UI 環境を試すことができます。

デフォルト: False

FEATURE_LISTEN_IP_VERSION

String

IPv4、IPv6、またはデュアルスタックプロトコルファミリーを有効にします。この設定フィールドは正しく設定する必要があります。そうしないと、Red Hat Quay は起動に失敗します。

デフォルト: IPv4

追加設定: IPv6、デュアルスタック

LDAP_SUPERUSER_FILTER

String

LDAP_USER_FILTER 設定フィールドのサブセット。設定すると、Red Hat Quay 管理者は、Red Hat Quay が認証プロバイダーとして LDAP を使用する場合に、Lightweight Directory Access Protocol (LDAP) ユーザーをスーパーユーザーとして設定することができます。

このフィールドを使用すると、管理者は Red Hat Quay 設定ファイルを更新してデプロイメントを再起動することなく、スーパーユーザーを追加または削除できます。

LDAP_RESTRICTED_USER_FILTER

String

LDAP_USER_FILTER 設定フィールドのサブセット。設定すると、Red Hat Quay 管理者は、Red Hat Quay が認証プロバイダーとして LDAP を使用する場合に、Lightweight Directory Access Protocol (LDAP) ユーザーを制限付きユーザーとして設定することができます。

FEATURE_SUPERUSERS_FULL_ACCESS

ブール値

スーパーユーザーが所有していない名前空間、または明示的なアクセス許可を持っていない名前空間内の他のリポジトリーからコンテンツを読み取り、書き込み、削除する機能をスーパーユーザーに付与します。

デフォルト: False

GLOBAL_READONLY_SUPER_USERS

String

設定すると、公開リポジトリーかどうかに関係なく、このリストのユーザーにすべてのリポジトリーへの読み取りアクセスが許可されます。

FEATURE_RESTRICTED_USERS

ブール値

RESTRICTED_USERS_WHITELIST を設定すると、制限されたユーザーは自分の名前空間で組織やコンテンツを作成できなくなります。通常のアクセス許可は、組織のメンバーシップに適用されます。たとえば、制限付きのユーザーは、所属するチームをもとに、組織内の通常のパーミッションは割り当てられたままです。

デフォルト: False

RESTRICTED_USERS_WHITELIST

String

FEATURE_RESTRICTED_USERS: true を設定すると、特定のユーザーが FEATURE_RESTRICTED_USERS 設定から除外されます。

1.2. Quay 3.7 の設定更新

1.2.1. Red Hat Quay 3.7.7 の新規設定フィールド

フィールドタイプ説明

REPO_MIRROR_ROLLBACK

Boolean

true に設定されている場合、リポジトリーはミラー試行の失敗後にロールバックします。

デフォルト: false

1.2.2. 新規設定フィールド

以下の設定フィールドが Red Hat Quay 3.7 で導入されました。

パラメーター説明

FEATURE_QUOTA_MANAGEMENT

クォータ管理がサポートされるようになりました。この機能により、ユーザーは、設定されたストレージクォータ制限を確立することにより、ストレージ消費を報告し、レジストリーの増加を抑えることができます。クォータ管理の詳細については、Red Hat Quay クォータの管理と実施 を参照してください。

DEFAULT_SYSTEM_REJECT_QUOTA_BYTES

すべての組織およびユーザーに適用するクォータサイズクォータ管理の詳細については、Red Hat Quay クォータの管理と実施 を参照してください。

FEATURE_PROXY_CACHE

Red Hat Quay を使用してリモート組織をプロキシーすることがサポートされるようになりました。この機能により、Red Hat Quay は、アップストリームレジストリーからのプルレート制限を回避するためのプロキシーキャッシュとして機能します。クォータ管理の詳細については、アップストリームレジストリーのプロキシーキャッシュとしての Red Hat Quay を参照してください。

1.3. Red Hat Quay 3.6 の設定の更新

1.3.1. 新規設定フィールド

以下の設定フィールドが Red Hat Quay 3.6 で導入されました。

パラメーター説明

FEATURE_EXTENDED_REPOSITORY_NAMES

ネストされたリポジトリーと拡張リポジトリー名のサポートが追加されました。この変更により、特定の OpenShift Container Platform ユースケースに必要なリポジトリー名で / を使用できるようになります。詳細は、ネストされたリポジトリーの設定 を参照してください。

FEATURE_USER_INITIALIZE

true に設定すると、API /api/v1/user/initialize によって最初の User アカウントを作成できます。詳細は、自動化のための Red Hat Quay の事前設定 を参照してください。

ALLOWED_OCI_ARTIFACT_TYPES

Helm、cosign、および ztsd 圧縮スキームアーティファクトはデフォルトで Red Hat Quay 3.6 に組み込まれています。デフォルトでサポートされていないその他の Open Container Initiative (OCI) メディアタイプについては、Quay の config.yaml の ALLOWED_OCI_ARTIFACT_TYPES 設定に追加できます。詳細については、他の OCI メディアタイプを Quay に追加する を参照してください。

CREATE_PRIVATE_REPO_ON_PUSH

レジストリーユーザーは、セキュリティーのニーズに応じて、config.yaml の CREATE_PRIVATE_REPO_ON_PUSH を True または False に設定できるようになりました。

CREATE_NAMESPACE_ON_PUSH

存在しない組織にプッシュした場合に、組織を自動的に作成するように設定できるようになりました。

1.3.2. 非推奨の設定フィールド

以下の設定フィールドは、Red Hat Quay 3.6 で廃止されました。

パラメーター説明

FEATURE_HELM_OCI_SUPPORT

このオプションは廃止され、Red Hat Quay の将来のバージョンでは削除される予定です。Red Hat Quay 3.6 では、Helm アーティファクトがデフォルトでサポートされ、FEATURE_GENERAL_OCI_SUPPORT プロパティーに含まれています。ユーザーは、サポートを有効にするために config.yaml ファイルを更新する必要がなくなりました。

1.4. 設定ファイルの編集

Red Hat Quay のスタンドアロンインスタンスをデプロイするには、最小限の設定情報を提供する必要があります。最小設定の要件は、「Red Hat Quay の最小設定」に記載されています。

必須フィールドに入力したら、設定を検証できます。問題がある場合は、強調表示されます。

注記

コンフィグレーション API を使用して設定を検証することもできますが、これには Quay コンテナーを設定モードで起動する必要があります。詳細については、「設定ツールの使用」を参照してください。

変更を有効にするには、レジストリーを再起動する必要があります。

1.5. スタンドアロンデプロイメントにおける設定ファイルの場所

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.8.15

1.6. 最小設定

Red Hat Quay のスタンドアロンデプロイメントには、以下の設定オプションが必要です。

  • サーバーのホスト名
  • HTTP または HTTPS
  • 認証タイプ (データベースや LDAP (Lightweight Directory Access Protocol) など)
  • データ暗号化用の秘密鍵
  • イメージのストレージ
  • メタデータ用のデータベース
  • ビルドログおよびユーザーイベント用の Redis
  • タグの有効期限オプション

1.6.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 フィールドは、設定が検証されたことを示します。レジストリーを起動する前に、設定エディターツールを使用して設定を検証する必要があります。

1.6.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.8.15

1.6.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.8.15

第2章 設定フィールド

このセクションでは、Red Hat Quay のデプロイ時に必須および任意の設定フィールドの両方について説明します。

2.1. 必須の設定フィールド

Red Hat Quay の設定で必須のフィールドは、以下のセクションで説明されています。

2.2. 自動化オプション

以下のセクションでは、Red Hat Quay デプロイメントで利用可能な自動化オプションについて説明します。

2.3. 任意の設定フィールド

Red Hat Quay の任意のフィールドについては、以下のセクションで説明します。

2.4. 一般的な必須フィールド

以下の表は、Red Hat Quay デプロイメントの必須設定フィールドについて説明しています。

表2.1 一般的な必須フィールド
フィールドタイプ説明

AUTHENTICATION_TYPE
(必須)

String

認証情報の認証に使用する認証エンジン｡

値:
Database、LDAP、JWT、Keystone、OIDC のいずれか。

デフォルト: Database

PREFERRED_URL_SCHEME
(必須)

String

Red Hat Quay へのアクセスに使用する URL スキーム。

値:
http, https のいずれか。

デフォルト: http

SERVER_HOSTNAME
(必須)

String

スキームなしで Red Hat Quay にアクセスできる URL｡

例:
quay-server.example.com

DATABASE_SECRET_KEY
(必須)

String

データベース内で機密フィールドを暗号化するのに使用されるキー。この値は、一旦設定したら変更しないでください。変更すると、リポジトリーのミラーユーザー名やパスワード設定など、すべての信頼できるフィールドが無効になります。

SECRET_KEY
(必須)

String

データベース内および実行時に機密フィールドを暗号化するために使用されるキー。この値は一度設定すると決して変更しないでください。そうしないと、暗号化されたパスワード資格情報などのすべての依存フィールドが無効になります。

SETUP_COMPLETE
(必須)

Boolean

これは、以前のバージョンのソフトウェアからそのまま残っているアーティファクトで、現時点では値を true に指定する 必要があります。

2.5. データベースの設定

このセクションでは、Red Hat Quay デプロイメントで利用可能なデータベース設定フィールドを説明します。

2.5.1. データベース URI

Red Hat Quay では、必要な DB_URI フィールドを使用してデータベースへの接続を設定します。

以下の表は DB_URI 設定フィールドを説明します。

表2.2 データベース URI
フィールドタイプ説明

DB_URI
(必須)

String

認証情報を含む、データベースにアクセスするための URI。

DB_URI フィールドの例:

postgresql://quayuser:quaypass@quay-server.example.com:5432/quay

2.5.2. データベース接続引数

オプションの接続引数は、DB_CONNECTION_ARGS パラメーターで設定されます。DB_CONNECTION_ARGS で定義されたキーと値のペアの一部は汎用的なものも、データベース固有のものもあります。

以下の表は、データベース接続引数を説明します。

表2.3 データベース接続引数
フィールドタイプ説明

DB_CONNECTION_ARGS

Object

タイムアウトや SSL などのデータベースの任意の接続引数。

.autorollback

Boolean

スレッドローカル接続を使用するかどうか。
常に true にする必要があります。

.threadlocals

Boolean

自動ロールバック接続を使用するかどうか。
常に true にする必要があります。

2.5.2.1. PostgreSQL SSL 接続引数

SSL では、設定はデプロイするデータベースによって異なります。以下の例は、PostgreSQL SSL 設定を示します。 

DB_CONNECTION_ARGS:
  sslmode: verify-ca
  sslrootcert: /path/to/cacert

sslmode オプションは、セキュアな SSL/IP 接続がサーバーにネゴシエートされるかどうか、その優先度を決定します。モードは 6 つあります。

表2.4 SSL オプション
Mode説明

disable

設定は SSL 以外の接続のみを試みます。

allow

設定は、SSL 以外の接続を最初に試行します。障害が発生したときに、SSL 接続を試行します。

prefer
(デフォルト)

設定は最初に SSL 接続を試みます。障害が発生したときに、SSL 以外の接続を試みます。

require

設定は SSL 接続のみを試みます。ルート CA ファイルが存在する場合は、verify-ca が指定されているのと同じ方法で証明書を検証します。

verify-ca

設定は SSL 接続のみを試行し、サーバー証明書が信頼できる認証局 (CA) によって発行されたことを確認します。

verify-full

SSL 接続のみを試行し、信頼された CA によりサーバー証明書が発行され、要求されたサーバーのホスト名が証明書と一致することを確認します。

PostgreSQL の有効な引数の詳細は、Database Connection Control Functions を参照してください。

2.5.2.2. MySQL SSL 接続引数

以下の例は、MySQL SSL 設定の例を示します。 

DB_CONNECTION_ARGS:
  ssl:
    ca: /path/to/cacert

MySQL の有効な接続引数に関する情報は、Connecting to the Server Using URI-Like Strings or Key-Value Pairs を参照してください。

2.6. イメージストレージ

このセクションでは、Red Hat Quay で利用可能なイメージストレージ機能と設定フィールドについて説明します。

2.6.1. イメージストレージ機能

以下の表は、Red Hat Quay のイメージストレージ機能について説明しています。

表2.5 ストレージ設定機能
フィールドタイプ説明

FEATURE_REPO_MIRROR

Boolean

true に設定されている場合、リポジトリーのミラーリングを有効にします。

デフォルト: false

FEATURE_PROXY_STORAGE

Boolean

NGINX を使用してストレージ内のすべての直接ダウンロード URL をプロキシーするかどうか。

デフォルト: false

FEATURE_STORAGE_REPLICATION

Boolean

ストレージエンジン間で自動的にレプリケートするかどうか

のデフォルト: false

2.6.2. イメージストレージ設定フィールド

以下の表は、Red Hat Quay のイメージストレージ設定フィールドについて説明しています。

表2.6 ストレージ設定フィールド
フィールドタイプ説明

DISTRIBUTED_STORAGE_CONFIG
(必須)

Object

Red Hat Quay で使用するストレージエンジンの設定。各キーは、ストレージエンジンの一意の ID を表します。この値は、ストレージエンジンパラメーターを記述するオブジェクトのタプル (キー、値) で設定されます。

デフォルト: []

DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS
(必須)

文字列の配列

イメージをデフォルトで他のすべてのストレージエンジンに対して完全にレプリケートする必要のあるストレージエンジンの一覧 (DISTRIBUTED_STORAGE_CONFIG の ID 別)。

DISTRIBUTED_STORAGE_PREFERENCE
(必須)

文字列の配列

使用する優先ストレージエンジン（DISTRIBUTED_STORAGE_CONFIGの ID 別）。優先エンジンとは、プルする必要がないかを先にチェックしてから、イメージをプッシュするという意味です。

デフォルト: false

MAXIMUM_LAYER_SIZE

String

イメージレイヤーの最大許容サイズ。

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

例: 100G

デフォルト: 20G

2.6.3. ローカルストレージ

以下の YAML は、ローカルストレージを使用した設定のサンプルを示しています。 

DISTRIBUTED_STORAGE_CONFIG:
  default:
    - LocalStorage
    - storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
    - default

2.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/registry

2.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:
    - default

2.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:
    - s3Storage

2.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:
    - googleCloudStorage

2.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 エラーが発生します。

2.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:
    - swiftStorage

2.7. Redis 設定フィールド

本セクションでは、Redis デプロイメントで利用可能な設定フィールドについて説明します。

2.7.1. ビルドログ

Redis デプロイメントには、以下のビルドログ設定フィールドを利用できます。

表2.7 ビルドログの設定
フィールドタイプ説明

BUILDLOGS_REDIS
(必須)

Object

ビルドログキャッシュ用の Redis 接続の詳細

.host
(必須)

String

Redis にアクセスできるホスト名。
例:
quay-server.example.com

.port
(必須)

数値

Redis にアクセスできるポート。
例:
6379

.password

String

Redis インスタンスに接続するためのパスワード。
例:
strongpassword

.ssl
(オプション)

Boolean

Redis と Quay 間の TLS 通信を有効にするかどうか。デフォルトは false です。

2.7.2. ユーザーイベント

Redis デプロイメントには、以下のユーザーイベントフィールドを使用できます。

表2.8 ユーザーイベント設定
フィールドタイプ説明

USER_EVENTS_REDIS
(必須)

Object

ユーザーイベント処理の Redis 接続の詳細

.host
(必須)

String

Redis にアクセスできるホスト名。
例:
quay-server.example.com

.port
(必須)

数値

Redis にアクセスできるポート。
例:
6379

.password

String

Redis インスタンスに接続するためのパスワード。
例:
strongpassword

.ssl

Boolean

Redis と Quay 間の TLS 通信を有効にするかどうか。デフォルトは false です。

.ssl_keyfile
(オプション)

String

使用するクライアント証明書を格納する鍵データベースファイルの名前。
例:
ssl_keyfile:/path/to/server/privatekey.pem

.ssl_certfile
(オプション)

String

SSL 証明書のファイルパスを指定するために使用されます。
例:
ssl_certfile:/path/to/server/certificate.pem

.ssl_cert_reqs
(オプション)

String

SSL/TLS ハンドシェーク中に実行される証明書検証のレベルを指定するために使用されます。
例:
ssl_cert_reqs: CERT_REQUIRED

.ssl_ca_certs
(オプション)

String

信頼された認証局 (CA) 証明書のリストを含むファイルへのパスを指定するために使用されます。
例:
ssl_ca_certs:/path/to/ca_certs.pem

.ssl_ca_data
(オプション)

String

信頼できる CA 証明書を含む文字列を PEM 形式で指定するために使用されます。
例:
ssl_ca_data: <certificate>

.ssl_check_hostname
(オプション)

Boolean

サーバーへの SSL/TLS 接続をセットアップするときに使用されます。サーバーの SSL/TLS 証明書のホスト名が、接続先のサーバーのホスト名と一致することをクライアントが確認する必要があるかどうかを指定します。
例:
ssl_check_hostname: true

2.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 になります。

2.8. ModelCache 設定オプション

以下のオプションは、ModelCache を設定するために Red Hat Quay で利用できます。

2.8.1. memcache 設定オプション

memcache は、デフォルトの ModelCache 設定オプションです。memcache を使用すると、追加の設定は必要ありません。

2.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 >

2.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 >

2.9. タグの有効期限の設定フィールド

以下のタグの有効期限設定フィールドは Red Hat Quay で利用できます。

表2.9 タグの有効期限の設定フィールド
フィールドタイプ説明

FEATURE_GARBAGE_COLLECTION

Boolean

リポジトリーのガベージコレクションを有効にするかどうか。

デフォルト: True

TAG_EXPIRATION_OPTIONS
(必須)

文字列の配列

有効にすると、名前空間内のタグの有効期限についてユーザーが選択できるオプション。

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

DEFAULT_TAG_EXPIRATION
(必須)

String

タイムマシンのデフォルトの設定可能なタグの有効期限。

パターン:
^[0-9]+(w|m|d|h|s)$
デフォルト 2w

FEATURE_CHANGE_TAG_EXPIRATION

Boolean

ユーザーおよび組織が namespace のタグの有効期限を変更できるかどうか｡

デフォルト: True

2.9.1. タグの有効期限の設定例

以下の YAML は、タグの有効期限の設定例を示しています。 

DEFAULT_TAG_EXPIRATION: 2w
TAG_EXPIRATION_OPTIONS:
    - 0s
    - 1d
    - 1w
    - 2w
    - 4w

2.10. 自動化のための Red Hat Quay の事前設定

Red Hat Quay には、自動化をサポートする複数の設定オプションがあります。これらのオプションはデプロイメントの前に設定でき、ユーザーインターフェイスとの対話の必要性を最小限に抑えることができます。

2.10.1. API による最初のユーザー作成の許可

/api/v1/user/initialize API を使用して最初のユーザーを作成するには、FEATURE_USER_INITIALIZE パラメーターを true に設定します。既存の組織の OAuth アプリケーションによって生成された OAuth トークンを必要とする他のすべてのレジストリー API 呼び出しとは異なり、API エンドポイントには認証は必要ありません。

Red Hat Quay のデプロイ後に、API を使用して他のユーザーがすでに作成されていない限り、quayadmin などのユーザーを作成できます。詳細は、API を使用して最初のユーザーを作成する を参照してください。

2.10.2. API 一般アクセスの有効化

Red Hat Quay レジストリー API の一般的なアクセスを許可するには、設定オプション BROWSER_API_CALLS_XHR_ONLY を false に設定します。

2.10.3. スーパーユーザーの追加

Red Hat Quay のデプロイ後に、ユーザーを作成できます。最初のユーザーには、完全な権限を持つ管理者権限を付与することを推奨します。すべてのパーミッションは、SUPER_USER 設定オブジェクトを使用して事前に設定できます。以下に例を示します。 

...
SERVER_HOSTNAME: quay-server.example.com
SETUP_COMPLETE: true
SUPER_USERS:
  - quayadmin
...

2.10.4. ユーザー作成の制限

スーパーユーザーを設定したら、新しいユーザーをスーパーユーザーグループに作成する機能を制限できます。ユーザー作成を制限するには、FEATURE_USER_CREATION を false に設定します。以下に例を示します。 

...
FEATURE_USER_INITIALIZE: true
BROWSER_API_CALLS_XHR_ONLY: false
SUPER_USERS:
- quayadmin
FEATURE_USER_CREATION: false
...

2.10.5. 新機能の有効化

新しい 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:
      -
...

2.10.6. 新機能の有効化

新規の 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
...

2.10.7. 自動化の推奨設定

自動化には、以下の config.yaml パラメーターが推奨されます。 

...
FEATURE_USER_INITIALIZE: true
BROWSER_API_CALLS_XHR_ONLY: false
SUPER_USERS:
- quayadmin
FEATURE_USER_CREATION: false
...

2.10.8. 初期設定を使用した Red Hat Quay Operator のデプロイ

以下の手順に従って、初期設定を使用して OpenShift Container Platform に Red Hat Quay をデプロイします。

前提条件

  • oc CLI がインストールされている。

手順

  1. 設定ファイルを使用してシークレットを作成します。 

    $ oc create secret generic -n quay-enterprise --from-file config.yaml=./config.yaml init-config-bundle-secret

  2. quayregistry.yaml ファイルを作成します。以下のように、管理対象外のコンポーネントを特定し、作成されたシークレットを参照します。 

    apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  name: example-registry
  namespace: quay-enterprise
spec:
  configBundleSecret: init-config-bundle-secret

  3. Red Hat Quay レジストリーをデプロイします。 

    $ oc create -n quay-enterprise -f quayregistry.yaml

次のステップ

  • API を使用した最初のユーザーの作成

2.10.9. API を使用した Red Hat Quay のデプロイ

このセクションでは、API を使用して Red Hat Quay をデプロイする方法を説明します。

前提条件

  • 設定オプション FEATURE_USER_INITIALIZE は true に設定する。
  • データベースにユーザーが存在していない。

Red Hat Quay デプロイメントを事前に設定する方法は、自動化のための Red Hat Quay の設定 セクションを参照してください。

2.10.9.1. API を使用した最初のユーザーの作成

以下の手順に従って、Red Hat Quay 組織で最初のユーザーを作成します。

注記

この手順では、"access_token": true を指定して OAuth トークンを要求します。

  1. root ユーザーとして、次のコマンドを入力して python39 をインストールします。 

    $ sudo yum install python39

  2. Python 3.9 の pip パッケージマネージャーをアップグレードします。 

    $ python3.9 -m pip install --upgrade pip

  3. pip パッケージマネージャーを使用して bcrypt パッケージをインストールします。 

    $ pip install bcrypt

  4. 次のコマンドを入力して、Python 3.9 の bcrypt パッケージを使用して、安全なハッシュ化されたパスワードを生成します。 

    $ python3.9 -c 'import bcrypt; print(bcrypt.hashpw(b"subquay12345", bcrypt.gensalt(12)).decode("utf-8"))'

  5. Red Hat Quay 設定ファイルを開き、以下の設定フィールドを更新します。 

    FEATURE_USER_INITIALIZE: true
SUPER_USERS:
     -  quayadmin

  6. 次のコマンドを入力して、Red Hat Quay サービスを停止します。 

    $ sudo podman stop quay

  7. 次のコマンドを入力して、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}

  8. 次の 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."}

  9. 以下のコマンドを入力して、Red Hat Quay デプロイメントにログインします。 

    $ sudo podman login -u quayadmin -p quaypass12345 http://quay-server.example.com --tls-verify=false

    出力例

    Login Succeeded!

2.10.9.2. OAuth トークンの使用

API の呼び出し後に、返される OAuth コードを指定して残りの Red Hat Quay API を呼び出すことができます。

前提条件

  • /api/v1/user/initialize API を呼び出し、ユーザー名、パスワード、およびメールアドレスに渡している。

手順

  • 以下のコマンドを入力して、現在のユーザーの一覧を取得します。 

    $ 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 ユーザーの詳細が返されます。

2.10.9.3. API を使用した組織の作成

以下の手順では、API を使用して Red Hat Quay 組織を作成する方法を説明します。

前提条件

  • /api/v1/user/initialize API を呼び出し、ユーザー名、パスワード、およびメールアドレスに渡している。
  • 返された OAuth コードを指定して、残りの Red Hat Quay API を呼び出している。

手順

  1. 組織を作成するには、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"

  2. 以下のコマンドを入力して、作成した組織の詳細を取得できます。 

    $ 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
}

2.11. 基本設定フィールド

表2.10 基本設定
フィールドタイプ説明

REGISTRY_TITLE

String

指定されている場合、レジストリーの長いタイトル。Red Hat Quay デプロイメントのフロントエンド (組織のサインインページなど) に表示されます。35 文字を超えてはなりません。
デフォルト:
Red Hat Quay

REGISTRY_TITLE_SHORT

String

指定されている場合は、省略形式のレジストリーのタイトル。タイトルは、組織のさまざまなページに表示されます。たとえば、組織の Tutorial ページのチュートリアルのタイトルとして表示されます。
デフォルト:
Red Hat Quay

CONTACT_INFO

文字列の配列

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

[0]

String

電子メールを送信するためのリンクを追加します。

パターン:
^mailto:(.)+$
例:
mailto:support@quay.io

[1]

String

IRC チャットルームにアクセスするためのリンクを追加します。

パターン:
^irc://(.)+$
例:
irc://chat.freenode.net:6665/quay

[2]

String

電話番号を呼び出すためのリンクを追加します。+
パターン:
^tel:(.)+$
例:
tel:+1-888-930-3475

[3]

String

定義された URL へのリンクを追加します。

パターン:
^http(s)?://(.)+$
Example:
https://twitter.com/quayio

2.12. SSL 設定フィールド

表2.11 SSL 設定
フィールドタイプ説明

PREFERRED_URL_SCHEME

String

http または https のいずれか。クライアントから Quay への通信パスに TLS 暗号化がない場合に限り、ユーザーは PREFERRED_URL_SCHEME を http に設定することに注意してください。

+ TLS を終了するロードバランサー、リバースプロキシー (Nginx など) を使用する場合、またはカスタム SSL 証明書で Quay を直接使用する場合、ユーザーは PREFERRED_URL_SCHEME`を`https に設定する必要があります。ほとんどの場合、PREFERRED_URL_SCHEME は https である必要があります。
デフォルト: http

SERVER_HOSTNAME
(必須)

String

スキームなしで Red Hat Quay にアクセスできる URL

例:
quay-server.example.com

SSL_CIPHERS

文字列の配列

指定されている場合、有効化および無効化する SSL 暗号の nginx 定義の一覧

例:
[CAMELLIA, !3DES]

SSL_PROTOCOLS

文字列の配列

指定されている場合、nginx は、一覧で定義される SSL プロトコルの一覧を有効にするように設定されます。リストから SSL プロトコルを削除すると、Red Hat Quay の起動時にそのプロトコルが無効になります。

例:
['TLSv1','TLSv1.1','TLSv1.2', `TLSv1.3]`

SESSION_COOKIE_SECURE

Boolean

セッションクッキーに secure プロパティーを設定するべきであるかどうか。

デフォルト:
False

推奨:
SSL を使用するインストールの場合はすべて、True に n 設定。

2.12.1. SSL の設定

  1. 証明書ファイルとプライマリーキーファイルを設定ディレクトリーにコピーして、それぞれ ssl.cert と ssl.key という名前が付けられていることを確認します。 

    $ cp ~/ssl.cert $QUAY/config
$ cp ~/ssl.key $QUAY/config
$ cd $QUAY/config

  2. config.yaml ファイルを編集し、Quay で TLS を処理できるように指定します。

    config.yaml

    ...
SERVER_HOSTNAME: quay-server.example.com
...
PREFERRED_URL_SCHEME: https
...

  3. Quay コンテナーを停止し、レジストリーを再起動します。

2.13. Red Hat Quay コンテナーへの TLS 証明書の追加

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

2.13.1. TLS 証明書を Red Hat Quay に追加

  1. コンテナーに追加される証明書を表示します。 

    $ cat storage.crt
-----BEGIN CERTIFICATE-----
MIIDTTCCAjWgAwIBAgIJAMVr9ngjJhzbMA0GCSqGSIb3DQEBCwUAMD0xCzAJBgNV
[...]
-----END CERTIFICATE-----

  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

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

    $ sudo podman ps
CONTAINER ID        IMAGE                                COMMAND                  CREATED             STATUS              PORTS
5a3e82c4a75f        <registry>/<repo>/quay:v3.8.15 "/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

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

    $ sudo podman restart 5a3e82c4a75f

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

    $ sudo podman exec -it 5a3e82c4a75f cat /etc/ssl/certs/storage.pem
-----BEGIN CERTIFICATE-----
MIIDTTCCAjWgAwIBAgIJAMVr9ngjJhzbMA0GCSqGSIb3DQEBCwUAMD0xCzAJBgNV

2.14. LDAP 設定フィールド

表2.12 LDAP の設定
フィールドタイプ説明

AUTHENTICATION_TYPE
(必須)

String

LDAP に設定する必要があります。

FEATURE_TEAM_SYNCING

ブール値

認証エンジン (LDAP または Keystone) のバッキンググループからチームメンバーシップを同期するかどうか。

デフォルト: true

FEATURE_NONSUPERUSER_TEAM_SYNCING_SETUP

ブール値

有効にすると、スーパーユーザー以外のユーザーは LDAP を使用してチームの同期を設定できます

デフォルト値: false

LDAP_ADMIN_DN

String

LDAP 認証の管理 DN。

LDAP_ADMIN_PASSWD

String

LDAP 認証の管理パスワード。

LDAP_ALLOW_INSECURE_FALLBACK

Boolean

LDAP 認証で SSL の非セキュアなフォールバックを許可するかどうか。

LDAP_BASE_DN

文字列の配列

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

文字列の配列

LDAP 認証のユーザー RDN。

TEAM_RESYNC_STALE_TIME

String

チームの同期が有効になっている場合、必要に応じてメンバーシップを確認して再同期する頻度

パターン:
^[0-9]+(w|m|d|h|s)$
例:
2h
デフォルト:
30m

LDAP_SUPERUSER_FILTER

String

LDAP_USER_FILTER 設定フィールドのサブセット。設定すると、Red Hat Quay 管理者は、Red Hat Quay が認証プロバイダーとして LDAP を使用する場合に、Lightweight Directory Access Protocol (LDAP) ユーザーをスーパーユーザーとして設定することができます。

このフィールドを使用すると、管理者は Red Hat Quay 設定ファイルを更新してデプロイメントを再起動することなく、スーパーユーザーを追加または削除できます。

このフィールドでは、AUTHENTICATION_TYPE が LDAP に設定されている必要があります。

LDAP_RESTRICTED_USER_FILTER

String

LDAP_USER_FILTER 設定フィールドのサブセット。設定すると、Red Hat Quay 管理者は、Red Hat Quay が認証プロバイダーとして LDAP を使用する場合に、Lightweight Directory Access Protocol (LDAP) ユーザーを制限付きユーザーとして設定することができます。

このフィールドでは、AUTHENTICATION_TYPE が LDAP に設定されている必要があります。

2.14.1. LDAP 設定フィールドのリファレンス

次の参照を使用して、目的の設定フィールドで config.yaml ファイルを更新します。

2.14.1.1. 基本 LDAP ユーザー設定
---
AUTHENTICATION_TYPE: LDAP
---
LDAP_ADMIN_DN: uid=testuser,ou=Users,o=orgid,dc=jumpexamplecloud,dc=com
LDAP_ADMIN_PASSWD: samplepassword
LDAP_ALLOW_INSECURE_FALLBACK: false
LDAP_BASE_DN:
    - o=orgid
    - dc=example
    - dc=com
LDAP_EMAIL_ATTR: mail
LDAP_UID_ATTR: uid
LDAP_URI: ldap://ldap.example.com:389
LDAP_USER_RDN:
    - ou=Users
2.14.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
---
2.14.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=com

2.15. 設定フィールドのミラーリング

表2.13 ミラーリング設定
フィールドタイプ説明

FEATURE_REPO_MIRROR

Boolean

リポジトリーミラーリングを有効化または無効化します

デフォルト: false

REPO_MIRROR_INTERVAL

数値

次にリポジトリーミラー候補をチェックするまでの秒数。
デフォルト: 30

REPO_MIRROR_SERVER_HOSTNAME

String

SERVER_HOSTNAME は、ミラーリングの宛先に置き換えます。

デフォルト: None

例:
openshift-quay-service

REPO_MIRROR_TLS_VERIFY

Boolean

HTTPS を必要とし、ミラー時に Quay レジストリーの証明書を検証します。

デフォルト: false

REPO_MIRROR_ROLLBACK

Boolean

true に設定されている場合、リポジトリーはミラー試行の失敗後にロールバックします。

デフォルト: false

2.16. セキュリティースキャナー設定フィールド

表2.14 セキュリティースキャナーの設定
フィールドタイプ説明

FEATURE_SECURITY_SCANNER

Boolean

セキュリティースキャナー

デフォルト: false

FEATURE_SECURITY_NOTIFICATIONS

Boolean

セキュリティースキャナーが有効になっている場合、セキュリティー通知を有効にするか、オフにします

デフォルト値: false

SECURITY_SCANNER_V4_REINDEX_THRESHOLD

String

このパラメーターは、最終のインデックス作成から状態が変更されたか、以前に失敗したマニフェストのインデックスをもう一度作成するまで待機する最小時間を判断するのに使用します。データは manifestsecuritystatus テーブルの last_indexed datetime から計算されます。インデックス作成実行時に必ず、失敗したマニフェストのインデックスを再度作成しないように、このパラメーターを使用します。再インデックスのデフォルト時間は 300 秒です。

SECURITY_SCANNER_V4_ENDPOINT

String

V4 セキュリティースキャナーのエンドポイント

パターン:
^http(s)?://(.)+$

例:
http://192.168.99.101:6060

SECURITY_SCANNER_V4_PSK

String

Clair 用に生成された共有キー (PSK)

SECURITY_SCANNER_ENDPOINT

String

V2 セキュリティースキャナーのエンドポイント

パターン:
^http(s)?://(.)+$

例:
http://192.168.99.100:6060

SECURITY_SCANNER_INDEXING_INTERVAL

数値

このパラメーターは、セキュリティースキャナーのインデックス作成の間隔 (秒単位) を決定するために使用されます。インデックスがトリガーされると、Red Hat Quay は、Clair でインデックス化する必要のあるマニフェストに対してそのデータベースをクエリーします。これには、インデックス化されていないマニフェストや、以前にインデックスに失敗したマニフェストが含まれます。

デフォルト: 30

以下は、インデックス変更の特別なケースです。

Clair v4 がマニフェストをインデックス化する場合は、結果として、決定論的なものである必要があります。たとえば、同じマニフェストが同じインデックスレポートを生成する必要があります。これは、異なるスキャナーを使用するとレポートで返される特定のマニフェストに関連して異なる情報を生成するため、スキャナーが変更されるまで True となります。そのため、Clair v4 はインデックスエンジン (/indexer/api/v1/index_state) の状態表現を公開し、スキャナー設定が変更されたかどうかを判別します。

Red Hat Quay は、Quay のデータベースの解析時にこれをインデックスレポートに保存し、このインデックス状態を活用します。以前にスキャンされてからこの状態が変更された場合、Quay は定期的なインデックスプロセス時にマニフェストの再作成を試行します。

デフォルトでは、このパラメーターは 30 秒に設定されています。インデックス作成のプロセスをより頻繁に実行する場合は、時間を短縮します。たとえば、新規タグをプッシュしてから、30 秒待たずに、UI でセキュリティースキャンの結果を表示する場合などです。また、ユーザーは要求パターンを Clair に制御し、Quay データベースで実行されるデータベース操作のパターンをより詳細に制御する必要がある場合にパラメーターを変更することもできます。

2.17. OCI および Helm 設定フィールド

Helm のサポートが FEATURE_GENERAL_OCI_SUPPORT プロパティーでサポートされるようになりました。機能を明示的に有効にする必要がある場合 (機能が無効にされている場合や、デフォルトで有効にされていないバージョンからアップグレードした場合など) は、OCI アーティファクトの使用を有効にするために 2 つのプロパティーを Quay 設定に追加する必要があります。 

FEATURE_GENERAL_OCI_SUPPORT: true
FEATURE_HELM_OCI_SUPPORT: true
表2.15 OCI および Helm 設定フィールド
フィールドタイプ説明

FEATURE_GENERAL_OCI_SUPPORT

ブール値

OCI アーティファクトのサポートを有効にします

デフォルト: True

FEATURE_HELM_OCI_SUPPORT

ブール値

Helm アーティファクトのサポートを有効にします

デフォルト: True

重要

Red Hat Quay 3.6 の時点で、FEATURE_HELM_OCI_SUPPORT は非推奨になり、Red Hat Quay の今後のバージョンで削除される予定です。Red Hat Quay 3.6 では、Helm アーティファクトがデフォルトでサポートされ、FEATURE_GENERAL_OCI_SUPPORT プロパティーに含まれています。ユーザーは、サポートを有効にするために config.yaml ファイルを更新する必要がなくなりました。

2.18. アクションログ設定フィールド

2.18.1. アクションログストレージ設定

表2.16 アクションログストレージ設定
フィールドタイプ説明

FEATURE_LOG_EXPORT

ブール値

アクションログのエクスポートを許可するかどうか

デフォルト: True

LOGS_MODEL

String

セキュリティースキャナーを有効または無効にします。

値: database, transition_reads_both_writes_es, elasticsearch のいずれか。
デフォルト: database

LOGS_MODEL_CONFIG

オブジェクト

アクションログのログモデル設定

  • 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 [文字列]: 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

2.18.2. アクションログのローテーションおよびアーカイブ設定

表2.17 アクションログのローテーションおよびアーカイブ設定
フィールドタイプ説明

FEATURE_ACTION_LOG_ROTATION

ブール値

ログローテーションおよび archival を有効にすると、30 日以上経過したすべてのログをストレージに移動します。

デフォルト: false

ACTION_LOG_ARCHIVE_LOCATION

String

アクションログのアーカイブが有効な場合、アーカイブされたデータを配置するストレージエンジン

例: s3_us_east

ACTION_LOG_ARCHIVE_PATH

String

アクションログのアーカイブが有効な場合、アーカイブされたデータを配置するストレージのパス

例: archives/actionlogs

ACTION_LOG_ROTATION_THRESHOLD

String

ログをローテーションする間隔。

例: 30d

2.19. ビルドログ設定フィールド

表2.18 ビルドログ設定フィールド
フィールドタイプ説明

FEATURE_READER_BUILD_LOGS

Boolean

true に設定されている場合、書き込みアクセスや管理アクセスがある場合だけでなく、リポジトリーへの読み取りアクセスを持つユーザーがビルドログを読み取ることができます。

デフォルト: False

LOG_ARCHIVE_LOCATION

String

アーカイブされたビルドログを配置する、 DISTRIBUTED_STORAGE_CONFIG で定義されたストレージの場所

例: s3_us_east

LOG_ARCHIVE_PATH

String

アーカイブされたビルドログを JSON 形式で配置する、設定されたストレージエンジンの下のパス

例: archives/buildlogs

2.20. Dockerfile ビルドトリガーフィールド

表2.19 Dockerfile ビルドのサポート
フィールドタイプ説明

FEATURE_BUILD_SUPPORT

Boolean

Dockerfile ビルドをサポートするかどうか。

初期値: False

SUCCESSIVE_TRIGGER_FAILURE_DISABLE_THRESHOLD

数値

None ではない場合に、ビルドトリガーが自動的に無効にされる前に、連続で失敗できる回数。

デフォルト: 100

SUCCESSIVE_TRIGGER_INTERNAL_ERROR_DISABLE_THRESHOLD

数値

None ではない場合に、ビルドトリガーが自動的に無効にされる前に、連続で発生可能な内部エラーの回数。

デフォルト: 5

2.20.1. GitHub ビルドトリガー

表2.20 GitHub ビルドトリガー
フィールドタイプ説明

FEATURE_GITHUB_BUILD

Boolean

GitHub ビルドトリガーをサポートしているかどうか

デフォルト: False

 

 

 

GITHUB_TRIGGER_CONFIG

Object

ビルドトリガーに GitHub (Enterprise) を使用するための設定

   .GITHUB_ENDPOINT
(必須)

String

GitHub (Enterprise) のエンドポイント

例: https://github.com/

   .API_ENDPOINT

String

使用する GitHub (Enterprise) API のエンドポイント。github.com に対して上書きする必要があります。

例: https://api.github.com/

   .CLIENT_ID
(必須)

String

この Red Hat Quay インスタンスの登録されたクライアント ID。GITHUB_LOGIN_CONFIG と共有にすることはできません。

   .CLIENT_SECRET
(必須)

String

この Red Hat Quay インスタンスの登録されたクライアントシークレット。

2.20.2. Bitbucket ビルドトリガー

表2.21 Bitbucket ビルドトリガー
フィールドタイプ説明

FEATURE_BITBUCKET_BUILD

Boolean

Bitbucket ビルドトリガーをサポートしているかどうか

デフォルト: False

 

 

 

BITBUCKET_TRIGGER_CONFIG

Object

ビルドトリガーに BitBucket を使用するための設定

   .CONSUMER_KEY
(必須)

String

この Quay インスタンスの登録されたコンシューマーキー (クライアント ID)

   .CONSUMER_SECRET
(必須)

String

この Quay インスタンスの、登録されたコンシューマーシークレット (クライアントシークレット)

2.20.3. GitLab ビルドトリガー

表2.22 GitLab ビルドトリガー
フィールドタイプ説明

FEATURE_GITLAB_BUILD

Boolean

GitLab ビルドトリガーをサポートしているかどうか

デフォルト: False

 

 

 

GITLAB_TRIGGER_CONFIG

Object

ビルドトリガーに Gitlab を使用するための設定

   .GITLAB_ENDPOINT
(必須)

String

Gitlab (Enterprise) が実行されているエンドポイント

   .CLIENT_ID
(必須)

String

この Quay インスタンスの、登録されたクライアント ID

   .CLIENT_SECRET
(必須)

String

この Quay インスタンスの、登録されたクライアントシークレット

2.21. OAuth 設定フィールド

表2.23 OAuth フィールド
フィールドタイプ説明

DIRECT_OAUTH_CLIENTID_WHITELIST

文字列の配列

ユーザーの承認なしに直接 OAuth 承認を実行できる Red Hat Quay 管理 アプリケーションのクライアント ID の一覧。

2.21.1. GitHub OAuth 設定フィールド

表2.24 GitHub OAuth フィールド
フィールドタイプ説明

FEATURE_GITHUB_LOGIN

Boolean

GitHub ログインがサポートされるかどうか

**デフォルト: False

GITHUB_LOGIN_CONFIG

Object

外部ログインプロバイダーとして GitHub (Enterprise) を使用するための設定

   .ALLOWED_ORGANIZATIONS

文字列の配列

ORG_RESTRICT オプションを使用するためにホワイトリスト化された GitHub (Enterprise) 組織の名前

   .API_ENDPOINT

String

使用する GitHub (Enterprise) API のエンドポイント。github.com

例: https://api.github.com/

   .CLIENT_ID
(必須)

String

この Red Hat Quay インスタンスの登録されたクライアント ID。GITHUB_TRIGGER_CONFIG とは共有できません。GITHUB_TRIGGER_CONFIG.

例: 0e8dbe15c4c7630b6780

   .CLIENT_SECRET
(必須)

String

Red Hat Quay インスタンスの登録クライアントシークレット。

例: e4a58ddd3d7408b7aec109e85564a0d153d3e846

   .GITHUB_ENDPOINT
(必須)

String

GitHub (Enterprise) のエンドポイント。

例: https://github.com/

   .ORG_RESTRICT

Boolean

true の場合、このプロバイダーを使用してログインできるのは組織のホワイトリスト内のユーザーのみです。

2.21.2. Google OAuth 設定フィールド

表2.25 Google OAuth フィールド
フィールドタイプ説明

FEATURE_GOOGLE_LOGIN

Boolean

Google ログインがサポートされるかどうか。

**デフォルト: False

GOOGLE_LOGIN_CONFIG

Object

外部認証に Google を使用するための設定。

   .CLIENT_ID
(必須)

String

この Red Hat Quay インスタンスの登録されたクライアント ID。

例: 0e8dbe15c4c7630b6780

   .CLIENT_SECRET
(必須)

String

Red Hat Quay インスタンスの登録クライアントシークレット。

例: e4a58ddd3d7408b7aec109e85564a0d153d3e846

2.22. OIDC 設定フィールド

表2.26 OIDC フィールド

フィールド

タイプ

説明

<文字列>_LOGIN_CONFIG
(必須)

String

OIDC 設定を保持する親キー。通常は、OIDC プロバイダーの名前 (AZURE_LOGIN_CONFIG など) ですが、任意の文字列も受け入れられます。

.CLIENT_ID
(必須)

String

この Red Hat Quay インスタンスの登録されたクライアント ID。

例: 0e8dbe15c4c7630b6780

.CLIENT_SECRET
(必須)

String

Red Hat Quay インスタンスの登録クライアントシークレット。

例: e4a58ddd3d7408b7aec109e85564a0d153d3e846

.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 エンドポイントでのカスタムクエリーパラメーターのサポートを追加しました。エンドポイント authorization_endpoint、token_endpoint、および user_endpoint がサポートされています。

.OIDC_ISSUER

String

ユーザーが検証する発行者を定義できます。たとえば、JWT トークンは、トークンを発行したユーザーを定義する iss と呼ばれるパラメーターをコンテナー化します。デフォルトでは、これはすべての OIDC プロバイダーによって公開される .well-know/openid/configuration エンドポイントから読み込まれます。この検証に失敗すると、ログインはありません。

.OIDC_SERVER
(必須)

String

認証に使用される OIDC サーバーのアドレス。

例: https://sts.windows.net/6c878…​/

.PREFERRED_USERNAME_CLAIM_NAME

String

優先ユーザー名をトークンのパラメーターに設定します。

.SERVICE_ICON

String

ログイン画面のアイコンを変更します。

.SERVICE_NAME
(必須)

String

認証されているサービスの名前。

例: Azure AD

.VERIFIED_EMAIL_CLAIM_NAME

String

ユーザーの電子メールアドレスを確認するために使用されるクレームの名前。

2.22.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",

2.23. ネストされたリポジトリー設定フィールド

Red Hat Quay 3.6 では、ネストされたリポジトリーパス名のサポートが FEATURE_EXTENDED_REPOSITORY_NAMES プロパティーに追加されました。このオプションの設定は、デフォルトで config.yaml に追加されます。有効にすると、リポジトリー名で / を使用できます。 

FEATURE_EXTENDED_REPOSITORY_NAMES: true
表2.27 OCI およびネストされたリポジトリー設定フィールド
フィールドタイプ説明

FEATURE_EXTENDED_REPOSITORY_NAMES

Boolean

ネストされたリポジトリーのサポートを有効にする

デフォルト: True

2.24. その他の OCI メディアタイプの Quay への追加

Helm、cosign、および ztsd 圧縮スキームアーティファクトはデフォルトで Red Hat Quay 3.6 に組み込まれています。デフォルトでサポートされていない他の OCI メディアタイプでは、以下の形式を使用して Quay の config.yaml の ALLOWED_OCI_ARTIFACT_TYPES 設定に追加できます。 

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) サポートを追加できます。 

...
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 メディアタイプを追加する場合、ユーザーは必要に応じて cosign と Helm のサポートも手動で追加する必要があります。ztsd 圧縮スキームはデフォルトでサポートされているため、ユーザーはサポートを有効にするためにその OCI メディアタイプを config.yaml に追加する必要はありません。

2.25. メール設定フィールド

表2.28 メール設定フィールド
フィールドタイプ説明

FEATURE_MAILING

Boolean

メールが有効かどうか

デフォルト: False

MAIL_DEFAULT_SENDER

String

指定されている場合、Red Hat Quay がメールを送信する際の from として使用されるメールアドレス。何も指定されていない場合は、support@quay.io

にデフォルト設定されます。例: support@example.com

MAIL_PASSWORD

String

メールの送信時に使用する SMTP パスワード。

MAIL_PORT

数値

使用する SMTP ポート。指定されていない場合は、デフォルトの 587 になります。

MAIL_SERVER

String

メールの送信に使用する SMTP サーバー。FEATURE_MAILING が true に設定されている場合にのみ必要です。

例: smtp.example.com

MAIL_USERNAME

String

メールの送信時に使用する SMTP ユーザー名

MAIL_USE_TLS

Boolean

指定されている場合、電子メールの送信に TLS を使用するかどうか

デフォルト: True

2.26. ユーザー設定フィールド

表2.29 ユーザー設定フィールド
フィールドタイプ説明

FEATURE_SUPER_USERS

Boolean

スーパーユーザーがサポートされるかどうか

デフォルト: true

FEATURE_USER_CREATION

Boolean

ユーザーを作成するかどうか (スーパーユーザー以外)

デフォルト: true

FEATURE_USER_LAST_ACCESSED

Boolean

ユーザーが最後にアクセスした時間を記録するかどうか

デフォルト: true

FEATURE_USER_LOG_ACCESS

Boolean

true に設定すると、ユーザーは namespace の監査ログにアクセスできます

デフォルト: false

FEATURE_USER_METADATA

Boolean

ユーザーメタデータを収集してサポートするかどうか

デフォルト: false

FEATURE_USERNAME_CONFIRMATION

Boolean

true に設定すると、OpenID Connect (OIDC) または LDAP などのデータベース以外の認証プロバイダーでログインする場合に、初期ユーザー名を確認および変更できます。
デフォルト:true

FEATURE_USER_RENAME

Boolean

true に設定されている場合、ユーザーは独自の namespace の名前を変更できます。

デフォルト: false

FEATURE_INVITE_ONLY_USER_CREATION

Boolean

作成するユーザーは別のユーザーから招待を受ける必要があります。

デフォルト: false

FRESH_LOGIN_TIMEOUT

String

新規ログイン時にユーザーがパスワードの再入力を要求されるまでの時間

例: 5m

USERFILES_LOCATION

String

ユーザーがアップロードしたファイルを配置するストレージエンジンの ID。

例:s3_us_east

USERFILES_PATH

String

ユーザーがアップロードしたファイルを配置するストレージの下のパス。

例:userfiles

USER_RECOVERY_TOKEN_LIFETIME

String

ユーザーアカウントを復元するためのトークンが有効な期間

パターン:^[0-9]+(w|m|d|h|s)$
デフォルト: 30m

FEATURE_SUPERUSERS_FULL_ACCESS

Boolean

スーパーユーザーが所有していない名前空間、または明示的なアクセス許可を持っていない名前空間内の他のリポジトリーからコンテンツを読み取り、書き込み、削除する機能をスーパーユーザーに付与します。

デフォルト: False

FEATURE_RESTRICTED_USERS

Boolean

RESTRICTED_USERS_WHITELIST を設定すると、制限されたユーザーは自分の名前空間で組織やコンテンツを作成できなくなります。通常のアクセス許可は、組織のメンバーシップに適用されます。たとえば、制限付きのユーザーは、所属するチームをもとに、組織内の通常のパーミッションは割り当てられたままです。

デフォルト: False

RESTRICTED_USERS_WHITELIST

String

FEATURE_RESTRICTED_USERS: true を設定すると、特定のユーザーが FEATURE_RESTRICTED_USERS 設定から除外されます。

GLOBAL_READONLY_SUPER_USERS

String

設定すると、公開リポジトリーかどうかに関係なく、このリストのユーザーにすべてのリポジトリーへの読み取りアクセスが許可されます。

2.26.1. ユーザー設定フィールドのリファレンス

次の参照を使用して、目的の設定フィールドで config.yaml ファイルを更新します。

2.26.1.1. FEATURE_SUPERUSERS_FULL_ACCESS 設定リファレンス
---
SUPER_USERS:
- quayadmin
FEATURE_SUPERUSERS_FULL_ACCESS: True
---
2.26.1.2. GLOBAL_READONLY_SUPER_USERS 設定リファレンス
---
GLOBAL_READONLY_SUPER_USERS:
      - user1
---
2.26.1.3. FEATURE_RESTRICTED_USERS 設定リファレンス
---
AUTHENTICATION_TYPE: Database
---
---
FEATURE_RESTRICTED_USERS: true
---
2.26.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 などの他のユーザーは、組織の作成、コンテンツの読み取りまたは書き込みが制限されています。

2.27. reCAPTCHA 設定フィールド

表2.30 reCAPTCHA 設定フィールド
フィールドタイプ説明

FEATURE_RECAPTCHA

Boolean

ユーザーログインおよびリカバリーに Recaptcha が必要かどうか

デフォルト: False

RECAPTCHA_SECRET_KEY

String

recaptcha が有効にされている場合は、Recaptcha サービスのシークレットキー

RECAPTCHA_SITE_KEY

String

recaptcha が有効にされている場合は、Recaptcha サービスのサイトキー

2.28. ACI 設定フィールド

表2.31 ACI 設定フィールド
フィールドタイプ説明

FEATURE_ACI_CONVERSION

Boolean

ACI への変換を有効にするかどうか。

デフォルト: False

GPG2_PRIVATE_KEY_FILENAME

String

ACI の復号化に使用される秘密鍵のファイル名

GPG2_PRIVATE_KEY_NAME

String

ACI に署名するために使用されるプライベートキーの名前

GPG2_PUBLIC_KEY_FILENAME

String

ACI の暗号化に使用する公開鍵のファイル名

2.29. JWT 設定フィールド

表2.32 JWT 設定フィールド
フィールドタイプ説明

JWT_AUTH_ISSUER

String

JWT ユーザーのエンドポイント

パターン:^http(s)?://(.)+$
例:http://192.168.99.101:6060

JWT_GETUSER_ENDPOINT

String

JWT ユーザーのエンドポイント
パターン:^http(s)?://(.)+$
例:http://192.168.99.101:6060

JWT_QUERY_ENDPOINT

String

JWT クエリーのエンドポイント

パターン:^http(s)?://(.)+$
例:http://192.168.99.101:6060

JWT_VERIFY_ENDPOINT

String

JWT 検証のエンドポイント

パターン:^http(s)?://(.)+$
例:http://192.168.99.101:6060

2.30. アプリケーショントークン設定フィールド

表2.33 アプリケーショントークン設定フィールド
フィールドタイプ説明

FEATURE_APP_SPECIFIC_TOKENS

Boolean

有効な場合には、ユーザーは Docker CLI で使用するトークンを作成できます。

デフォルト: True

APP_SPECIFIC_TOKEN_EXPIRATION

String

外部アプリトークンの有効期限。

デフォルト なし
パターン: ^[0-9]+(w|m|d|h|s)$

EXPIRED_APP_SPECIFIC_TOKEN_GC

String

期限切れとなった外部アプリケーションがガべージコレクションが行われるまでに留まる期間。

デフォルト: 1d

2.31. その他の設定フィールド

表2.34 その他の設定フィールド
フィールドタイプ説明

ALLOW_PULLS_WITHOUT_STRICT_LOGGING

String

true に指定すると、プルの監査ログのエントリーに書き込みできない場合でも、プルは成功します。これは、データベースが読み取り専用の状態にフォールバックし、その間プルを続行する必要がある場合に便利です。

初期値: False

AVATAR_KIND

String

表示する avatar のタイプ。インライン (ローカル) または Gravatar (gravatar)。

値: local, gravatar

BROWSER_API_CALLS_XHR_ONLY

Boolean

有効にされている場合には、ブラウザーから XHR による呼び出しとしてマークが付けられた API のみが許可されます。

デフォルト: True

DEFAULT_NAMESPACE_MAXIMUM_BUILD_COUNT

数値

namespace でキューに入れることができるデフォルトの最大ビルド数です。

デフォルト: None

ENABLE_HEALTH_DEBUG_SECRET

String

指定されている場合は、スーパーユーザーとして認証されていない場合に詳細なデバッグ情報を表示するために正常性エンドポイントに指定できるシークレット

EXTERNAL_TLS_TERMINATION

Boolean

TLS がサポートされているが、Quay の前の層で終了する場合は true に設定します。Quay が独自の SSL 証明書を使用して実行されており、TLS トラフィックを直接受信している場合は、false に設定します。

FRESH_LOGIN_TIMEOUT

String

新規ログイン時にユーザーがパスワードの再入力を要求されるまでの時間

例: 5m

HEALTH_CHECKER

String

設定済みのヘルスチェック

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

PROMETHEUS_NAMESPACE

String

公開されているすべての Prometheus メトリクスに適用される接頭辞

デフォルト:quay

PUBLIC_NAMESPACES

文字列の配列

namespace がパブリック namespace 一覧に定義されている場合に、それはユーザーが namespace のメンバーであるかどうかに関係なく、すべての ユーザーのリポジトリー一覧ページに表示されます。一般的には、企業のお客様がよく知られた名前空間のセットを設定する際に使用されます。

REGISTRY_STATE

String

レジストリーの状態

値: normal または read-only

SEARCH_MAX_RESULT_PAGE_COUNT

数値

ユーザーが検索で表示できる最大ページ数。

デフォルト: 10

SEARCH_RESULTS_PER_PAGE

数値

検索ページでページごとに返される結果数

デフォルト: 10

V2_PAGINATION_SIZE

数値

V2 レジストリー API において、1 ページあたりに返される結果の数

デフォルト: 50

WEBHOOK_HOSTNAME_BLACKLIST

文字列の配列

検証時に、ローカルホスト以外に Webhook から禁止するホスト名のセット

CREATE_PRIVATE_REPO_ON_PUSH

Boolean

プッシュで作成された新規リポジトリーがプライベート表示に設定されているかどうか

デフォルト: True

CREATE_NAMESPACE_ON_PUSH

Boolean

既存の組織への新規プッシュで namespace を作成するかどうか

デフォルト: False

NON_RATE_LIMITED_NAMESPACES

文字列の配列

FEATURE_RATE_LIMITS を使用してレートの制限が有効で、特定の namespace で無制限のアクセス権が必要な場合に、オーバーライドできます。

FEATURE_UI_V2

Boolean

設定すると、ユーザーはベータ UI 環境を試すことができます。

デフォルト: True

2.31.1. その他の設定フィールドのリファレンス

次の参照を使用して、目的の設定フィールドで config.yaml ファイルを更新します。

2.31.1.1. v2 ユーザーインターフェイス設定

FEATURE_UI_V2 を有効にすると、現在のバージョンのユーザーインターフェイスと新しいバージョンのユーザーインターフェイスを切り替えることができます。

重要
  • この UI は現在ベータ版であり、変更される可能性があります。現在の状態では、ユーザーは組織、リポジトリー、およびイメージタグのみを作成、表示、および削除できます。
  • 古い UI で Red Hat Quay を実行している場合、セッションがタイムアウトすると、ユーザーはポップアップウィンドウでパスワードを再度入力する必要がありました。新しい UI では、ユーザーはメインページに戻り、ユーザー名とパスワードの認証情報を入力する必要があります。これは既知の問題であり、新しい UI の今後のバージョンで修正される予定です。
  • 従来の UI と新しい UI の間で、イメージマニフェストのサイズが報告される方法に違いがあります。従来の UI では、イメージマニフェストはメビバイト単位で報告されていました。新しい UI では、Red Hat Quay はメガバイト (MB) の標準定義を使用して、イメージマニフェストのサイズを報告します。

手順

  1. デプロイメントの config.yaml ファイルで、FEATURE_UI_V2 パラメーターを追加し、true に設定します。次に例を示します。 

    ---
FEATURE_TEAM_SYNCING: false
FEATURE_UI_V2: true
FEATURE_USER_CREATION: true
---
  2. Red Hat Quay デプロイメントにログインします。

  3. Red Hat Quay デプロイメントのナビゲーションペインに、現在の UI と 新しい UI を切り替えるオプションが表示されます。切り替えボタンをクリックして新しい UI に設定し、次に Use Beta Environment をクリックします。次に例を示します。

    Red Hat Quay 3.8 UI toggle

2.31.1.1.1. Red Hat Quay 3.8 ベータ UI での新しい組織の作成

前提条件

  • 3.8 ベータ UI を使用するように Red Hat Quay デプロイメントを切り替えている。

以下の手順に従って、Red Hat Quay 3.8 ベータ UI を使用して組織を作成します。

手順

  1. ナビゲーションペインで Organization をクリックします。
  2. Create Organization をクリックします。
  3. Organization Name (testorg など) を入力します。
  4. Create をクリックします。

これで、サンプルの組織が Organizations ページの下に表示されます。

2.31.1.1.2. Red Hat Quay 3.8 ベータ UI を使用した組織の削除

以下の手順に従って、Red Hat Quay 3.8 ベータ UI を使用して組織を削除します。

手順

  1. Organizations ページで、削除する組織の名前 (testorg など) を選択します。
  2. More Actions ドロップダウンメニューをクリックします。

  3. Delete をクリックします。

    注記

    Delete ページには、Search 入力ボックスがあります。このボックスを使用すると、ユーザーは特定の組織を検索して、削除が適切にスケジュールされていることを確認できます。たとえば、ユーザーが 10 の組織を削除していて、特定の組織が削除されたことを確認したい場合、Search 入力ボックスを使用して、その組織が削除対象としてマークされていることを確認できます。

  4. ボックスに confirm と入力して、組織を完全に削除することを確定します。
  5. Delete をクリックします。

削除後、Organizations ページに戻ります。

注記

複数の組織を選択してから、More Actions → Delete をクリックすると、一度に複数の組織を削除できます。

2.31.1.1.3. Red Hat Quay 3.8 ベータ UI を使用した新しいリポジトリーの作成

以下の手順に従って、Red Hat Quay 3.8 ベータ UI を使用してリポジトリーを作成します。

手順

  1. ナビゲーションペインで Repositories をクリックします。
  2. Create Repository をクリックします。
  3. 名前空間 (例: quayadmin) を選択し、リポジトリー名 (例: testrepo) を入力します。
  4. Create をクリックします。

これで、サンプルリポジトリーが Repositories ページの下に表示されるはずです。

2.31.1.1.4. Red Hat Quay 3.8 ベータ UI を使用したリポジトリーの削除

前提条件

  • リポジトリーを作成している。

手順

  1. Red Hat Quay 3.8 ベータ UI の Repositories ページで、削除するイメージの名前 (quay/admin/busybox など) をクリックします。
  2. More Actions ドロップダウンメニューをクリックします。

  3. Delete をクリックします。

    注記

    必要に応じて、Make Public または Make Private をクリックできます。

  4. ボックスに confirm と入力してから、Delete をクリックします。
  5. 削除後、Repositories ページに戻ります。
2.31.1.1.5. Red Hat Quay 3.8 ベータ UI へのイメージのプッシュ

以下の手順に従って、イメージを Red Hat Quay 3.8 ベータ UI にプッシュします。

手順

  1. 外部レジストリーからサンプルイメージをプルします。 

    $ podman pull busybox

  2. イメージにタグを付けます。 

    $ podman tag docker.io/library/busybox quay-server.example.com/quayadmin/busybox:test

  3. イメージを Red Hat Quay レジストリーにプッシュします。 

    $ podman push quay-server.example.com/quayadmin/busybox:test
  4. Red Hat Quay UI の Repositories ページに移動し、イメージが適切にプッシュされていることを確認します。
  5. イメージタグを選択し、Security Report ページに移動すると、セキュリティーの詳細を確認できます。
2.31.1.1.6. Red Hat Quay 3.8 ベータ UI を使用したイメージの削除

以下の手順に従って、Red Hat Quay 3.8 ベータ UI を使用してイメージを削除します。

前提条件

  • イメージを Red Hat Quay レジストリーにプッシュしている。

手順

  1. Red Hat Quay 3.8 ベータ UI の Repositories ページで、削除するイメージの名前 (quay/admin/busybox など) をクリックします。
  2. More Actions ドロップダウンメニューをクリックします。

  3. Delete をクリックします。

    注記

    必要に応じて、Make Public または Make Private をクリックできます。

  4. ボックスに confirm と入力してから、Delete をクリックします。
  5. 削除後、Repositories ページに戻ります。
2.31.1.1.7. Red Hat Quay レガシー UI の有効化

  1. Red Hat Quay デプロイメントのナビゲーションペインに、Current UI と New UI を切り替えるオプションが表示されます。切り替えボタンをクリックして、Current UI に設定します。

    Red Hat Quay 3.8 UI toggle

2.32. レガシー設定フィールド

一部のフィールドは非推奨または廃止されています。

表2.35 レガシー設定フィールド
フィールドタイプ説明

FEATURE_BLACKLISTED_EMAILS

Boolean

true に設定すると、メールドメインがブラックリストに指定されている場合には、新しいユーザーアカウントが作成されません。

BLACKLISTED_EMAIL_DOMAINS

文字列の配列

FEATURE_BLACKLISTED_EMAILS が true に設定されている場合に使用されるメールアドレスドメインの一覧

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

BLACKLIST_V2_SPEC

String

Red Hat Quay が V2 は サポート対象外 であることを示す応答を返す Docker CLI バージョン。

例: <1.8.0
デフォルト: <1.6.0

DOCUMENTATION_ROOT

String

ドキュメントリンクのルート URL

SECURITY_SCANNER_V4_NAMESPACE_WHITELIST

String

セキュリティースキャナーを有効にする namespace

FEATURE_RESTRICTED_V1_PUSH

ブール値

true に設定すると、V1_PUSH_WHITELIST にリストされている名前空間のみが V1 プッシュをサポートします

デフォルト: True

V1_PUSH_WHITELIST

文字列の配列

FEATURE_RESTRICTED_V1_PUSH が true に設定されている場合に V1 push をサポートする namespace 名の配列。

2.33. ユーザーインターフェイス v2 設定フィールド

表2.36 ユーザーインターフェイス v2 設定フィールド
フィールドタイプ説明

FEATURE_UI_V2

Boolean

設定すると、ユーザーはベータ UI 環境を試すことができます。

デフォルト: False

2.34. IPv6 設定フィールド

表2.37 IPv6 設定フィールド
フィールドタイプ説明

FEATURE_LISTEN_IP_VERSION

String

IPv4、IPv6、またはデュアルスタックプロトコルファミリーを有効にします。この設定フィールドは正しく設定する必要があります。そうしないと、Red Hat Quay は起動に失敗します。

デフォルト: IPv4

追加設定: IPv6、デュアルスタック

2.35. ブランディング設定フィールド

表2.38 ブランディング設定フィールド
フィールドタイプ説明

BRANDING

Object

Red Hat Quay UI のロゴおよび URL のカスタムブランディング

.logo
(必須)

String

メインのロゴイメージ URL。

ヘッダーロゴのデフォルトは 205x30 PX です。Web UI の Red Hat Quay サインイン画面のフォームロゴは、デフォルトで 356.5x39.7 PX です。
例:
/static/img/quay-horizontal-color.svg

.footer_img

String

UI フッターのロゴ。デフォルトは 144x34 ピクセルです。

例:
/static/img/RedHat.svg

.footer_url

String

フッターイメージへのリンク。

例:
https://redhat.com

2.35.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/

2.36. セッションタイムアウト設定フィールド

次の設定フィールドは、同じ名前の Flask API 設定フィールドに依存しています。

表2.39 セッションログアウト設定フィールド
フィールドタイプ説明

PERMANENT_SESSION_LIFETIME

Integer

永続セッションの有効期限を設定するために使用される timedelta。デフォルトは 31 日で、永続セッションは約 1 か月間存続します。

デフォルト: 2678400

2.36.1. 設定セッションタイムアウトの設定例

次の YAML は、セッションの有効期間を有効にする場合の推奨設定です。

重要

セッションの有効期間を変更することは推奨できません。管理者は、セッションタイムアウトを設定するときに、割り当てられた時間を認識する必要があります。時間が早すぎると、ワークフローが中断される可能性があります。

セッションタイムアウトの YAML 設定

PERMANENT_SESSION_LIFETIME: 3000

第3章 環境変数

Red Hat Quay は、動的に設定する多数の環境変数をサポートします。

3.1. Geo レプリケーション

ストレージバックエンド以外のすべてのリージョンで同じ設定を使用する必要があります。これは、QUAY_DISTRIBUTED_STORAGE_PREFERENCE 環境変数を使用して明示的に設定できます。

表3.1 Geo レプリケーションの設定
変数タイプ説明

QUAY_DISTRIBUTED_STORAGE_PREFERENCE

String

使用する優先されるストレージ (DISTRIBUTED_STORAGE_CONFIG の ID 別)

3.2. データベース接続プール

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

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

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

データベース接続プーリングは、環境変数 DB_CONNECTION_POOLING を true または false に設定することで切り替えることができます。

表3.2 データベース接続プールの設定
変数タイプ説明

DB_CONNECTION_POOLING

Boolean

データベース接続プールの有効化または無効化

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

config.yaml

...
DB_CONNECTION_ARGS:
  max_connections: 10
...

3.3. HTTP 接続回数

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

表3.3 HTTP 接続数の設定
変数タイプ説明

WORKER_CONNECTION_COUNT

数値

同時 HTTP 接続

デフォルト: 50

WORKER_CONNECTION_COUNT_REGISTRY

数値

レジストリーの同時 HTTP 接続

デフォルト: WORKER_CONNECTION_COUNT

WORKER_CONNECTION_COUNT_WEB

数値

Web UI の同時 HTTP 接続

デフォルト: WORKER_CONNECTION_COUNT

WORKER_CONNECTION_COUNT_SECSCAN

数値

Clair の同時 HTTP 接続

デフォルト: WORKER_CONNECTION_COUNT

3.4. ワーカーカウント変数

表3.4 ワーカーカウント変数
変数タイプ説明

WORKER_COUNT

数値

プロセス数の汎用上書き

WORKER_COUNT_REGISTRY

数値

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

値: 8 から 64 までの整数。

WORKER_COUNT_WEB

数値

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

値: 2 から 32 までの整数。

WORKER_COUNT_SECSCAN

数値

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

値: 2 から 4 までの整数。

3.5. デバッグ変数

次のデバッグ変数は Red Hat Quay で利用できます。

表3.5 デバッグ設定変数
変数タイプ説明

DEBUGLOG

Boolean

デバッグログを有効または無効にするかどうか。

USERS_DEBUG

整数0 または 1 のいずれか。

パスワードを含むクリアテキストで LDAP 操作をデバッグするために使用されます。DEBUGLOG=TRUE とともに使用する必要があります。

重要

USERS_DEBUG=1 を設定すると、認証情報がクリアテキストで公開されます。この変数は、デバッグ後に Red Hat Quay デプロイメントから削除する必要があります。この環境変数を使用して生成されたログファイルは精査する必要があり、他のユーザーに送信する前にパスワードを削除する必要があります。注意して使用してください。

第4章 設定ツールを使用した OpenShift における Quay の再設定

4.1. 設定エディターへのアクセス

QuayRegistry 画面の Details セクションには、設定エディターのエンドポイントと、設定エディターへのログインに使用する認証情報などのシークレットのリンクがあります。

Config editor details

4.1.1. 設定エディターの認証情報の取得

  1. 設定エディターシークレットのリンクをクリックします。

    Config editor secret

  2. Secret details 画面の Data セクションで、Reveal values をクリックし、設定エディターへのログインに使用する認証情報を表示します。

    Config editor secret reveal

4.1.2. 設定エディターへのログイン

設定エディターエンドポイントを参照し、設定ツールにアクセスする時に使用するユーザー名 (通常は quayconfig)、および対応するパスワードを入力します。

Config editor user interface

4.1.3. 設定の変更

次の例では、削除されたタグのデフォルトの有効期限を変更して、設定ファイルを更新します。

手順

  1. 設定エディターで、Time Machine セクションを見つけます。

  2. 許可された有効期限 ボックスに有効期限を追加します (例: 4w)。

    Add expiration period

  3. Validate Configuration Changes を選択して、変更が有効であることを確認します。

  4. Reconfigure Quay を押して変更を適用します。

    Reconfigure

変更を適用した後、設定ツールは、加えられた変更が Red Hat Quay デプロイメントに送信されたことを通知します。

+ Reconfigured

注記

設定ツール UI を使用して Red Hat Quay を再設定すると、更新された設定が適用されるまでの間、レジストリーが短時間使用できなくなる可能性があります。

4.2. UI での再設定の監視

4.2.1. QuayRegistry リソース

Operator の再設定後に、QuayRegistry の特定インスタンスの YAML タブで再デプロイの進捗を追跡できます (この場合は example-registry)。

ui monitor deploy update

ステータスが変わるたびに、データをリロードして更新されたバージョンを表示するように求められます。最終的に、Operator は変更を調整し、正常でないコンポーネントが報告されることはありません。

ui monitor deploy done

4.2.2. イベント

QuayRegistry の Events タブには、再デプロイに関連するイベントが表示されます。

ui monitor deploy streaming events

再設定の影響を受ける namespace のすべてのリソースのストリーミングイベントは、Home → Events の OpenShift コンソールで利用できます。

ui monitor deploy streaming events

4.3. 再設定後に更新された情報へのアクセス

4.3.1. UI で更新された設定ツールの認証情報へのアクセス

Red Hat Quay 3.7 では、UI を介して Quay を再設定しても、新しいログインパスワードが生成されなくなりました。パスワードは 1 回だけ生成され、QuayRegistry オブジェクトを調整した後も同じままです。

4.3.2. UI で更新された config.yaml へのアクセス

設定バンドルを使用して、更新された config.yaml ファイルにアクセスします。

  1. QuayRegistry の詳細画面で、Config Bundle Secret をクリックします。
  2. Secret の詳細画面の Data セクションで、Reveal values をクリックし、config.yaml ファイルを表示します。

  3. 変更が適用されていることを確認します。この場合、4w は TAG_EXPIRATION_OPTIONS の一覧に存在するはずです。 

    ...
SERVER_HOSTNAME: example-quay-openshift-operators.apps.docs.quayteam.org
SETUP_COMPLETE: true
SUPER_USERS:
- quayadmin
TAG_EXPIRATION_OPTIONS:
- 2w
- 4w
...

第5章 Quay Operator コンポーネント

Quay は強力なコンテナーレジストリープラットフォームであるため、多くの依存関係が存在します。これらには、データベース、オブジェクトストレージ、Redis などが含まれます。Quay Operator は、Kubernetes 上で Quay とその依存関係に指向したデプロイメントを管理します。これらの依存関係は コンポーネント として処理され、QuayRegistry API で設定されます。

QuayRegistry カスタムリソースでは、spec.components フィールドでコンポーネントを設定します。各コンポーネントには、kind (コンポーネントの名前) と managed (コンポーネントのライフサイクルを Operator が処理するかどうかを示すブール値) の 2 つのフィールドがあります。(このフィールドを省略する) デフォルトでは、すべてのコンポーネントが管理され、調整時に表示できるように自動的に入力されます。 

spec:
  components:
    - kind: quay
      managed: true
    - kind: postgres
      managed: true
    - kind: clair
      managed: true
    - kind: redis
      managed: true
    - kind: horizontalpodautoscaler
      managed: true
    - kind: objectstorage
      managed: true
    - kind: route
      managed: true
    - kind: mirror
      managed: true
    - kind: monitoring
      managed: true
    - kind: tls
      managed: true
    - kind: clairpostgres
      managed: true

5.1. 管理コンポーネントの使用

QuayRegistry カスタムリソースで特に指定しない限り、Red Hat Quay Operator は以下の管理コンポーネントにデフォルトを使用します。

  • quay: Red Hat Quay デプロイメントのオーバーライドを保持します。たとえば、環境変数とレプリカの数です。このコンポーネントは Red Hat Quay 3.7 の新機能であり、アンマネージドに設定することはできません。
  • postgres: レジストリーメタデータを保存するには、Software Collections から Postgres 10 のバージョンを使用します。
  • clair: イメージの脆弱性スキャンを提供します。
  • redis: ライブビルダーログと Red Hat Quay チュートリアルを保存します。ガベージコレクションに必要なロックメカニズムも含まれます。
  • horizontalpodautoscaler: メモリー/CPU 消費量に応じて Quay Pod の数を調整します。
  • ObjectStorage: イメージレイヤー Blob を格納するには、Noobaa/RHOCS によって提供される ObjectBucketClaim Kubernetes API を使用します。
  • route: OpenShift Container Platform の外部から Red Hat Quay レジストリーへの外部エントリーポイントを提供します
  • mirror: オプションのリポジトリーミラーリングをサポートするようにリポジトリーミラーワーカーを設定します。
  • monitoring: Grafana ダッシュボード、個別のメトリクスへのアクセス、Quay Pod が頻繁に再起動されていることを通知するアラートなどが含まれます。
  • tls: Red Hat Quay または OpenShift Container Platform が SSL/TLS を処理するかどうかを設定します
  • clairpostgres: 管理された Clair データベースを設定します

Red Hat Quay Operator は、Red Hat Quay がマネージドコンポーネントを使用するために必要な設定およびインストール作業を処理します。Red Hat Quay Operator によって実行される独自のデプロイメントが環境に適していない場合は、以下のセクションで説明するように、Red Hat Quay Operator に unmanaged リソース (オーバーライド) を提供できます。

5.2. 依存関係向けの管理対象外コンポーネントの使用

Quay で使用する Postgres、Redis、またはオブジェクトストレージなどの既存のコンポーネントがある場合は、まず Quay 設定バンドル (config.yaml) 内でそれらを設定し、QuayRegistry でバンドルを参照します (Kubernetes Secret)。これは、非管理対象のコンポーネントを示します。

注記

Quay 設定エディターを使用して、既存の設定バンドルを作成または変更したり、Kubernetes Secret の更新プロセスを単純化したりできます。Quay の設定が設定エディターで変更され、Operator に送信されると、Quay デプロイメントは新規の設定を反映するように更新されます。

5.2.1. 既存の Postgres データベースの使用

要件

外部で管理された PostgreSQL データベースを使用している場合は、デプロイメントを成功させるために手動で pg_trgm 拡張機能を有効にする必要があります。

  1. 必要なデータベースフィールドを使用して設定ファイル config.yaml を作成します。

    config.yaml:

    DB_URI: postgresql://test-quay-database:postgres@test-quay-database:5432/test-quay-database

  2. 設定ファイルを使用してシークレットを作成します。 

    $ kubectl create secret generic --from-file config.yaml=./config.yaml config-bundle-secret

  3. postgres コンポーネントを管理対象外としてマークし、作成された Secret を参照する QuayRegistry YAML ファイル quayregistry.yaml を作成します。

    quayregistry.yaml

    apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  name: example-registry
  namespace: quay-enterprise
spec:
  configBundleSecret: config-bundle-secret
  components:
    - kind: postgres
      managed: false

  4. 以下のセクションで説明されているようにレジストリーをデプロイします。

5.2.2. NooBaa アンマネージドストレージ

  1. Storage → Object Bucket Claims のコンソールで NooBaa Object Bucket Claim を作成します。
  2. アクセスキー、バケット名、エンドポイント (ホスト名)、およびシークレットキーを含む Object Bucket Claim データの詳細を取得します。

  3. Object Bucket Claim (オブジェクトバケット要求) の情報を使用して config.yaml 設定ファイルを作成します。 

    DISTRIBUTED_STORAGE_CONFIG:
  default:
    - RHOCSStorage
    - access_key: WmrXtSGk8B3nABCDEFGH
      bucket_name: my-noobaa-bucket-claim-8b844191-dc6c-444e-9ea4-87ece0abcdef
      hostname: s3.openshift-storage.svc.cluster.local
      is_secure: true
      port: "443"
      secret_key: X9P5SDGJtmSuHFCMSLMbdNCMfUABCDEFGH+C5QD
      storage_path: /datastorage/registry
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: []
DISTRIBUTED_STORAGE_PREFERENCE:
  - default

5.2.3. 水平 Pod オートスケーラー

水平 Pod オートスケーラー (HPA) が Clair、Quay、および Mirror Pod に追加され、負荷の急増時に自動的にスケーリングされるようになりました。

HPA はデフォルトで managed ように設定されているため、Clair Pod、Quay Pod、および Mirror Pod の数は 2 に設定されています。これにより Operator による Red Hat Quay の更新または再設定時、またはイベントの再スケジュール中のダウンタイムの回避が容易になります。

5.2.3.1. Horizontal Pod Autoscaler の無効化

自動スケーリングを無効にするか、独自の HorizontalPodAutoscaler を作成するには、QuayRegistry インスタンスでコンポーネントを unamanged として指定します。以下に例を示します。 

apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  name: example-registry
  namespace: quay-enterprise
spec:
  components:
    - kind: horizontalpodautoscaler
      managed: false

5.3. 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=

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

    $ kubectl --namespace quay-enterprise edit secret/quay-enterprise-config-secret

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

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

5.4. Operator を使用した OCI および Helm の設定

Quay の設定のカスタマイズは、設定バンドルを含むシークレットで提供できます。以下のコマンドを実行して、quay-config-bundle という新規シークレットを適切な namespace に作成します。これには、OCI サポートを有効にするために必要なプロパティーが含まれます。

quay-config-bundle.yaml

apiVersion: v1
stringData:
  config.yaml: |
    FEATURE_GENERAL_OCI_SUPPORT: true
    FEATURE_HELM_OCI_SUPPORT: true
kind: Secret
metadata:
  name: quay-config-bundle
  namespace: quay-enterprise
type: Opaque

重要

Red Hat Quay 3.8 の時点で、FEATURE_HELM_OCI_SUPPORT は非推奨になり、Red Hat Quay の将来のバージョンで削除される予定です。Red Hat Quay 3.6 では、Helm アーティファクトがデフォルトでサポートされ、FEATURE_GENERAL_OCI_SUPPORT プロパティーに含まれています。ユーザーは、サポートを有効にするために config.yaml ファイルを更新する必要がなくなりました。

シークレットを適切な namespace に作成します (この例では quay-enterprise です)。 

$ oc create -n quay-enterprise -f quay-config-bundle.yaml

spec.configBundleSecret フィールドのシークレットを指定します。

quay-registry.yaml

apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  name: example-registry
  namespace: quay-enterprise
spec:
  configBundleSecret: quay-config-bundle

指定された設定でレジストリーを作成します。 

$ oc create -n quay-enterprise -f quay-registry.yaml

5.5. ボリュームサイズのオーバーライド

マネージドコンポーネントにプロビジョニングされるストレージリソースの希望のサイズを指定できます。Clair および Quay PostgreSQL データベースのデフォルトサイズは 50Gi です。パフォーマンス上の理由がある場合や、ストレージバックエンドにサイズ変更機能がない場合など、十分な容量を事前に選択できるようになりました。

以下の例では、Clair および Quay PostgreSQL データベースのボリュームサイズは 70Gi に設定されています。 

apiVersion: quay.redhat.com/v1
kind: QuayRegistry
metadata:
  name: quay-example
  namespace: quay-enterprise
spec:
  configBundleSecret: config-bundle-secret
  components:
    - kind: objectstorage
      managed: false
    - kind: route
      managed: true
    - kind: tls
      managed: false
    - kind: clair
      managed: true
      overrides:
        volumeSize: 70Gi
    - kind: postgres
      managed: true
      overrides:
        volumeSize: 70Gi
    - kind: clairpostgres
      managed: true
注記

clairpostgres コンポーネントのボリュームサイズはオーバーライドできません。これは既知の問題であり、Red Hat Quay の将来のバージョンで修正される予定です。(PROJQUAY-4301)

第6章 Red Hat Quay の Clair

Clair v4 (Clair) は、静的コード分析を活用してイメージコンテンツを解析し、コンテンツに影響を与える脆弱性を報告するオープンソースアプリケーションです。Clair は Red Hat Quay にパッケージ化されており、スタンドアロンと Operator デプロイメントの両方で使用できます。エンタープライズ環境に合わせてコンポーネントを個別にスケーリングできる、非常にスケーラブルな設定で実行できます。

6.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 モードで実行している場合は、設定でインデクサー、マッチャー、通知設定ブロックを指定する必要があります。

6.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 ファイルには、完全を期すためにすべてのキーがリストされています。この設定ファイルをそのまま使用すると、一部のオプションがデフォルトで正常に設定されない場合があります。

6.1.2. Clair の一般的なフィールド

次のセクションでは、Clair デプロイメントで使用できる一般的な設定フィールドを説明します。

フィールドTyphttp_listen_ae説明

http_listen_addr

String

HTTP API が公開される場所を設定します。

デフォルト: :6060

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 証明書。フルチェーン証明書である必要があります。

6.1.3. Clair インデクサー設定フィールド

Clair では、次のインデクサー設定フィールドを使用できます。

フィールドタイプ説明

indexer

Object

Clair インデクサーノード設定を提供します。

.airgap

Boolean

インデクサーとフェッチャーのインターネットへの HTTP アクセスを無効にします。プライベート IPv4 および IPv6 アドレスが許可されます。データベース接続は影響を受けません。

.connstring

String

Postgres 接続文字列。URL または libpq 接続文字列として形式を受け入れます。

.index_report_request_concurrency

Integer

レートは、インデックスレポート作成リクエストの数を制限します。これを 0 に設定すると、この値の自動サイズ調整が試みられます。負の値を設定すると、無制限になります。自動サイジングは、使用可能なコア数の倍数です。

同時実行数を超えた場合、API はステータスコード 429 を返します。

.scanlock_retry

Integer

秒を表す正の整数。並行インデクサーは、マニフェストスキャンをロックして、上書きを回避します。この値は、待機中のインデクサーがロックをポーリングする頻度をチューニングします。

.layer_scan_concurrency

Integer

レイヤーの同時スキャン数を制限する正の整数。インデクサーは、マニフェストのレイヤーを同時にマッチングします。この値は、インデクサーが並行してスキャンするレイヤーの数をチューニングします。

.migrations

Boolean

インデクサーノードがデータベースへの移行を処理するかどうか。

.scanner

String

インデクサー設定。

Scanner を使用すると、設定オプションをレイヤースキャナーに渡すことができます。スキャナーは、そのように設計されていると、構築時にこの設定を渡します。

.scanner.dist

String

特定のスキャナーの名前と値として任意の YAML を持つマップ。

.scanner.package

String

特定のスキャナーの名前と値として任意の YAML を持つマップ。

.scanner.repo

String

特定のスキャナーの名前と値として任意の YAML を持つマップ。

6.1.4. Clair マッチャー設定フィールド

Clair では、次のマッチャー設定フィールドを使用できます。

注記

matchers 設定フィールドとは異なります。

フィールドタイプ説明

matcher

Object

Clair マッチャーノード設定を提供します。

.cache_age

String

レスポンスをキャッシュするように、ユーザーに通知する期間を制御します。

.connstring

String

Postgres 接続文字列。URL または libpq 接続文字列として形式を受け入れます。

.max_conn_pool

Integer

データベース接続プールのサイズを制限します。

Clair では、カスタムの接続プールサイズを使用できます。この数は、同時に許可されるアクティブなデータベース接続の数を直接設定します。

このパラメーターは、将来のバージョンでは無視されます。ユーザーは、接続文字列を使用して、これを設定する必要があります。

.indexer_addr

String

マッチャーはインデクサーに接続して VulnerabilityReport を作成します。このインデクサーの場所は必須です。

デフォルトは 30m です。

.migrations

Boolean

マッチャーノードがデータベースへの移行を処理するかどうか。

.period

String

新しいセキュリティーアドバイザリーの更新頻度を決定します。

デフォルトは 30m です。

.disable_updaters

Boolean

バックグラウンド更新を実行するかどうか。

.update_retention

Integer

ガベージコレクションサイクル間で保持する更新操作の数を設定します。これは、データベースサイズの制約に基づいて安全な MAX 値に設定する必要があります。

デフォルトは 10m です。

0 未満の値を指定すると、ガベージコレクションが無効になります。2 は、更新を通知と比較できるようにするための最小値です。

6.1.5. Clair マッチャー設定フィールド

Clair では、次のマッチャー設定フィールドを使用できます。

注記

matcher 設定フィールドとは異なります。

フィールドタイプ説明

matchers

文字列の配列。

in-tree matchers および remotematchers の設定を提供します。

.names

String

有効なマッチャーについてマッチャーファクトリーに通知する文字列値のリスト。値が null に設定されている場合、マッチャーのデフォルトのリストは、alpine、aws、debian、oracle、photon、python、python、rhel、suse、ubuntu、crda を実行します。

.config

String

特定のマッチャーに設定を提供します。

マッチャーファクトリーコンストラクターに提供されるサブオブジェクトを含むマッチャーの名前をキーとするマップ。以下に例を示します。 

config:
  python:
    ignore_vulns:
      - CVE-XYZ
      - CVE-ABC

6.1.6. Clair アップデーター設定フィールド

Clair では、次のアップデーター設定フィールドを使用できます。

フィールドタイプ説明

updaters

Object

マッチャーの更新マネージャーの設定を提供します。

.sets

String

どのアップデーターを実行するかを更新マネージャーに通知する値のリスト。

値が null に設定されている場合、アップデーターのデフォルトのセットは、alpine、aws、debian、oracle、photon、pyupio、rhel、suse、ubuntu を実行します。

空白のままにすると、更新プログラムは実行されません。

.config

String

特定のアップデーターセットに設定を提供します。

アップデーターセットのコンストラクターに提供されるサブオブジェクトを含むアップデーターセットの名前をキーとするマップ。以下に例を示します。 

config:
  ubuntu:
    security_tracker_url: http://security.url
    ignore_distributions:
      - cosmic

6.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

true の場合、ノーティファイアーは設定された AMQP ブローカーに個別の通知 (コールバックではない) を配信します。

.amqp.rollup

Integer

amqp.direct が true に設定されている場合、この値は直接配信で送信する通知の数をノーティファイアーに通知します。たとえば、direct が true に設定され、amqp.rollup が 5 に設定されている場合、ノーティファイアーは単一の JSON ペイロードで 5 つ以下の通知をブローカーに配信します。値を 0 に設定すると、実質的に 1 に設定されます。

.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

設定されたキューが auto_delete_policy を使用するかどうか。

.amqp.routing_key

String

各通知が送信されるルーティングキーの名前。

.amqp.callback

String

amqp.direct が false に設定されている場合、この URL はブローカーに送信される通知コールバックで提供されます。この URL は、Clair の通知 API エンドポイントを指している必要があります。

.amqp.uris

String

接続先の 1 つ以上の AMQP ブローカーのリスト (優先順位順)。

.amqp.tls

Object

AMQP ブローカーへの TLS/SSL 接続を設定します。

.amqp.tls.root_ca

String

ルート CA を読み取ることができるファイルシステムパス。

.amqp.tls.cert

String

TLS/SSL 証明書を読み取ることができるファイルシステムパス。

注記

Go crypto/x509 パッケージで文書化されているように、Clair は SSL_CERT_DIR も許可します。

.amqp.tls.key

String

TLS/SSL 秘密鍵を読み取ることができるファイルシステムパス。

.stomp

Object

STOMP 配信のノーティファイアーを設定します。

.stomp.direct

Boolean

true の場合、ノーティファイアーは個別の通知 (コールバックではない) を設定済みの STOMP ブローカーに配信します。

.stomp.rollup

Integer

stomp.direct が true に設定されている場合、この値は、1 回の直接配信で送信される通知の数を制限します。たとえば、direct が true に設定され、rollup が 5 に設定されている場合、ノーティファイアーは単一の JSON ペイロードで 5 つ以下の通知をブローカーに配信します。値を 0 に設定すると、実質的に 1 に設定されます。

.stomp.callback

String

stomp.callback が false に設定されている場合は、通知コールバックで指定された URL がブローカーに送信されます。この URL は、Clair の通知 API エンドポイントを指している必要があります。

.stomp.destination

String

通知を配信する STOMP の宛先。

.stomp.uris

String

接続先の 1 つ以上の STOMP ブローカーのリスト (優先順位順)。

.stomp.tls

Object

STOMP ブローカーへの TLS/SSL 接続を設定しました。

.stomp.tls.root_ca

String

ルート CA を読み取ることができるファイルシステムパス。

注記

Go crypto/x509 パッケージで文書化されているように、Clair は SSL_CERT_DIR も尊重します。

.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 パスコード。

6.1.8. Clair 承認設定フィールド

Clair では、次の承認設定フィールドを使用できます。

フィールドタイプ説明

auth

Object

Clair の外部およびサービス内 JWT ベースの認証を定義します。複数の auth 機能が定義されている場合、Clair は 1 つを選択します。現在、複数の機能はサポートされていません。

.psk

String

事前共有キー認証を定義します。

.psk.key

String

JWT の署名と検証を行うすべての当事者間で配布される、base64 でエンコードされた共有キー。

.psk.iss

String

確認する JWT 発行者のリスト。空のリストは、JWT クレームで任意の発行者を受け入れます。

6.1.9. Clair トレース設定フィールド

Clair では、次のトレース設定フィールドを使用できます。

フィールドタイプ説明

trace

Object

OpenTelemetry に基づいて分散トレース設定を定義します。

.name

String

トレースが属するアプリケーションの名前。

.probability

Integer

トレースが発生する確率。

.jaeger

Object

Jaeger トレースの値を定義します。

.jaeger.agent

Object

Jaeger エージェントへの配信を設定するための値を定義します。

.jaeger.agent.endpoint

String

トレースを送信できる <host>:<post> 構文のアドレス。

.jaeger.collector

Object

Jaeger コレクターへの配信を設定するための値を定義します。

.jaeger.collector.endpoint

String

トレースを送信できる <host>:<post> 構文のアドレス。

.jaeger.collector.username

String

Jaeger ユーザー名。

.jaeger.collector.password

String

Jaeger パスワード。

.jaeger.service_name

String

Jaeger に登録されているサービス名。

.jaeger.tags

String

追加のメタデータを提供するキーと値のペア。

.jaeger.buffer_max

Integer

保管および分析のために Jaeger バックエンドに送信される前にメモリーにバッファーできるスパンの最大数。

6.1.10. Clair メトリック設定フィールド

Clair では、次のメトリック設定フィールドを使用できます。

フィールドタイプ説明

metrics

Object

OpenTelemetry に基づいて分散トレース設定を定義します。

.name

String

使用中のメトリックの名前。

.prometheus

String

Prometheus メトリックエクスポーターの設定。

.prometheus.endpoint

String

メトリックが提供されるパスを定義します。

第7章 コンテナーセキュリティー Operator での Pod イメージのスキャン

Container Security Operator (CSO) は、OpenShift Container Platform およびその他の Kubernetes プラットフォームで利用可能な Clair セキュリティースキャナーのアドオンです。CSO を使用すると、ユーザーはアクティブな Pod に関連付けられているコンテナーイメージをスキャンして、既知の脆弱性を見つけることができます。

注記

CSO は、Red Hat Quay と Clair なしでは機能しません。

Container Security Operator (CSO) は、次の機能を実行します。

  • 指定された namespace またはすべての namespace の Pod に関連付けられたコンテナーを監視します。
  • コンテナーのソースであるコンテナーレジストリーにクエリーを実行して、脆弱性情報を取得します (イメージのレジストリーが、Clair スキャンを使用する Red Hat Quay レジストリーなどのイメージスキャンをサポートしている場合)。
  • Kubernetes API の ImageManifestVuln オブジェクトを使用して脆弱性を公開します。
注記

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

7.1. OpenShift Container Platform での Container Security Operator のダウンロードおよび実行

Container Security Operator (CSO) をダウンロードするには、次の手順を使用します。

注記

次の手順では、CSO を marketplace-operators namespace にインストールします。これにより、OpenShift Container Platform クラスターのすべての namespace で CSO を使用できるようになります。

手順

  1. OpenShift Container Platform コンソールページで、Operators → OperatorHub を選択し、Container Security Operator を検索します。
  2. Container Security Operator を選択し、Install を選択して Create Operator Subscription ページに移動します。
  3. 設定 (デフォルトでは、すべての名前空間と自動承認戦略) を確認し、Subcription を選択します。しばらくすると、Installed Operators 画面に Container Security が表示されます。

  4. オプション: カスタム証明書を CSO に追加できます。以下の例では、現在のディレクトリーに quay.crt という名前の証明書を作成します。次に、次のコマンドを実行して証明書を CSO に追加します。 

    $ oc create secret generic container-security-operator-extra-certs --from-file=quay.crt -n openshift-operators
    注記

    新しい証明書を有効にするには、Operator Pod を再起動する必要があります。

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

    Access CSO scanning data from the OpenShift Container Platform dashboard

    重要

    Container Security Operator は現在、Red Hat セキュリティーアドバイザリーの壊れたリンクを提供しています。たとえば、リンク https://access.redhat.com/errata/RHSA-2023:1842%20https://access.redhat.com/security/cve/CVE-2023-23916 が提供される場合があります。URL 内の %20 はスペース文字を表しますが、現時点では 2 つの URL が 1 つの不完全な URL に結合されます (例: https://access.redhat.com/errata/RHSA-2023:1842 と https://access.redhat.com/security/cve/CVE-2023-23916。一時的な回避策として、各 URL をブラウザーにコピーして、適切なページに移動できます。これは既知の問題であり、Red Hat Quay の今後のバージョンで修正される予定です。

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

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

      The CSO points you to a registry containing the vulnerable image

    2. namespaces リンクを選択し、ImageManifestVuln 画面に移動します。ここでは、選択されたイメージの名前、およびイメージが実行されているすべての namespace を確認できます。以下の図は、特定の脆弱なイメージが 2 つの namespace で実行されていることを示しています。

      View namespaces a vulnerable image is running in

この手順を実行すると、どのイメージに脆弱性があるか、それらの脆弱性を修正するために何をしなければならないか、およびイメージが実行されたすべての名前空間がわかります。これを知っていると、次のアクションを実行できます。

  • イメージを実行しているユーザーに、脆弱性を修正する必要があることを警告します。

  • デプロイメント、またはイメージが含まれる Pod を開始したオブジェクトを削除して、イメージの実行を停止します。

    注記

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

7.2. CLI からイメージの脆弱性を問い合わせ

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

$ oc get vuln --all-namespaces
NAMESPACE     NAME              AGE
default       sha256.ca90...    6m56s
skynet        sha256.ca90...    9m37s

特定の脆弱性の詳細を表示するには、脆弱性の 1 つを特定し、その namespace および 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...

法律上の通知

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.