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

2.6.2. シークレットの作成方法

管理者は、開発者がシークレットに依存する Pod を作成できるよう事前にシークレットを作成しておく必要があります。

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

  1. 秘密にしておきたいデータを含む秘密オブジェクトを作成します。各シークレットタイプに必要な特定のデータは、以下のセクションで非表示になります。

    不透明なシークレットを作成する YAML オブジェクトの例

    apiVersion: v1
kind: Secret
metadata:
  name: test-secret
type: Opaque 1
data: 2
  username: dmFsdWUtMQ0K
  password: dmFsdWUtMQ0KDQo=
stringData: 3
  hostname: myapp.mydomain.com
  secret.properties: |
    property1=valueA
    property2=valueB

    1
    シークレットのタイプを指定します。
    2
    エンコードされた文字列およびデータを指定します。
    3
    デコードされた文字列およびデータを指定します。

    data フィールドまたは stringdata フィールドの両方ではなく、いずれかを使用してください。

  2. Pod のサービスアカウントをシークレットを参照するように更新します。

    シークレットを使用するサービスアカウントの YAML

    apiVersion: v1
kind: ServiceAccount
 ...
secrets:
- name: test-secret

  3. シークレットを環境変数またはファイルとして使用する Pod を作成します (secret ボリュームを使用)。

    シークレットデータと共にボリュームのファイルが設定された Pod の YAML

    apiVersion: v1
kind: Pod
metadata:
  name: secret-example-pod
spec:
  containers:
    - name: secret-test-container
      image: busybox
      command: [ "/bin/sh", "-c", "cat /etc/secret-volume/*" ]
      volumeMounts: 1
          - name: secret-volume
            mountPath: /etc/secret-volume 2
            readOnly: true 3
  volumes:
    - name: secret-volume
      secret:
        secretName: test-secret 4
  restartPolicy: Never

    1
    シークレットが必要な各コンテナーに volumeMounts フィールドを追加します。
    2
    シークレットが表示される未使用のディレクトリー名を指定します。シークレットデータマップの各キーは mountPath の下にあるファイル名になります。
    3
    true に設定します。true の場合、ドライバーに読み取り専用ボリュームを提供するように指示します。
    4
    シークレットの名前を指定します。

    シークレットデータと共に環境変数が設定された Pod の YAML

    apiVersion: v1
kind: Pod
metadata:
  name: secret-example-pod
spec:
  containers:
    - name: secret-test-container
      image: busybox
      command: [ "/bin/sh", "-c", "export" ]
      env:
        - name: TEST_SECRET_USERNAME_ENV_VAR
          valueFrom:
            secretKeyRef: 1
              name: test-secret
              key: username
  restartPolicy: Never

    1
    シークレットキーを使用する環境変数を指定します。

    シークレットデータと環境変数が設定されたビルド設定の YAML

    apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: secret-example-bc
spec:
  strategy:
    sourceStrategy:
      env:
      - name: TEST_SECRET_USERNAME_ENV_VAR
        valueFrom:
          secretKeyRef: 1
            name: test-secret
            key: username

    1
    シークレットキーを使用する環境変数を指定します。

2.6.2.1. シークレットの作成に関する制限

シークレットを使用するには、Pod がシークレットを参照できる必要があります。シークレットは、以下の 3 つの方法で Pod で使用されます。

  • コンテナーの環境変数を事前に設定するために使用される。
  • 1 つ以上のコンテナーにマウントされるボリュームのファイルとして使用される。
  • Pod のイメージをプルする際に kubelet によって使用される。

ボリュームタイプのシークレットは、ボリュームメカニズムを使用してデータをファイルとしてコンテナーに書き込みます。イメージプルシークレットは、シークレットを namespace のすべての Pod に自動的に挿入するためにサービスアカウントを使用します。

テンプレートにシークレット定義が含まれる場合、テンプレートで指定のシークレットを使用できるようにするには、シークレットのボリュームソースを検証し、指定されるオブジェクト参照が Secret オブジェクトを実際に参照していることを確認できる必要があります。そのため、シークレットはこれに依存する Pod の作成前に作成されている必要があります。最も効果的な方法として、サービスアカウントを使用してシークレットを自動的に挿入することができます。

シークレット API オブジェクトは namespace にあります。それらは同じ namespace の Pod によってのみ参照されます。

個々のシークレットは 1MB のサイズに制限されます。これにより、apiserver および kubelet メモリーを使い切るような大規模なシークレットの作成を防ぐことができます。ただし、小規模なシークレットであってもそれらを数多く作成するとメモリーの消費につながります。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.