🎄teratailクリスマスプレゼントキャンペーン2024🎄』開催中!

\teratail特別グッズやAmazonギフトカード最大2,000円分が当たる!/

詳細はこちら
GitHub

GitHubは、Gitバージョン管理システムを利用したソフトウェア開発向けの共有ウェブサービスです。GitHub商用プランおよびオープンソースプロジェクト向けの無料アカウントを提供しています。

暗号化

ネットワークを通じてデジタルデータをやり取りする際に、第三者に解読されることのないよう、アルゴリズムを用いてデータを変換すること。

Q&A

解決済

1回答

1825閲覧

[Kubernetes] Secretリソースはエンコードされているだけで暗号化していないのはなぜか?

masarusan24

総合スコア55

GitHub

GitHubは、Gitバージョン管理システムを利用したソフトウェア開発向けの共有ウェブサービスです。GitHub商用プランおよびオープンソースプロジェクト向けの無料アカウントを提供しています。

暗号化

ネットワークを通じてデジタルデータをやり取りする際に、第三者に解読されることのないよう、アルゴリズムを用いてデータを変換すること。

0グッド

0クリップ

投稿2020/11/26 07:24

編集2020/11/27 07:41

前提

DBのユーザ名・パスワード等の機密情報をSecretリソースで記述することを検討しています。

一般的に、このような機密情報はConfigMapではなくSecretで管理するものと思いますが、例えば以下のようなマニフェストから作成する場合、 username password は base64エンコードされている状況になりますが、暗号化されている訳ではないのでRead権限さえあればデコードが可能かと思います。

Secretの例

yml

1apiVersion: v1 2kind: Secret 3matadata: 4 name: sample-db-auth 5type: Opaque 6data: 7 username: cm9vdA== # 'root' をエンコードしたもの 8 password: cm9vdHBhc3N3b3Jk # 'rootpassword' をエンコードしたもの

このままではGitHubでコード管理する際にセキュリティリスクとなってしまうので、kubesec のようなOSSを用いて暗号化してからGitHubにプッシュするのが常套手段なのかと認識しておりますが、ここで疑問が生じました。

疑問

  • Secretのvalueはbase64エンコードのみで暗号化する前提でないのはなぜ?

エンコードするくらいなら、いっそのこと暗号化まで公式でサポートすれば良い
のでは?
そもそもマニフェストをGitHub等でコード管理することを想定していない?
だから、GitHubで管理したい有志によってkubesecのようなOSSが開発された?

  • どうせ暗号化するならConfigMapのマニフェストを暗号してしまえば事足りるのではないか?

わざわざSecretというものがあるのはなぜ?
見えてもよい情報と機密情報とで使い分けるため?

Kubernetes初学者で知識不足や根本的な概念を勘違いしていたら申し訳ありませんが、ご教授いただけるとありがたいです。
よろしくお願いいたします。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答1

0

ベストアンサー

Secretの暗号化が組み込まれていない話について

そもそも最初にbase64で作られた経緯まではわからないので答えになるかはわかりませんが回答させてください。

Kubernetesの強みの1つに「既存の基盤との統合が可能な点」があります。言い換えれば拡張性が高くなるように設計されているということで、インフラ基盤になるべく依存しないようにクラスターを構築するようなエコシステムが用意されています。これのおかげで、AWS、Azure、GCP、OpenStack、VMware、ベアメタルなど様々な環境でKubernetesの恩恵を得られるような開発がコミュニティ手動で行われてきました。

暗号化についても同じことが言えて、kubesecの他にkubernetes-external-secretsのように「外部の暗号化の仕組み」に乗っかることができるようなOSSもありますし、sealed-secretsのようにクラスター内だけで使える復号鍵をデプロイしておくことで安全にリソースを管理できるようにするような仕組みもあります。

今となってはDockerだけに依存しないためのCRI、ネットワークの仕組みを外部と連携できるようにするCNI、上記のCPI(Cloud Provider Interface)、ストレージを外部と連携できるようにするCSIなどさまざまな拡張機能が作られていて、最初は私もなぜだかわかりませんでしたが、こうした拡張性を重視してのことだったのかもしれないなと思うようになりました。

SecretとConfigMapの違いについて

おっしゃるとおり、見かけ上の違いはbase64されてるかどうかのように感じられるかもしれません。どちらもファイル・環境変数としてマウントできますしね。
SecretにあってConfigMapにない機構には以下のようなものがあります。

  • SecretはPodが消えると一緒に消える

ConfigMapをPodにマウントすると、該当のPodがコンテナとして動くノードの物理ディスク(SSD/HDD)にConfigMapがロードされます。このとき、Podが削除されたとしても、物理ディスクのデータが書き込まれた以上復元のリスクがあります。
一方でSecretはマウントする際にtmpfs、つまりRAMディスクを使用します。これは揮発ディスクなので、物理ディスクと違い再現のリスクが低いです。

  • Secretはさまざまな種類の「秘匿情報」フォーマットをサポートしている

Secretがサポートするデータにはいくつが種類があって、代表的なものにTLSで使う暗号鍵、Dockerレジストリへの接続情報があります。このへんの細かいデータの読み出しにおけるちょっとしたハックがいらなくなる(パースして読み出すとか)点については便利かなと思います。

投稿2020/11/28 01:54

inductor

総合スコア428

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

masarusan24

2020/11/30 07:05

@inductor さん ご回答ありがとうございます。 ## Secretの暗号化が組み込まれていない話について こちらのご意見、非常に参考になりました。 ごく簡単にまとめると、 Kubernetesの **拡張性を重視した設計思想** にのっとり、特定のアルゴリズムや形式に依存することなく、各種OSSを駆使しながら暗号化可能な状態にしている。 という感じでしょうか。 base64エンコードしているのは、 `kubectl get secret -o yaml` でマニフェスト全体を表示した時に、エンコードした状態で表示させて画面上ではすぐに判別が付かなくするための最低限の配慮なのかな、と理解しました。 ## SecretとConfigMapの違いについて > 見かけ上の違いはbase64されてるかどうかのように感じられるかもしれません。どちらもファイル・環境変数としてマウントできますしね。 はい、そのように感じてこの質問をさせていただきました。 > SecretはPodが消えると一緒に消える なるほどです。揮発性のある場所に保存するので、より安全性が高いということで理解出来ました。 > Secretはさまざまな種類の「秘匿情報」フォーマットをサポートしている TLSやDockerレジストリ等の情報をSecretにするケースがありましたら参考にさせていただきます。ありがとうございます。 今回は、DBの接続情報なんかをマニフェストにしてGitHubで管理する想定ですので、 `type: Opaque` としてSecretのマニフェストファイルを作成し、値を kubesec で暗号化する方向で考えております。
masarusan24

2020/12/07 02:55

ご回答いただいた内容で質問の意図は満たせたと思うのでクローズします。 ありがとうございました。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.36%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問