2.7. シークレットを使用した機密データの Pod への提供
管理者として、Secret オブジェクトを使用すると、パスワードやユーザー名などの機密情報を、開発者が閲覧できる平文で公開することなく、アプリケーションに提供できます。
2.7.1. シークレットについて リンクのコピーリンクがクリップボードにコピーされました!
ボリュームプラグインを使用することで、シークレットをコンテナーにマウントできます。また、システムがシークレットを使用して、Pod に代わってアクションを実行することもできます。
Secret オブジェクトタイプはパスワード、OpenShift Container Platform クライアント設定ファイル、プライベートソースリポジトリーの認証情報などの機密情報を保持するメカニズムを提供します。シークレットは機密内容を Pod から切り離します。
キーのプロパティーには以下が含まれます。
- シークレットデータはその定義とは別に参照できます。
- シークレットデータのボリュームは一時ファイルストレージ機能 (tmpfs) でサポートされ、ノードで保存されることはありません。
- シークレットデータは namespace 内で共有できます。
YAML Secret オブジェクト定義
apiVersion: v1
kind: Secret
metadata:
name: test-secret
namespace: my-namespace
type: Opaque
data:
username: <username>
password: <password>
stringData:
hostname: myapp.mydomain.com
各項目の説明:
type- シークレットのキー名と値の構造を指定します。
data-
データフィールド内のキーの許容フォーマットを指定します。このフォーマットは、Kubernetes ドキュメントの Kubernetes における識別子と名前で説明されている DNS_SUBDOMAIN 値のガイドラインを満たす必要があります。 データ.ユーザー名-
データマップ内のキーに関連付けられた値を指定します。この値は Base64 エンコードされている必要があります。 データ.パスワード-
データマップ内のキーに関連付けられた値を指定します。この値は Base64 エンコードされている必要があります。 stringData.hostname-
データマップ内のキーに関連付けられた値を指定します。stringDataマップのキーに関連付けられた値は単純なテキスト文字列で構成されます。stringDataマップのエントリーが base64 に変換され、このエントリーは自動的にdataマップに移動します。このフィールドは書き込み専用です。この値はdataフィールドでのみ返されます。
シークレットに依存する Pod を作成する前に、シークレットを作成する必要があります。
シークレットの作成時に以下を実行します。
- シークレットデータでシークレットオブジェクトを作成します。
- Pod のサービスアカウントをシークレットの参照を許可するように更新します。
-
シークレットを環境変数またはファイルとして使用する Pod を作成します (
secretボリュームを使用)。
2.7.1.1. シークレットの種類 リンクのコピーリンクがクリップボードにコピーされました!
type フィールドの値で、シークレットのキー名と値の構造を指定します。このタイプを使用して、シークレットオブジェクトにユーザー名とキーの配置を実行できます。検証の必要がない場合には、デフォルト設定の opaque タイプを使用してください。
以下のタイプから 1 つ指定して、サーバー側で最小限の検証をトリガーし、シークレットデータに固有のキー名が存在することを確認します。
-
kubernetes.io/basic-auth: Basic 認証で使用します。 -
kubernetes.io/dockercfg: イメージプルシークレットとして使用します。 -
kubernetes.io/dockerconfigjson: イメージプルシークレットとして使用します。 -
kubernetes.io/service-account-token: レガシーサービスアカウント API トークンの取得に使用します。 -
kubernetes.io/ssh-auth: SSH キー認証で使用します。 -
kubernetes.io/tls: TLS 認証局で使用します。
検証が必要ない場合には type: Opaque と指定します。これは、シークレットがキー名または値の規則に準拠しないという意味です。opaque シークレットでは、任意の値を含む、体系化されていない key:value ペアも利用できます。
example.com/my-secret-type などの他の任意のタイプを指定できます。これらのタイプはサーバー側では実行されませんが、シークレットの作成者がその種類のキー/値の要件に従う意図があることを示します。
さまざまな種類のシークレットを作成する例は、シークレットの作成方法 を参照してください。
2.7.1.2. シークレットデータキー リンクのコピーリンクがクリップボードにコピーされました!
シークレットキーは DNS サブドメインになければなりません。
2.7.1.3. 自動的に生成されたイメージプルシークレット リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、各サービスアカウントに対してイメージプルシークレットを自動的に作成し、内部イメージレジストリーとユーザー認証を統合します。
OpenShift Container Platform 4.16 より前では、作成されたサービスアカウントごとに、長期間有効なサービスアカウント API トークンシークレットも生成されていました。OpenShift Container Platform 4.16 以降では、このサービスアカウント API トークンシークレットは作成されません。
バージョン 4.22 にアップグレードした後も、既存の長期有効なサービスアカウント API トークンシークレットは削除されず、引き続き機能します。クラスターで使用されている長期有効 API トークンを検出する方法、または不要な場合に削除する方法は、「Long-lived service account API tokens in OpenShift Container Platform (Red Hat ナレッジベースの記事)」を参照してください。
このイメージプルシークレットは、OpenShift イメージレジストリーをクラスターのユーザー認証および認可システムに統合するために必要です。
ただし、ImageRegistry 機能を有効にしていない場合、または Cluster Image Registry Operator の設定で統合済みの OpenShift イメージレジストリーを無効にしている場合、イメージプルシークレットはサービスアカウントごとに生成されません。
統合済みの OpenShift イメージレジストリーを有効にしていたクラスターでそれを無効にすると、以前に生成されたイメージプルシークレットが自動的に削除されます。