Skip to main content

Snyk @ Snyk:開発者がKubernetes RBACを活用できる環境を実現

2021年4月14日

0 分で読めます

ベンおじさんがかつて言ったように、「大いなる力には、大いなる責任が伴う」。これはKubernetes APIにも当てはまります。非常に強力で、その上に素晴らしいものを構築できますが、代償もあります。悪意のあるユーザーがAPIを悪用し、問題を引き起こす可能性もあるのです。

そこで役立つのがKubernetes RBAC(ロールベースのアクセス制御)です。最小権限の原則に従って必要な権限だけを付与することで、APIを適切に制御しながら利用できます。

クラスターのロール、ロールバインディング、名前空間、ユーザー、グループ、サービスアカウントを示すKubernetes RBACの図。

Kubernetesでは、ユーザーは名前空間内にロールを、名前空間の外にクラスターロールを定義できます。

しかし、これでは問題を別の場所に移しただけです。RBACリソースを適切に管理するプロセスがなければ、単純なRBACの設定ミスでも深刻なセキュリティ上の影響を招く可能性があります。たとえば、開発者が「うっかり」デフォルト名前空間のデフォルトサービスアカウントにクラスタ管理者ロールを付与してしまうケースです。なんと恐ろしいことでしょう!

防護服を着た消防士が、黒煙と炎に包まれた燃えているコンテナの近くに立っています。

写真提供:https://unsplash.com/@arnykoor

Kubernetesセキュリティの舗装された道

理想的には、すべての開発者が望むとおりにRBAC権限を作成できる一方で、安全でない設定を防ぐためのガードレールも整備したいところです。その方法の1つは、RBACリソースを含む変更すべてにAppSecのコードレビューを必須にすることです。これは有効かもしれませんが、いくつかの欠点があります。

  • AppSecがボトルネックとなり、開発者の作業が遅くなる。

  • レビュー時にAppSecが何を確認しているのか、公開されたガイドラインがないため、セキュリティがAppSecだけの知る「魔法」になってしまう。

  • サイロ化がさらに進み、開発者がセキュリティの責任を担えなくなります。その結果、AppSecがボトルネックとなって開発者の作業を遅らせる問題も、さらに深刻になります。

Kubernetes RBACセキュリティチェックリスト

Snykでも同様の課題に直面しました。開発者の作業を遅らせることなく、Kubernetes APIを利用できるようにしたいと考えたのです。そこでまず、RBACルールに関するセキュリティ要件をリストにまとめました。ルールは比較的簡潔で、主にCIS Kubernetesベンチマークに基づいています。

  • リソースや動詞にワイルドカードを使用しない

  • 組み込みルールを使用しない(権限が多すぎるため)

  • デフォルト名前空間(空であるべき)またはkube-system名前空間(機密性の高いワークロードを実行)内のサービスアカウントにバインドしない

  • デフォルトサービスアカウントにバインドしない

  • Podの作成やシークレットの読み取りなど、危険な権限を使用しない

リストができたら、次のことができます。

  • 社内ガイドラインとして公開し、すべてのRBACオブジェクトにこのリストを遵守させます。これで、判断基準が「魔法」ではなくなります。

  • 開発者とセキュリティエンジニアに、リストへの違反をセキュリティリスクとして記録し、AppSecに知らせるよう依頼します。

  • フィードバックを募り、すべての開発者にリストの改善への参加を促すことで、サイロを解消します。

  • 自動化です。リストができたら、テストを驚くほど簡単にしたいものです。

Snyk IaCでKubernetes設定チェックを自動化

2020年後半、Snykは新製品Snyk Infrastructure as Code(Snyk IaC)を発表しました。Snyk IaCには、Kubernetesマニフェスト(Terraformも対象ですが、それはまた別のブログで)などのIaCコードをテストするためのルールが組み込まれています。Snykで働く特典の1つは、あらゆる機能をいち早く利用できること、そしてさらにうれしいことに、製品の改善に貢献できることです。

そこでリストをまとめた後、Snyk IaCチームに連絡し、Kubernetes RBACチェックリストについて話し合いました。すると、Snyk IaCに5つの新しいチェック項目が追加され、セキュリティチェックを自動化し、AppSecがボトルネックにならないようにできました。

構成ファイルの検出が有効になっており、RoleとRoleBindingの問題に対するKubernetesの重大度設定が表示されたSnyk Infrastructure as Codeの設定。

Snykの開発者にとってIaCセキュリティを驚くほど簡単に

Snyk IaCはGitHub Actions経由でスキャンし、結果をSarif形式で出力できます。GitHub Securityとの統合も可能です。しかし、さらに一歩進めて、違反をPR上に直接表示したいと考えました。これはSnyk IaCではまだ対応していません。そこでAppSecチームが独自のGitHubインテグレーションを作成し、Kubernetesマニフェストファイルへの変更をコミット時にSnykで自動スキャンするようにしました。違反があれば、開発者にPR上でわかりやすい警告が表示されます。

RoleBindingがデフォルトのサービスアカウントを使用していることを示す警告が表示されたKubernetes YAMLのプルリクエスト。

これで、すべての開発者がAppSecの対応を待たずにRBACを変更できるようになりました。Snykが守ってくれているとわかり、AppSecも安心です。

チームでも同じようなことを実現したいですか?こちらのサンプルリポジトリをご覧ください。Snykアカウントを作成して、IaCを無料で始めましょう。

ソースコードの段階からインフラを保護

Snykはワークフロー内のIaCセキュリティとコンプライアンスを自動化し、構成ドリフトや不足しているリソースを検出します。

カテゴリー: