第21章シークレット

21.1. シークレットの使用

このトピックでは、シークレットの重要なプロパティーについて説明し、開発者がこれらを使用する方法の概要を説明します。

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

YAML シークレットオブジェクト定義

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
  namespace: my-namespace
type: Opaque 1
data: 2
  username: dmFsdWUtMQ0K 3
  password: dmFsdWUtMg0KDQo=
stringData: 4
  hostname: myapp.mydomain.com 5

1

「シークレットのキーの名前と値の構造」を指定します。

2

data フィールドのキーに使用可能な形式は Kubernetes identifiers glossary の DNS_SUBDOMAIN 値のガイドラインに従う必要があります。

3

data マップのキーに関連付けられる値は base64 でエンコーディングされている必要があります。

4

stringData マップのキーに関連付けられた値は単純なテキスト文字列で構成されます。

5

stringData マップのエントリーが base64 に変換され、このエントリーは自動的に data マップに移動します。このフィールドは書き込み専用です。この値は data フィールドでのみ返されます。

ローカルの .docker/config.json ファイルからシークレットを作成します。
```
$ oc create secret generic dockerhub \
    --from-file=.dockerconfigjson=<path/to/.docker/config.json> \
    --type=kubernetes.io/dockerconfigjson
```
このコマンドにより、dockerhub という名前のシークレットの JSON 仕様が生成され、オブジェクトが作成されます。

YAML の不透明なシークレットオブジェクトの定義

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque 1
data:
  username: dXNlci1uYW1l
  password: cGFzc3dvcmQ=

1: 不透明な シークレットを指定します。

Docker 設定の JSON ファイルシークレットオブジェクトの定義

apiVersion: v1
kind: Secret
metadata:
  name: aregistrykey
  namespace: myapps
type: kubernetes.io/dockerconfigjson 1
data:
  .dockerconfigjson:bm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg== 2

1: シークレットが Docker 設定の JSON ファイルを使用することを指定します。
2: Docker 設定 JSON ファイルを base64 でエンコードした出力

21.1.1. シークレットのプロパティー

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

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

21.1.2. シークレットの作成

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

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

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

作成コマンドを使用して JSON または YAML ファイルのシークレットオブジェクトを作成できます。

$ oc create -f <filename>

21.1.3. シークレットの種類

type フィールドの値で、シークレットのキー名と値の構造を指定します。このタイプを使用して、シークレットオブジェクトにユーザー名とキーを強制的に配置することができます。検証の必要がない場合には、デフォルト設定の opaque タイプを使用してください。

以下のタイプから 1 つ指定して、サーバー側で最小限の検証をトリガーし、シークレットデータに固有のキー名が存在するようにします。

kubernetes.io/service-account-token。サービスアカウントトークンを使用します。
kubernetes.io/dockercfg。必須の Docker 認証には .dockercfg ファイルを使用します。
kubernetes.io/dockerconfigjson。必須の Docker 認証には .docker/config.json ファイルを使用します。
kubernetes.io/basic-auth。Basic 認証で使用します。
kubernetes.io/ssh-auth。SSH 鍵認証で使用します。
kubernetes.io/tls。TLS 証明局で使用します。

検証が必要ない場合には type= Opaque と指定します。これは、シークレットがキー名または値の規則に準拠しないという意味です。opaque なシークレットでは、任意の値を含む、体系化されていない key:value ペアも利用できます。

注記

example.com/my-secret-type などの他の任意のタイプを指定できます。これらのタイプは、サーバー側で強制されませんが、シークレットの作成者がその種類のキー/値の要件に従う意思があることを示します。

異なるシークレットタイプの例については、シークレットの使用 の「コードサンプル」を参照してください。

21.1.4. シークレットの更新

シークレットの値を変更する場合、値 (すでに実行されている Pod で使用される値) は動的に変更されません。シークレットを変更するには、元の Pod を削除してから新規の Pod を作成する必要があります (同じ PodSpec を使用する場合があります)。

シークレットの更新は、新規コンテナーイメージのデプロイと同じワークフローで実行されます。kubectl rolling-update コマンドを使用できます。

シークレットの resourceVersion 値は参照時に指定されません。したがって、シークレットが Pod の起動と同じタイミングで更新される場合、Pod に使用されるシークレットのバージョンは定義されません。

注記

現時点で、Pod の作成時に使用されるシークレットオブジェクトのリソースバージョンを確認することはできません。今後はコントローラーが古い resourceVersion を使用して再起動できるよう Pod がこの情報を報告できるようにすることが予定されています。それまでは既存シークレットのデータを更新せずに別の名前で新規のシークレットを作成します。

21.2. ボリュームおよび環境変数のシークレット

シークレットデータを含む YAML ファイルのサンプルを参照してください。

シークレットの作成後に以下を実行できます。

