☰

セレクターを満たすオブジェクトにロールを制限できますか?

tag-icon • tag-icon kubernetes authorization
セレクターを満たすオブジェクトにロールを制限できますか?

特定の名前空間内で特定のラベルを持つオブジェクトのみを作成、一覧表示、削除などできるようにサービス アカウントを制限するにはどうすればよいですか?

私たちは、サービス (Kubernetes 名前空間にマップ) とコンポーネント (personaさまざまなオブジェクトのラベルで表されます) の階層を設計し、アクセスできるシークレットがサービスとコンポーネントのペアに固有になるように Vault と統合しました。これにより、物事を分離できます。たとえば、多数のデプロイメントを管理するチームがあり、そのうちの一部だけが PII データを処理するとします。そのラベルを使用して、それらのシークレットへのアクセスを選択的に許可できます。

# only approximatively k8s objects
---
kind: Deployment
metadata:
  name: backend
  namespace: banana
  labels:
    persona: backend
spec: ...
# pods in this deployment have access to banana§backend secrets via a vault sidecar
---
kind: Deployment
metadata:
  name: frontend
  labels:
    persona: frontend
spec: ...
# pods in this deployment have access to banana§frontend secrets via a vault sidecar

しかし、それは単に管理できるサービスアカウントを作成するのではなく、全てその名前空間内のポッド — そのサービス アカウントのシークレットが漏洩した場合、攻撃者はそれを利用して悪意のあるイメージを含むポッドを起動し、個人情報 (PII) にアクセスできるようになります。

したがって、次のようなものを用意したいと思います (サービス アカウント、ロール、ロール バインディングに関する私の知識は非常に限られていることに注意してください)

# even more approximatively so k8s objects
kind: Role
metadata:
  name: deploy-frontend
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
  selector:
    labels:
      persona: frontend
# even if compromised, this service account cannot access banana§backend secrets

k8sのようですかもしれないこれに似たものをサポートするには、例えば特定のリソース名のリストを提供するなどします（#) ですが、これは現時点では k8s がサポートしていないものなのでしょうか? それとも何か見落としているのでしょうか?

唯一の選択肢は、すべてに幅広くアクセスできるクラスター全体のサービス アカウントを設定し、トークンが使用される前に独自のカスタム認証および承認ルーチンを実行する Web サービスを起動することでしょうか。もしそうなら、この「god アカウント」の範囲を可能な限り制限するにはどうすればよいでしょうか。

答え1

Kubernetesには制限する方法がありませんリストオブジェクトごとに動詞。コレクションを一覧表示できる場合は、そのコレクション内のすべてのオブジェクトを読み取ることができます。

いつか状況が変わるかもしれませんが、現時点では、Kubernetes はコレクションと読み取りアクセスに関してこのように動作します。これには、Secret への読み取りアクセスも含まれます...

ただし、制限したい場合は書くオブジェクトに対しては、それが可能です。次の方法を使用して、特定の名前付きオブジェクトへの書き込み機能を制限できます。

  • 外部の承認用入場ウェブフック
  • (ベータ) ValidatingAdmissionPolicy
  • 認証ウェブフック

または、慎重に作成された RBAC ルールを使用します。

アクセス管理に役立つかもしれないのは階層型名前空間コントローラチームが管理できるようにし、セットそれぞれ独自の制限を持つ名前空間があります。クラスターが ValidatingAdmissionPolicies をサポートしている場合は、それらを使用して、委任されたアクセスと書き込みアクセスの制限をさらに強化できます (ただし、これはかなり複雑なトピックです)。

1 つの ServiceAccount でさまざまな操作を実行できるが、それらの操作の制御を委任したい場合は、各ターゲット名前空間に RoleBinding を使用して ServiceAccount を作成し、ServiceAccount 全体が特定の ServiceAccount を偽装できるようにします。これも、説明するのがかなり複雑なことですが、可能です。

関連情報