Kubernetes RBACを可能な限り許容度の低い方法で構成しようとしていますが、ロールを特定のリソースとサブリソースにスコープしたいです。ドキュメントを掘り下げましたが、リソースとそのサブリソースの簡潔なリストが見つかりません。
特に、展開の仕様の一部を管理するサブリソースであるコンテナイメージに興味があります。
kubectl api-resources -o wide
を使用すると、すべてのressources、verbs、および関連するAPI-groupが表示されます。
$ kubectl api-resources -o wide
NAME SHORTNAMES APIGROUP NAMESPACED KIND VERBS
bindings true Binding [create]
componentstatuses cs false ComponentStatus [get list]
configmaps cm true ConfigMap [create delete deletecollection get list patch update watch]
endpoints ep true Endpoints [create delete deletecollection get list patch update watch]
events ev true Event [create delete deletecollection get list patch update watch]
limitranges limits true LimitRange [create delete deletecollection get list patch update watch]
namespaces ns false Namespace [create delete get list patch update watch]
nodes no false Node [create delete deletecollection get list patch update watch]
persistentvolumeclaims pvc true PersistentVolumeClaim [create delete deletecollection get list patch update watch]
persistentvolumes pv false PersistentVolume [create delete deletecollection get list patch update watch]
pods po true Pod [create delete deletecollection get list patch update watch]
statefulsets sts apps true StatefulSet [create delete deletecollection get list patch update watch]
meshpolicies authentication.istio.io false MeshPolicy [delete deletecollection get list patch create update watch]
policies authentication.istio.io true Policy [delete deletecollection get list patch create update watch]
...
...
これを使用して、RBAC構成に必要なリソースのリストを作成できると思います
RBACロールを定義するために必要なリソース、サブリソース、および動詞は、静的リストのどこにも記載されていません。それらは、ディスカバリドキュメントで利用できます。つまり、APIを介して、たとえば/api/apps/v1
。
次のbashスクリプトは、すべてのリソース、サブリソース、および動詞を次の形式でリストします。
api_version resource: [verb]
ここで、api-version
はコアリソースのcore
であり、ロール定義で""
(空の引用符付き文字列)に置き換える必要があります。
たとえば、core pods/status: get patch update
。
スクリプトには jq が必要です。
#!/bin/bash
SERVER="localhost:8080"
APIS=$(curl -s $SERVER/apis | jq -r '[.groups | .[].name] | join(" ")')
# do core resources first, which are at a separate api location
api="core"
curl -s $SERVER/api/v1 | jq -r --arg api "$api" '.resources | .[] | "\($api) \(.name): \(.verbs | join(" "))"'
# now do non-core resources
for api in $APIS; do
version=$(curl -s $SERVER/apis/$api | jq -r '.preferredVersion.version')
curl -s $SERVER/apis/$api/$version | jq -r --arg api "$api" '.resources | .[]? | "\($api) \(.name): \(.verbs | join(" "))"'
done
警告:API経由で動詞がリストされていない場合、出力にはAPIバージョンとリソースが表示されるだけです。
core pods/exec:
次のリソースの特定のインスタンスでは、APIを介して動詞が表示されませんが、これは間違っています(Kubernetesのバグ #65421 、 #65518 で修正):
nodes/proxy
pods/attach
pods/exec
pods/portforward
pods/proxy
services/proxy
これらのリソースでサポートされている動詞は次のとおりです。
nodes/proxy: create delete get patch update
pods/attach: create get
pods/exec: create get
pods/portforward: create get
pods/proxy: create delete get patch update
services/proxy: create delete get patch update
警告2:Kubernetesは、ここにリストされていない特殊な動詞を使用して、追加の許可をチェックする場合があります。たとえば、rbac.authorization.k8s.io
APIグループのbind
およびroles
リソースには、clusterroles
動詞が必要です。これらの特殊な動詞の詳細は docs here にあります。
Kubernetes v1.9のリソースリストは、ここから入手できます。 https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.9/#-strong-api-overview-strong- 。他のK8sバージョンについては、 https://kubernetes.io/docs/reference/ の「APIリファレンス」セクションを確認してください。
左側のカタログを確認します。たとえば、「ワークロード」は、コンテナ、展開、CronJobなどの基本的なリソースの概要です。また、「コンテナ、展開、CronJob」などのこれらのサブリソースは、一般的なKubernetes APIリソース。
これらの基本リソースにはkubectlを介してアクセスできます。したがって、 https://kubernetes.io/docs/reference/kubectl/cheatsheet/ で利用可能な「リソースタイプ」のリストもあります。
しかし、「展開の仕様の一部を管理するサブリソース-コンテナイメージ」というステートメントで混乱しています。コンテナイメージの権限を管理する場合は、イメージレジストリで行う必要がありますが、 Kubernetes側ではありません。たとえば、レジストリには、ユーザーが画像をプルするときに認証を行うアクセスコントローラーが必要です。
for kind in `kubectl api-resources | tail +2 | awk '{ print $1 }' | sort`; do kubectl explain $kind ; done | grep -e "KIND:" -e "VERSION:" | awk '{print $2}' | paste -sd' \n'
これを「回答」とすることもheしますが、コメントには長すぎます
リソースのリストについては、$HOME/.kube/cache/discovery
を知っていますか。SwaggerJSONファイルは、それらを囲むapiVersion
と一致するディレクトリによってディスクに永続化されます。 これは 私が見つけることができる最速のリンク(「CRDの発見と使用」の見出しを見てください)ですが、ls -la ~/.kube/cached/discovery
が意味を示しています。これらのSwagger JSONファイルは、apiVersion
内のすべての主要なプレーヤーを列挙し、APIリファレンスWebサイトよりもはるかにアクセスしやすいと感じています。
サブリソース定義が含まれているかどうかを知るためのファイルが目の前にないので、他の誰かがそれを検討することを願っています。
「重量を量る」部分のマイナーアスタリスクは、RBACのドキュメントと1.9 APIリファレンスで行ったサーフィンに基づいて、サブリソースがその親リソースへの「フィールドレベルアクセス」であるという印象を受けなかったことです。たとえば、 v1beta1/Evictions は/evictions
のPodサブリソースです。私の知る限り、PodSpec
内のフィールドではありません
したがって、RBACを使用して展開のイメージを制約することに興味がある場合は、 Webhookモード を使用すると、muchより幸せになります試行された要求にほぼ無制限のビジネスロジックが適用されています。