ファイルを選択
  1. base64hub
  2. Web・トークンツール
  3. Kubernetes Secret デコーダー

Kubernetes Secret デコーダー(kubectl の YAML 用)

kubectl get secret NAME -o yaml(または JSON)の Secret を貼り付けると、すべての data: の値がデコードされて表に並びます。キーを 1 つずつ base64 --decode に通す必要はありません。

無料 登録不要・制限なし ローカル アップロードなし 全キー 一度にデコード。複数ドキュメントの YAML にも対応 更新日 2026/10/27

ブラウザ内で処理されます。このページがデータをどこかに送信することはできません – その根拠

Kubernetes の Secret をデコードする方法

  1. kubectl get secret app-db -n shop -o yaml を実行し、出力を入力欄に貼り付けます。-o json の JSON でも構いません。
  2. 表には各キーがデコード後の値とサイズ付きで並び、コピー と Base64 をコピー のボタンもあります。
  3. 出力欄には、同じ Secret を stringData で書き直し、値を平文にしたものが入ります。バイナリの値は data に残ります。
  4. 逆の操作をするには Secret を作成 に切り替えます。KEY=value の行を入れると、Base64 の data を持つ Secret が出力されます。

入力は、kubectl get secrets -o yaml の List、--- で区切った複数のドキュメント、Helm でレンダリングしたマニフェスト、単独の .dockerconfigjson、Base64 の値 1 つだけでも構いません。

例:kubectl の出力とその意味

apiVersion: v1
data:
  DATABASE_URL: cG9zdGdyZXM6Ly9hcHA6czNjcjN0LVBhNTVAZGI6NTQzMi9zaG9w
  DB_PASSWORD: czNjcjN0LVBhNTUK
  DB_USER: YXBw
kind: Secret
metadata:
  name: app-db
  namespace: shop
type: Opaque
キーデコード結果サイズ
DATABASE_URLpostgres://app:s3cr3t-Pa55@db:5432/shop39 B
DB_PASSWORDs3cr3t-Pa55 と改行12 B
DB_USERapp3 B

パスワードは 11 文字なのに、値は 12 バイトあります。誰かが echo 's3cr3t-Pa55' | base64 で作ったため、末尾の改行のせいでデータベースへのログインが失敗します。改行のない Base64 なら czNjcjN0LVBhNTU= です。

デコーダーが認識するもの

  • PEM の証明書と鍵:kubernetes.io/tls の Secret にある tls.crt や tls.key などを示します。証明書には、有効期限や SAN を確認できる 証明書デコーダー へのリンクが付きます。
  • JSON の値 は整形表示されます。
  • バイナリの値:Java のキーストアなどは、ファイル形式、16進数のプレビュー、ダウンロード ボタン付きで表示されます。
  • .dockerconfigjson と .dockercfg の値は、レジストリ、ユーザー名、パスワードに分けられ、auth もデコードされます。これらを優先して扱うなら .dockerconfigjson デコーダー を使ってください。

kubectl のワンライナー

値 1 つの場合。jsonpath の中では、キー名のドットをエスケープします。

kubectl get secret app-db -o jsonpath='{.data.DB_PASSWORD}' | base64 --decode
kubectl get secret app-tls -o jsonpath='{.data.tls\.crt}' | base64 --decode

すべての値をデコードするには、kubectl に組み込みのテンプレート関数 base64decode か jq を使います。

kubectl get secret app-db -o go-template='{{range $k, $v := .data}}{{$k}}={{$v | base64decode}}{{"\n"}}{{end}}'
kubectl get secret app-db -o json | jq '.data | map_values(@base64d)'

改行の罠を避けて Secret を作るには:

kubectl create secret generic app-db --from-literal=DB_PASSWORD='s3cr3t-Pa55' --dry-run=client -o yaml

ほかのシェルのレシピは Bash の Base64 のページ にあります。

制限とよくある問題

  • 「data または stringData を含む Secret が見つかりません」:貼り付けたのはおそらく Deployment か ConfigMap です。ConfigMap の値は平文なので、デコードは要りません。
  • サイズ:Secret は合計 1 MiB までです。Secret を作成 では、適用する前にこの上限、キー名、DNS 形式の名前をチェックします。
  • YAML の機能:kubectl、Helm、Kustomize が出力するものは、ブロックスカラーや複数ドキュメントも含めて読めます。アンカー、エイリアス、マージキーには対応していません。
  • Helm のリリース Secret(sh.helm.release.v1.*)は、Base64 の data の値の中に、さらに gzip データの Base64 が入っています。外側の層をここでデコードしてから、gzip Base64 デコーダー を使ってください。

よくある質問

kubectl で Kubernetes の Secret をデコードするには?

キー 1 つなら kubectl get secret app-db -o jsonpath='{.data.DB_PASSWORD}' | base64 --decode です。すべてのキーをまとめてデコードするなら、-o yaml の出力をここに貼り付けるか、このページにある go-template や jq のワンライナーを使ってください。

Kubernetes の Secret は暗号化されていますか?

data フィールドは Base64 にすぎず、読み取り権限があれば誰でも元に戻せます。etcd での保存時の暗号化はクラスターの別の設定で、誰が Secret を読めるかは RBAC で決まります。エンコードと暗号化の違い をご覧ください。

デコードした Secret の末尾に改行が付いているのはなぜですか?

値が echo -n ではなく echo で作られ、改行までエンコードされたからです。その場合 Base64 はよく K、o=、Cg== で終わります。printf '%s' value | base64 か kubectl create secret --from-literal で作り直してください。

data と stringData の違いは何ですか?

data は Base64 の値を持ち、stringData は書き込み時に API サーバーがエンコードしてくれる平文を受け取ります。読み出すと常に data が返ります。このページの出力欄は Secret を stringData で書き直すので、編集して再適用できます。