第14章. Kubernetesの役割ベースのアクセス制御
この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている:translation-feedback@oreilly.com
この時点で、あなたが遭遇するほぼすべてのKubernetesクラスタは、ロールベースのアクセス制御(RBAC)が有効になっている。そのため、以前にもRBACに遭遇したことがあるだろう。おそらく、ユーザをロールにマッピングするためにRoleBindingを追加する魔法のようなコマンドを使うまで、初期状態ではクラスタにアクセスできなかっただろう。RBACに触れたことはあっても、KubernetesのRBACについて、それが何のためにあるのか、どのように使うのかなど、あまり理解した経験がないかもしれない。
ロールベースのアクセス制御は、Kubernetes APIへのアクセスとKubernetes APIに対するアクションの両方を制限し、許可されたユーザのみがアクセスできるようにするメカニズムを提供する。RBACは、アプリケーションをデプロイするKubernetesクラスタへのアクセスを強固にすると同時に、(おそらくもっと重要なことだが)間違ったネームスペースにいる1人が、テストクラスタを破壊しているつもりが誤って本番環境をダウンさせてしまうという、予期せぬ事故を防ぐためにも重要なコンポーネントだ。
注
RBACはKubernetes APIへのアクセスを制限する上で非常に有用だが、Kubernetesクラスタ内部で任意のコードを実行できる人なら誰でも、クラスタ全体のroot権限を事実上取得できることを覚えておくことが重要だ。そのような攻撃をより難しく、より高価にするために取れるアプローチがあり、正しいRBACの設定はこの防御の一部だ。しかし、敵対的なマルチテナントのセキュリティに重点を置くのであれば、RBAC単体で十分に防御できる。効果的なマルチテナント・セキュリティを提供するには、クラスタ内で実行されているPodを分離する必要がある。一般的には、ハイパーバイザで隔離されたコンテナやコンテナ・サンドボックスを使用してこれを行う。
KubernetesにおけるRBACの詳細に飛び込む前に、概念としてのRBACと、より一般化された認証認可について高レベルで理解しておくことは価値がある。
Kubernetesへのリクエストはすべて、まず認証される。認証は、リクエストを発行する呼び出し元のアイデンティティを提供する。リクエストが未認証であるという単純なものから、プラグイン可能な認証プロバイダ(Azure Active Directoryなど)と深く統合して、そのサードパーティシステム内でIDを確立するものまである。興味深いことに、Kubernetesは組み込みのIDストアを持たず、代わりに他のIDソースをKubernetes内で統合することに注力している。
ユーザが認証されると、認可フェーズでは、そのユーザがリクエストの実行を 許可されているかどうかを決定する。 認可は、ユーザのアイデンティティ、リソース(事実上HTTPパス)、および ユーザが実行しようとしている動詞またはアクションの組み合わせである。特定のユーザがそのリソース上でそのアクションを実行することを許可されている場合、リクエストの続行が許可される。そうでなければ、HTTP 403エラーが返される。このプロセスに飛び込もう。
役割ベースのアクセス制御
Kubernetesでアクセスを適切に管理するには、ID、ロール、ロールバインディングがどのように相互作用して、誰がどのリソースで何をできるかを制御するかを理解することが重要だ。最初のうちは、RBACを理解するのは一連の相互に関連した抽象化された概念で難しいように思えるかもしれない。 ...