シークレットを参照する Pod を作成します。
```
$ oc create -f <your_yaml_file>.yaml
```
ログを取得します。
```
$ oc logs secret-example-pod
```
Pod を削除します。
```
$ oc delete pod secret-example-pod
```

21.3. イメージプルのシークレット

詳細は、「イメージプルシークレットの使用」を参照してください。

21.4. ソースクローンのシークレット

ビルド時にソースクローンのシークレットを使用する方法についての詳細は、「ビルド入力」を参照してください。

21.5. サービス提供証明書のシークレット

サービスが提供する証明書のシークレットは、追加設定なしの証明書を必要とする複雑なミドルウェアアプリケーションをサポートするように設計されています。これにはノードおよびマスターの管理者ツールで生成されるサーバー証明書と同じ設定が含まれます。

サービスへの通信を確保するには、クラスターで署名された証明書/キーのペアを生成し、これを namespace のシークレットに入れます。これを実行するには、シークレットに使用する名前に設定した値を使って service.alpha.openshift.io/serving-cert-secret-name アノテーションをサービスに設定します。その後に PodSpec はそのシークレットをマウントできます。利用可能になると Pod が実行されます。この証明書は内部サービス DNS 名 <service.name>.<service.namespace>.svc に適しています。

証明書およびキーは PEM 形式であり、tls.crt と tls.key にそれぞれ保存されます。証明書/キーのペアは有効期限に近づくと自動的に置換されます。シークレットの service.alpha.openshift.io/expiry アノテーションで RFC3339 形式の有効期限の日付を確認します。

他の Pod は、自動的に Pod にマウントされる /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt ファイルの CA バンドルを使用して、クラスターで作成される証明書 (内部 DNS 名の場合にのみ署名される) を信頼できます。

この機能の署名アルゴリズムは x509.SHA256WithRSA です。ローテーションを手動で実行するには、生成されたシークレットを削除します。新規の証明書が作成されます。

21.6. 制限

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

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

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

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

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

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

21.6.1. シークレットデータキー

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

21.7. 例

例21.1 4 つのファイルを作成する YAML シークレット

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

1: デコードされる値が含まれるファイル
2: デコードされる値が含まれるファイル
3: 提供される文字列が含まれるファイル
4: 提供されるデータが含まれるファイル

例21.2 シークレットデータと共にボリュームのファイルが設定された 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:
          # name must match the volume name below
          - name: secret-volume
            mountPath: /etc/secret-volume
            readOnly: true
  volumes:
    - name: secret-volume
      secret:
        secretName: test-secret
  restartPolicy: Never

例21.3 シークレットデータと共に環境変数が設定された 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:
              name: test-secret
              key: username
  restartPolicy: Never

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

apiVersion: v1
kind: BuildConfig
metadata:
  name: secret-example-bc
spec:
  strategy:
    sourceStrategy:
      env:
      - name: TEST_SECRET_USERNAME_ENV_VAR
        valueFrom:
          secretKeyRef:
            name: test-secret
            key: username

21.8. トラブルシューティング

サービス証明書の生成が失敗する場合 (サービスの service.alpha.openshift.io/serving-cert-generation-error のアノテーション):

secret/ssl-key references serviceUID 62ad25ca-d703-11e6-9d6f-0e9c0057b608, which does not match 77b6dd80-d716-11e6-9d6f-0e9c0057b60

証明書を生成したサービスがすでに存在しないか、またはサービスに異なる serviceUID があります。古いシークレットを削除し、サービスのアノテーション (service.alpha.openshift.io/serving-cert-generation-error、 service.alpha.openshift.io/serving-cert-generation-error-num) をクリアして証明書の再生成を強制的に実行する必要があります。

$ oc delete secret <secret_name>
$ oc annotate service <service_name> service.alpha.openshift.io/serving-cert-generation-error-
$ oc annotate service <service_name> service.alpha.openshift.io/serving-cert-generation-error-num-

注記

アノテーションを削除するコマンドは、削除するアノテーションの後に - を付けます。

第21章シークレット

21.1. シークレットの使用

21.1.1. シークレットのプロパティー

21.1.2. シークレットの作成

21.1.3. シークレットの種類

21.1.4. シークレットの更新

21.2. ボリュームおよび環境変数のシークレット

21.3. イメージプルのシークレット

21.4. ソースクローンのシークレット

21.5. サービス提供証明書のシークレット

21.6. 制限

21.6.1. シークレットデータキー

21.7. 例

21.8. トラブルシューティング

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links

第21章 シークレット

21.1. シークレットの使用

21.1.1. シークレットのプロパティー

21.1.2. シークレットの作成

21.1.3. シークレットの種類

21.1.4. シークレットの更新

21.2. ボリュームおよび環境変数のシークレット

21.3. イメージプルのシークレット

21.4. ソースクローンのシークレット

21.5. サービス提供証明書のシークレット

21.6. 制限

21.6.1. シークレットデータキー

21.7. 例

21.8. トラブルシューティング

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links

第21章シークレット