[{"data":1,"prerenderedAt":473},["ShallowReactive",2],{"blog-ja-kubernetes-secrets-rbac-etcd-encryption":3,"blog-related-ja-kubernetes-secrets-rbac-etcd-encryption":420,"blog-ja-kubernetes-secrets-rbac-etcd-encryption-alt":408},{"id":4,"title":5,"author":6,"body":7,"date":402,"description":403,"extension":404,"image":405,"locale":406,"meta":407,"navigation":408,"path":409,"seo":410,"stem":411,"tags":412,"__hash__":419},"blog\u002Fblog\u002Fja\u002Fkubernetes-secrets-rbac-etcd-encryption.md","Base64を見て安心するな。KubernetesのSecretsが「素通し」される理由とRBAC設計の落とし穴","Kubo Team",{"type":8,"value":9,"toc":386},"minimark",[10,19,22,27,38,56,65,70,83,90,94,114,117,151,159,165,169,172,176,183,187,209,213,226,293,299,303,306,342,351,359,365,368,371],[11,12,13,14,18],"p",{},"Kubernetesの ",[15,16,17],"code",{},"kubectl get secret -o yaml"," を実行して、値がBase64の文字列で表示されるのを見て「暗号化されているから安全だ」と思ったことはないでしょうか。実はこれは大きな誤解です。KubernetesのSecrets管理は、デフォルト設定のままではBase64エンコードが施されているだけで、暗号化は一切行われていません。etcdにアクセスできる人、あるいはRBACの権限設計が甘いクラスタでは、誰でも一瞬でデコードして平文の認証情報を取り出せてしまいます。",[11,20,21],{},"本記事では、この「Base64=暗号化」という思い込みがなぜ生まれるのか、RBACの権限スコープ設計がどのように事故を招くのか、そしてK3s本番運用でSecrets管理を安全にするための具体的な対策を解説します。",[23,24,26],"h2",{"id":25},"_1-暗号化されているという思い込みの正体-base64とetcdの実態","1. 「暗号化されている」という思い込みの正体 — Base64とetcdの実態",[11,28,29,30,33,34,37],{},"KubernetesのSecretリソースをマニフェストとして出力すると、",[15,31,32],{},"data"," フィールドの値はBase64文字列になっています。この見た目のせいで「難読化されている」「暗号化済みだ」と誤解するエンジニアは少なくありません。しかし、Base64はエンコード方式であり、暗号化ではありません。デコードには鍵も何も必要なく、",[15,35,36],{},"echo \u003C値> | base64 -d"," の一行で即座に元の平文に戻せます。",[11,39,40,47,48,51,52,55],{},[41,42,46],"a",{"href":43,"rel":44},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Ftasks\u002Fadminister-cluster\u002Fencrypt-data\u002F",[45],"nofollow","Kubernetes公式ドキュメント","も、デフォルト設定ではSecretやConfigMapなどの機密データがetcdに暗号化されずに保存されることを明記しています。Kubernetes APIサーバーに ",[15,49,50],{},"--encryption-provider-config"," フラグで暗号化設定を渡さない限り、",[15,53,54],{},"identity"," プロバイダー（実質的に暗号化なしの状態）が使われ続けます。つまり、何も設定していないクラスタでは、etcdのバックアップファイルやスナップショットにアクセスできる人間が、そのままSecretsの中身を読めてしまうということです。",[11,57,58,59,64],{},"この構造は、",[41,60,63],{"href":61,"rel":62},"https:\u002F\u002Fdev.classmethod.jp\u002Farticles\u002Fk8s_secret\u002F",[45],"DevelopersIOの解説記事","でも指摘されている通り、「読み込み権限があれば誰でもデコードして平文データを取得できる」という点に集約されます。エンコードと暗号化を混同したまま本番環境を構築してしまうと、監査や第三者機関のセキュリティレビューで初めて問題が発覚するケースも珍しくありません。",[66,67,69],"h3",{"id":68},"k3sでの暗号化オプション","K3sでの暗号化オプション",[11,71,72,73,78,79,82],{},"軽量Kubernetesディストリビューションである K3s では、",[41,74,77],{"href":75,"rel":76},"https:\u002F\u002Fdocs.k3s.io\u002Fsecurity\u002Fsecrets-encryption",[45],"K3s公式ドキュメント","にある通り、",[15,80,81],{},"--secrets-encryption"," フラグをサーバー起動時に指定するだけでetcdに保存されるSecretsを自動的に暗号化できます。AES-CBCの暗号化キーが自動生成され、暗号化設定ファイルがKube-APIServerに渡される仕組みです。ただし、既存のサーバーに後から有効化する場合は再起動が必要になる点には注意が必要です。",[11,84,85],{},[86,87],"img",{"alt":88,"src":89},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-secrets-rbac-etcd-encryption\u002Fsection01.webp",[23,91,93],{"id":92},"_2-rbacの過剰権限が事故を生む-getlistwatchの権限スコープ設計","2. RBACの過剰権限が事故を生む — get\u002Flist\u002Fwatchの権限スコープ設計",[11,95,96,97,102,103,106,107,106,110,113],{},"Secrets管理のもう一つの落とし穴は、RBAC（Role-Based Access Control）の権限スコープです。",[41,98,101],{"href":99,"rel":100},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Freference\u002Faccess-authn-authz\u002Frbac\u002F",[45],"Kubernetes公式のRBACドキュメント","によれば、RBACはRole・ClusterRole・RoleBinding・ClusterRoleBindingという4種類のオブジェクトで構成され、権限は「追加的」にしか付与できません。つまり、一度与えた ",[15,104,105],{},"get","・",[15,108,109],{},"list",[15,111,112],{},"watch"," の権限を後から部分的に取り消す「拒否ルール」は存在しないのです。",[11,115,116],{},"この特性を軽視すると、次のような事故パターンが生まれます。",[118,119,120,131,137],"ul",{},[121,122,123,127,128,130],"li",{},[124,125,126],"strong",{},"Service Account経由の権限拡散",": PodにアタッチされたService AccountにClusterRoleでSecretsへの ",[15,129,109],{}," 権限を付与すると、そのPodで動くあらゆるコンテナ・CI\u002FCDジョブがクラスタ全体のSecretsを読み取れてしまう",[121,132,133,136],{},[124,134,135],{},"Namespace境界の形骸化",": 「namespaceで分離しているから安全」と考えていても、ClusterRoleBindingで横断的な権限を付与していれば境界は意味を持たない",[121,138,139,142,143,146,147,150],{},[124,140,141],{},"ワイルドカードの安易な使用",": ",[15,144,145],{},"resources: [\"*\"]"," や ",[15,148,149],{},"verbs: [\"*\"]"," の指定は、意図しないリソースへのアクセスを許してしまう",[11,152,153,158],{},[41,154,157],{"href":155,"rel":156},"https:\u002F\u002Fwww.wiz.io\u002Facademy\u002Fcontainer-security\u002Fkubernetes-rbac-best-practices",[45],"Wizのコンテナセキュリティ解説","でも、最小権限原則（Principle of Least Privilege）の徹底、ワイルドカードの使用回避、そして権限の定期的な棚卸しが繰り返し強調されています。RBACは「一度設定したら終わり」ではなく、Service AccountやCI\u002FCDパイプラインが増えるたびに見直しが必要な、継続的な運用対象です。",[11,160,161],{},[86,162],{"alt":163,"src":164},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-secrets-rbac-etcd-encryption\u002Fsection02.webp",[23,166,168],{"id":167},"_3-実践対策-etcd暗号化external-secrets-operatorcsi-secrets-store","3. 実践対策 — etcd暗号化、External Secrets Operator、CSI Secrets Store",[11,170,171],{},"Secrets管理を安全にする対策は、導入コストと効果のバランスに応じて大きく3段階に整理できます。",[66,173,175],{"id":174},"対策1-etcd暗号化-at-rest最小コスト","対策1: etcd暗号化 at rest（最小コスト）",[11,177,178,179,182],{},"前述の ",[15,180,181],{},"EncryptionConfiguration"," を設定し、AES-GCMやKMSプロバイダーを利用してetcdへの保存時暗号化を有効にする方法です。既存のクラスタ構成を大きく変えずに導入でき、まず着手すべき最低ラインの対策といえます。",[66,184,186],{"id":185},"対策2-external-secrets-operator-によるvaultクラウド連携","対策2: External Secrets Operator によるVault\u002Fクラウド連携",[11,188,189,194,195,198,199,202,203,208],{},[41,190,193],{"href":191,"rel":192},"https:\u002F\u002Fexternal-secrets.io\u002Flatest\u002Fintroduction\u002Foverview\u002F",[45],"External Secrets Operator（ESO）","は、HashiCorp Vaultや各クラウドのSecrets Managerといった外部システムから認証情報を取得し、Kubernetes Secretとして自動同期するツールです。",[15,196,197],{},"SecretStore"," がアクセス方法を、",[15,200,201],{},"ExternalSecret"," が取得対象を定義するという役割分担により、「どこから」と「何を」の関心を分離できます。",[41,204,207],{"href":205,"rel":206},"https:\u002F\u002Fdeveloper.hashicorp.com\u002Fvault\u002Ftutorials\u002Fkubernetes-introduction\u002Fkubernetes-external-vault",[45],"HashiCorp Vaultの公式チュートリアル","にもある通り、Vault側でアクセスポリシーと監査ログを一元管理できるため、ローテーションや失効の運用負荷を大きく下げられます。",[66,210,212],{"id":211},"対策3-csi-secrets-store-driversecret-objectそのものを作らない","対策3: CSI Secrets Store Driver(Secret Objectそのものを作らない)",[11,214,215,216,221,222,225],{},"より高いセキュリティ要件がある環境では、",[41,217,220],{"href":218,"rel":219},"https:\u002F\u002Fsecrets-store-csi-driver.sigs.k8s.io\u002F",[45],"Secrets Store CSI Driver","の採用が選択肢になります。これは ",[15,223,224],{},"SecretProviderClass"," というCustom Resourceを使い、Kubernetes Secretオブジェクトそのものを作成せずに、外部シークレットストアの値を直接Podのファイルシステムにボリュームとしてマウントする仕組みです。Secret Objectがetcdに一切存在しないため、前述のBase64問題自体が発生しません。",[227,228,229,248],"table",{},[230,231,232],"thead",{},[233,234,235,239,242,245],"tr",{},[236,237,238],"th",{},"対策",[236,240,241],{},"導入コスト",[236,243,244],{},"効果",[236,246,247],{},"向いているケース",[249,250,251,266,279],"tbody",{},[233,252,253,257,260,263],{},[254,255,256],"td",{},"etcd暗号化 at rest",[254,258,259],{},"低",[254,261,262],{},"中",[254,264,265],{},"まず着手すべき最低ライン",[233,267,268,271,273,276],{},[254,269,270],{},"External Secrets Operator",[254,272,262],{},[254,274,275],{},"高",[254,277,278],{},"Vault等を既に運用している組織",[233,280,281,284,287,290],{},[254,282,283],{},"CSI Secrets Store Driver",[254,285,286],{},"中〜高",[254,288,289],{},"最高",[254,291,292],{},"私鍵・規制対象の認証情報を扱う環境",[11,294,295],{},[86,296],{"alt":297,"src":298},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-secrets-rbac-etcd-encryption\u002Fsection03.webp",[23,300,302],{"id":301},"_4-k3s-マネージド運用でのsecretsrbacチェックリスト","4. K3s \u002F マネージド運用でのSecrets・RBACチェックリスト",[11,304,305],{},"本番投入前に、以下の4項目を最低限確認しておくことをおすすめします。",[307,308,309,318,330,336],"ol",{},[121,310,311,314,315,317],{},[124,312,313],{},"暗号化設定",": EncryptionConfiguration（またはK3sの ",[15,316,81],{},"）が有効になっているか",[121,319,320,323,324,326,327,329],{},[124,321,322],{},"監査ログ",": Secretsへの ",[15,325,105],{},"\u002F",[15,328,109],{}," アクセスが監査ログに記録され、追跡可能になっているか",[121,331,332,335],{},[124,333,334],{},"ローテーション",": 暗号化キーおよびSecretsそのものの定期ローテーションが仕組み化されているか",[121,337,338,341],{},[124,339,340],{},"権限棚卸し",": Service Account・RoleBinding・ClusterRoleBindingが最小権限になっているか、定期的に見直されているか",[11,343,344,345,350],{},"これらを自前でゼロから構築・運用しようとすると、クラスタ構築の初期コストだけでなく、継続的な監視・棚卸しの運用負荷がインフラチームにのしかかります。この設定、毎回ゼロから作りますか。",[41,346,349],{"href":347,"rel":348},"https:\u002F\u002Fkubo.hexabase.io\u002F",[45],"Kubo","のようなマネージドK3s環境であれば、こうしたセキュリティ設定の土台がすでに整った状態から運用を始められます。",[11,352,353,354,358],{},"Kuboの",[41,355,357],{"href":347,"rel":356},[45],"Captain UI","は権限設定やクラスタ構成をブラックボックス化せず可視化するため、RBACの棚卸しが属人化しがちという課題にも対応しやすくなります。EKSやAKSを自前で構築・運用する場合と比較しても、K3sベースの軽量な構成でコスト効率よくセキュリティ運用の土台を整えられる点は大きな違いです。",[11,360,361],{},[86,362],{"alt":363,"src":364},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-secrets-rbac-etcd-encryption\u002Fsection04.webp",[23,366,367],{"id":367},"まとめ",[11,369,370],{},"KubernetesのSecretsはBase64エンコードされているだけで、暗号化ではありません。デフォルト設定のままでは、etcdにアクセスできる人間や、RBACの権限設計が甘いクラスタ内の誰もが機密情報を読み取れてしまいます。対策はetcd暗号化・External Secrets Operator・CSI Secrets Store Driverという3段階で、コストと効果のバランスを見ながら段階的に導入できます。",[11,372,373,374,379,380,385],{},"特に金融機関や医療機関など、データ主権やAir-Gapped環境での運用が求められる領域では、Secrets管理とRBAC設計をゼロから自前で構築・監査する負荷は決して小さくありません。そうした本番運用基盤の次の一歩として、",[41,375,378],{"href":376,"rel":377},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fkubo\u002Fon-premise",[45],"Kubo On-Premise","のような、自社インフラ上で完全にコントロールできるマネージドK3s環境を検討する価値があります。まずは",[41,381,384],{"href":382,"rel":383},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[45],"お問い合わせ","から、現状のSecrets・RBAC設計を見直すきっかけにしてみてください。",{"title":387,"searchDepth":388,"depth":388,"links":389},"",2,[390,394,395,400,401],{"id":25,"depth":388,"text":26,"children":391},[392],{"id":68,"depth":393,"text":69},3,{"id":92,"depth":388,"text":93},{"id":167,"depth":388,"text":168,"children":396},[397,398,399],{"id":174,"depth":393,"text":175},{"id":185,"depth":393,"text":186},{"id":211,"depth":393,"text":212},{"id":301,"depth":388,"text":302},{"id":367,"depth":388,"text":367},"2026-07-29","KubernetesのSecretsはBase64エンコードされているだけで、暗号化されていない。etcdへの平文相当保存とRBACの過剰権限が引き起こす事故と、K3s本番運用で実践すべきSecrets管理の対策を解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-secrets-rbac-etcd-encryption\u002Feyecatch.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fkubernetes-secrets-rbac-etcd-encryption",{"title":5,"description":403},"blog\u002Fja\u002Fkubernetes-secrets-rbac-etcd-encryption",[413,414,415,416,417,418],"kubernetes","k3s","secrets-management","rbac","security","etcd-encryption","b0bnWThwAnor5gf9u6GdkQ_zS_J8GDmiJmUeTxpj9ZY",[421,429,437,445,454,463],{"path":422,"title":423,"description":424,"date":425,"tags":426},"\u002Fblog\u002Fja\u002Fkubernetes-certificate-management-cert-manager-process-debt","証明書の更新、1行のコードより2ヶ月の会議が長かった。Kubernetesの証明書管理が『技術』ではなく『手続き』の問題である理由","Kubernetesの証明書管理は技術的には数日で終わる。だが実際に時間がかかるのは合意形成という『手続き』だ。cert-managerによる自動化と、組織的負債をなくす設計を解説する。","2026-08-09",[414,413,427,428,417],"cert-manager","tls",{"path":430,"title":431,"description":432,"date":433,"tags":434},"\u002Fblog\u002Fja\u002Fai-agent-sandbox-kata-containers-kubernetes","AIエージェントのコードは「信頼できる製品」じゃない。Kubernetesサンドボックス設計の答え","AIエージェントが生成・実行するコードはもう「信頼できる製品」ではない。KubernetesでAIエージェント向けサンドボックスを設計する際、コンテナ分離の限界とKata Containersによるマイクロ VM分離がなぜ必要になるのかを解説する。","2026-08-08",[414,413,435,436,417],"kata-containers","ai-agent",{"path":438,"title":439,"description":440,"date":441,"tags":442},"\u002Fblog\u002Fja\u002Fkubernetes-image-signing-sigstore-supply-chain","イメージタグは誰でも書き換えられる。Kubernetesのイメージ署名にSigstoreで『来歴』を刻むという発想","コンテナイメージ署名の仕組みを解説。イメージタグは誰でも書き換え可能で、CI\u002FCDのテストを通過した保証にはならない。SigstoreとKyvernoを組み合わせ、Kubernetes\u002FK3s上で未署名イメージの起動を拒否する防御層を構築する方法を、GitOps運用との統合も含めて紹介する。","2026-08-06",[414,413,443,444,417],"ci-cd","gitops",{"path":446,"title":447,"description":448,"date":449,"tags":450},"\u002Fblog\u002Fja\u002Fshadow-ai-kubernetes-admission-control-governance","野良デプロイが会社を壊す。KubernetesクラスターのシャドーAI問題とAdmission Controlという処方箋","SaaSの無断導入だけがシャドーAIではない。Kubernetesクラスター内で誰が何をデプロイしているか分からない状態が生むリスクと、Admission Controlによるガバナンス実装を解説する。","2026-07-17",[413,414,451,452,453,417],"shadow-ai","admission-control","kyverno",{"path":455,"title":456,"description":457,"date":458,"tags":459},"\u002Fblog\u002Fja\u002Fkubernetes-v136-k3s-managed-cost-reduction","マネージドKubernetesはもう高すぎる。K3s軽量化とv1.36セキュリティ強化で実現する『月額4万円台フルK8s運用』の現実味","Kubernetes v1.36「Haru」で強化されたUser Namespaces、セキュリティ機能をK3s軽量環境で活用する方法を解説。EKSより60%コスト削減を実現するマネージドK3s運用戦略と2026年のインフラ選定指針。","2026-05-28",[414,413,460,461,462,417],"kubernetes-v136","managed-kubernetes","cost-optimization",{"path":464,"title":465,"description":466,"date":467,"tags":468},"\u002Fblog\u002Fja\u002Fk3s-container-image-security-supply-chain-checklist","「スキャン済み」は本番投入の許可証にならない。K3sコンテナイメージセキュリティ、署名からアドミッション制御まで","コンテナ セキュリティ ガイドラインというと『スキャンしてるから大丈夫』で止まりがちだ。K3s環境でベースイメージの最小化から脆弱性スキャン、SBOM生成、署名、アドミッション制御まで、本番投入前に通すべき工程を実務チェックリストとして具体的に解説する。","2026-08-24",[414,413,469,470,471,472],"container-security","image-scanning","sbom","supply-chain-security",1787649513330]