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

2.6. Pod への機密性の高いデータの提供

アプリケーションによっては、パスワードやユーザー名など開発者に使用させない秘密情報が必要になります。

管理者は、Secret オブジェクトを使用して、機密情報をクリアテキストで公開せずに提供できます。

2.6.1. シークレットについて
リンクのコピー

Secret オブジェクトタイプはパスワード、OpenShift Container Platform クライアント設定ファイル、プライベートソースリポジトリーの認証情報などの機密情報を保持するメカニズムを提供します。シークレットは機密内容を Pod から切り離します。シークレットはボリュームプラグインを使用してコンテナーにマウントすることも、システムが Pod の代わりにシークレットを使用して各種アクションを実行することもできます。

キーのプロパティーには以下が含まれます。

  • シークレットデータはその定義とは別に参照できます。
  • シークレットデータのボリュームは一時ファイルストレージ機能 (tmpfs) でサポートされ、ノードで保存されることはありません。
  • シークレットデータは namespace 内で共有できます。

YAML Secret オブジェクト定義

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
  namespace: my-namespace
type: Opaque
1 

data:
2 

  username: <username>
3 

  password: <password>
stringData:
4 

  hostname: myapp.mydomain.com
5

1
シークレットにキー名および値の構造を示しています。
2
data フィールドのキーに使用可能な形式は、Kubernetes identifiers glossary の DNS_SUBDOMAIN 値のガイドラインに従う必要があります。
3
data マップのキーに関連付けられる値は base64 でエンコーディングされている必要があります。
4
stringData マップのエントリーが base64 に変換され、このエントリーは自動的に data マップに移動します。このフィールドは書き込み専用です。この値は data フィールドでのみ返されます。
5
stringData マップのキーに関連付けられた値は単純なテキスト文字列で構成されます。

シークレットに依存する Pod を作成する前に、シークレットを作成する必要があります。

シークレットの作成時に以下を実行します。

  • シークレットデータでシークレットオブジェクトを作成します。
  • Pod のサービスアカウントをシークレットの参照を許可するように更新します。
  • シークレットを環境変数またはファイルとして使用する Pod を作成します (secret ボリュームを使用)。

2.6.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.6.1.2. シークレットデータキー
リンクのコピー

シークレットキーは DNS サブドメインになければなりません。

2.6.1.3. 自動生成されるサービスアカウントトークンシークレット
リンクのコピー

サービスアカウントが作成されると、そのサービスアカウント用のトークンシークレットが自動的に生成されます。このサービスアカウントトークンシークレットは、自動的に生成された Docker 設定シークレットとともに、内部 OpenShift Container Platform レジストリーに対する認証に使用されます。これらの自動生成されたシークレットは、自分での使用に依存することがないようにしてください。これらは将来の OpenShift Container Platform リリースで削除される可能性があります。

注記

OpenShift Container Platform 4.11 より前では、サービスアカウントの作成時に 2 番目のサービスアカウントトークンシークレットが生成されました。このサービスアカウントトークンシークレットは、Kubernetes API へのアクセスに使用されていました。

OpenShift Container Platform 4.11 以降、この 2 番目のサービスアカウントトークンシークレットは作成されなくなりました。これは、LegacyServiceAccountTokenNoAutoGeneration アップストリーム Kubernetes フィーチャーゲートが有効になっており、Kubernetes API にアクセスするためのシークレットベースのサービスアカウントトークンの自動生成が停止されているためです。

4.13 にアップグレードした後も、既存のサービスアカウントトークンシークレットは削除されず、引き続き機能します。

バインドされたサービスアカウントトークンを取得するために、予測されたボリュームでワークロードが自動的に挿入されます。ワークロードに追加のサービスアカウントトークンが必要な場合は、ワークロードマニフェストに追加の予測ボリュームを追加します。バインドされたサービスアカウントトークンは、次の理由により、サービスアカウントトークンのシークレットよりも安全です。

  • バインドされたサービスアカウントトークンには有効期間が制限されています。
  • バインドされたサービスアカウントトークンには対象ユーザーが含まれます。
  • バインドされたサービスアカウントトークンは Pod またはシークレットにバインドでき、バインドされたオブジェクトが削除されるとバインドされたトークンは無効になります。

詳細は、ボリュームプロジェクションを使用したバインドされたサービスアカウントトークンの設定 を参照してください。

読み取り可能な API オブジェクト内の有効期限のないトークンのセキュリティー露出が許容される場合は、サービスアカウントトークンシークレットを手動で作成してトークンを取得することもできます。詳細は、サービスアカウントトークンシークレットの作成 を参照してください。

関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

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

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

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

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

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

Legal Notice

Theme

© 2026 Red Hatトップに戻る