現在表示しているのは、次のバージョン向けのドキュメントです。Kubernetesバージョン: v1.22
Kubernetes v1.22 のドキュメントは積極的にメンテナンスされていません。現在表示されているバージョンはスナップショットです。最新のドキュメントはこちらです: 最新バージョン
設定ファイルを使用してSecretを管理する
始める前に
Kubernetesクラスターが必要、かつそのクラスターと通信するためにkubectlコマンドラインツールが設定されている必要があります。 このチュートリアルは、コントロールプレーンのホストとして動作していない少なくとも2つのノードを持つクラスターで実行することをおすすめします。 まだクラスターがない場合、minikubeを使って作成するか、 以下のいずれかのKubernetesプレイグラウンドも使用できます:
設定ファイルを作成する
あらかじめYAMLまたはJSON形式でSecretのマニフェストを作成したうえで、オブジェクトを作成することができます。
Secretリソースには、data
とstringData
の2つのマップが含まれています。
data
フィールドは任意のデータを格納するのに使用され、base64でエンコードされます。
stringData
フィールドは利便性のために用意されており、Secretデータをエンコードされていない文字列として提供することができます。
data
とstringData
のキーは、英数字、-
、_
、.
で構成されている必要があります。
たとえば、data
フィールドを使用して2つの文字列をSecretに格納するには、次のように文字列をbase64に変換します:
echo -n 'admin' | base64
出力は次のようになります:
YWRtaW4=
echo -n '1f2d1e2e67df' | base64
出力は次のようになります:
MWYyZDFlMmU2N2Rm
以下のようなSecret設定ファイルを記述します:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: MWYyZDFlMmU2N2Rm
なお、Secretオブジェクトの名前は、有効なDNSサブドメイン名である必要があります。
base64
ユーティリティーを使用する場合、長い行を分割するために-b
オプションを使用するのは避けるべきです。
逆に、Linux ユーザーは、base64
コマンドにオプション-w 0
を追加するか、-w
オプションが利用できない場合には、パイプラインbase64 | tr -d '\n'
を追加する必要があります。
特定のシナリオでは、代わりにstringData
フィールドを使用できます。
このフィールドでは、base64エンコードされていない文字列を直接Secretに入れることができ、Secretの作成時や更新時には、その文字列がエンコードされます。
たとえば、設定ファイルを保存するためにSecretを使用しているアプリケーションをデプロイする際に、デプロイプロセス中に設定ファイルの一部を入力したい場合などが考えられます。
たとえば、次のような設定ファイルを使用しているアプリケーションの場合:
apiUrl: "https://my.api.com/api/v1"
username: "<user>"
password: "<password>"
次のような定義でSecretに格納できます:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
stringData:
config.yaml: |
apiUrl: "https://my.api.com/api/v1"
username: <user>
password: <password>
Secretを作成する
kubectl apply
でSecretを作成します:
kubectl apply -f ./secret.yaml
出力は次のようになります:
secret/mysecret created
Secretを確認する
stringData
フィールドは、書き込み専用の便利なフィールドです。Secretを取得する際には決して出力されません。たとえば、次のようなコマンドを実行した場合:
kubectl get secret mysecret -o yaml
出力は次のようになります:
apiVersion: v1
data:
config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19
kind: Secret
metadata:
creationTimestamp: 2018-11-15T20:40:59Z
name: mysecret
namespace: default
resourceVersion: "7225"
uid: c280ad2e-e916-11e8-98f2-025000000001
type: Opaque
kubectl get
とkubectl describe
コマンドはデフォルトではSecretの内容を表示しません。
これは、Secretが不用意に他人にさらされたり、ターミナルログに保存されたりしないようにするためです。
エンコードされたデータの実際の内容を確認するには、Secretのデコードを参照してください。
username
などのフィールドがdata
とstringData
の両方に指定されている場合は、stringData
の値が使われます。
たとえば、以下のようなSecretの定義の場合:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
stringData:
username: administrator
結果は以下の通りです:
apiVersion: v1
data:
username: YWRtaW5pc3RyYXRvcg==
kind: Secret
metadata:
creationTimestamp: 2018-11-15T20:46:46Z
name: mysecret
namespace: default
resourceVersion: "7579"
uid: 91460ecb-e917-11e8-98f2-025000000001
type: Opaque
YWRtaW5pc3RyYXRvcg==
をデコードするとadministrator
となります。
クリーンアップ
作成したSecretを削除するには次のコマンドを実行します:
kubectl delete secret mysecret
次の項目
- Secretのコンセプトを読む
- kubectlを使用してSecretを管理する方法を知る
- kustomizeを使用してSecretを管理する方法を知る