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 イメージレジストリーを有効にしていたクラスターでそれを無効にすると、以前に生成されたイメージプルシークレットが自動的に削除されます。

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

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

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

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

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

Legal Notice

Theme

© 2026 Red Hat
トップに戻る