2.7. シークレットを使用した機密データの Pod への提供
アプリケーションによっては、パスワードやユーザー名など開発者に使用させない秘密情報が必要になります。
管理者は、Secret オブジェクトを使用して、機密情報をクリアテキストで公開せずに提供できます。
2.7.1. シークレットについて リンクのコピーリンクがクリップボードにコピーされました!
Secret オブジェクトタイプはパスワード、OpenShift Container Platform クライアント設定ファイル、プライベートソースリポジトリーの認証情報などの機密情報を保持するメカニズムを提供します。シークレットは機密内容を Pod から切り離します。シークレットはボリュームプラグインを使用してコンテナーにマウントすることも、システムが 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
シークレットに依存する 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.20 にアップグレードした後も、既存の長期間有効なサービスアカウント API トークンシークレットは削除されず、引き続き機能します。クラスターで使用されている長期有効 API トークンを検出する方法、または不要な場合に削除する方法は、Red Hat ナレッジベースの記事 Long-lived service account API tokens in OpenShift Container Platform を参照してください。
このイメージプルシークレットは、OpenShift イメージレジストリーをクラスターのユーザー認証および認可システムに統合するために必要です。
ただし、ImageRegistry 機能を有効にしていない場合、または Cluster Image Registry Operator の設定で統合済みの OpenShift イメージレジストリーを無効にしている場合、イメージプルシークレットはサービスアカウントごとに生成されません。
統合済みの OpenShift イメージレジストリーを有効にしていたクラスターでそれを無効にすると、以前に生成されたイメージプルシークレットが自動的に削除されます。