Containers give developers the ability to isolate applications from one another, but that’s not enough. Resource isolation is much different that securi…
この記事はKubernetes Advent Calendar 12日目の記事になります。 Overview KubernetesのPodにパスワードやトークンを指定する際にはSecretを使います。(ってゆうか使ってください) コンテナ内に秘密情報を入れたままDockerHub等にアップロードしてしまい大変な事態に・・・ってことには注意しましょう。 さて、この記事の本題ですが"KubernetesのSecretは本当に安全か"です。 確かにKubernetes上に機能として存在しますが、本当に安全性は確保されているのでしょうか? また、もしノードが攻撃された場合、どの程度までSecretのデータを守れるのでしょうか? この記事では公式ドキュメントを参考に現在のSecretについて紹介できればと思います。 ※著者はまだまだ未熟者ゆえ間違い等もあるかと思いますが、温かい目&お手柔らかなコメン
この記事は Pod Security Policy (PodSecurityPolicy)によるセキュリティの設定について Kubernetes v1.9 で確認した内容になります。v1.9 未満では RBAC 周りで大きな違いがあるのでご注意ください。 PodSecurityPolicy とは PodSecurityPolicy とはクラスタ全体のセキュリティ上のポリシーを定義する機能です。ホストに影響を与える可能性がある 特権 (privileged) や HostIPC などの機能を制限し Pod に脆弱性があった場合にクラスタを守ることができます。ポリシーの制限は Admission Control として実装されており、ポリシーを満たしていない Pod の実行を拒否することができるようになります。Design Proposal を見るとマルチテナントでの利用を想定した機能のようで
Removed featurePodSecurityPolicy was deprecated in Kubernetes v1.21, and removed from Kubernetes in v1.25. Instead of using PodSecurityPolicy, you can enforce similar restrictions on Pods using either or both: Pod Security Admissiona 3rd party admission plugin, that you deploy and configure yourselfFor a migration guide, see Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Cont
Japan Container Days v18.04 で表題のセッションを聞いたので、まとめました。 スライド資料Kubernetesのセキュリティのベストプラクティス(SpeakerDeck) APIサーバへの攻撃を防ぐRBACでPodに付与される権限を絞るPodにはシークレットが自動でマウントされるため、不正アクセスにより読み込まれてしまうと危ない FirewallでAPIサーバへのアクセスについてIP制限を付与するいざ、シークレットが漏れた場合でも、APIサーバにアクセスされてしまわないように、ファイアウォールでIP制限をかけておくと良い NetworkPolicyでDBへの接続が許可されるPodを制限する大体の場合、重要なデータはDBに有るため、DBへのアクセスを絞ることで安全性を上げる example: kind: NetworkPolicy apiVersion: netwo
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く