私は以下を持っています:
apiVersion: v1
kind: ServiceAccount
metadata:
name: SomeServiceAccount
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: SomeClusterRole
rules:
- apiGroups:
- "myapi.com"
resources:
- 'myapi-resources'
verbs:
- '*'
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: SomeClusterRoleBinding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: SomeClusterRole
subjects:
- kind: ServiceAccount
name: SomeServiceAccount
しかし、それはスローします:The ClusterRoleBinding "SomeClusterRoleBinding" is invalid: subjects[0].namespace: Required value
"Cluster"RoleBinding
は、単一の名前空間に限定されないことです。誰でもこれを説明できますか?
Kubernetesバージョン1.13.12
Kubectlバージョンv1.16.2
ありがとうございます。
ClusterRoleのクラスター全体の側面は、ルール内のリソースがクラスター全体であることです。たとえば、ClusterRoleを使用して、サブジェクトがすべての名前空間のすべてのポッドにアクセスできるようにすることができます。 Roleを使用すると、特定の名前空間のポッドへのアクセス権をサブジェクトにのみ与えることができます。
ClusterRoleBindingのクラスター全体の側面は、バインディングのサブジェクトにはまったく適用されません。この例では、すべての名前空間で特定の名前を持つすべてのサービスアカウントのバインディングを作成することはできません。
Kubernetesサービスアカウントのスコープは名前空間です。サービスアカウントの作成時に名前空間を指定しない場合、サービスアカウントは「デフォルト」の名前空間に作成されます。
これにより、異なる名前空間で同じ名前のサービスアカウントを作成できます。つまり、名前空間が作成されると、すべての名前空間に「default」という名前のサービスアカウントがあります。
名前空間にサービスアカウントを作成するには:
kubectl create serviceaccount my-sa -n my-namespace
ここでサブジェクトに入力する必要がある名前空間は、「サービスアカウントの場所」を指し、「このクラスターの役割のバインディングがリソースアクセスをバインドする名前空間」ではありません。
確かに、あなたの言う通り、ClusterRoleBindingは名前空間に関連付ける必要はありませんが、Subjectは関連付けられているかどうかにかかわらず、エラーが発生する可能性があります。これをデバッグするには、特定のバージョンのKubernetes API仕様を確認します。
たとえば here は、サブジェクトの名前空間で次のように述べています:If the object kind is non-namespace, such as "User" or "Group", and this value is not empty the Authorizer should report an error.