为什么即使我没有访问权限,我的PodSecurityPolicy也会被应用? [英] Why is my PodSecurityPolicy applied even if I don't have access?

查看:271
本文介绍了为什么即使我没有访问权限,我的PodSecurityPolicy也会被应用?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有两个PodSecurityPolicy:

I have two PodSecurityPolicy:

  • 000特权(仅kube系统服务帐户和管理员用户)
  • 100个限制(其他所有条件)

我对他们分配到吊舱有疑问.

I have a problem with their assignment to pods.

第一个策略绑定:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: psp:privileged
rules:
- apiGroups:
  - extensions
  resources:
  - podsecuritypolicies
  resourceNames:
  - 000-privileged
  verbs:
  - use
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: psp:privileged-kube-system
  namespace: kube-system
subjects:
- kind: Group
  name: system:serviceaccounts
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: psp:privileged
  apiGroup: rbac.authorization.k8s.io

第二个策略绑定:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: psp:restricted
rules:
- apiGroups:
  - extensions
  resources:
  - podsecuritypolicies
  resourceNames:
  - 100-restricted
  verbs:
  - use
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: psp:restricted
subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: system:serviceaccounts
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: psp:restricted
  apiGroup: rbac.authorization.k8s.io

在kube系统中一切正常.

Everything works fine in kube-system.

但是,在其他命名空间中,它不能按预期方式工作:

However, in other namespaces, it does not work as expected:

  • 如果我创建一个Deployment(kubectl apply -f deployment.yml),则其pod会被标记为psp 100-restricted.

  • If I create a Deployment (kubectl apply -f deployment.yml), its pod gets tagged with psp 100-restricted.

如果我创建一个Pod(kubectl apply -f pod.yml),它将被标记为psp 000-privileged. 我真的不明白为什么它没有100个限制.

If I create a Pod (kubectl apply -f pod.yml), it gets tagged with psp 000-privileged. I really don't get why its not 100-restricted.

我的kubectl配置有来自OpenID Connect(OIDC)的外部身份验证令牌.

My kubectl is configured with external authentication token from OpenID Connect (OIDC).

我验证了访问权限,一切似乎都很好:

I verified the access and everything seems ok:

kubectl auth can-i use psp/100-restricted
yes
kubectl auth can-i use psp/000-privileged
no

有任何线索吗?

推荐答案

问题是我的用户可以访问其角色.

The problem was that my user had access to all verbs (*) of all resources (*) of the 'extensions' apiGroup in its Role.

文档有点不清楚( https://github. com/kubernetes/examples/tree/master/staging/podsecuritypolicy/rbac ):

use动词是一个特殊动词,它授予对使用策略的访问权限,但不允许任何其他访问.请注意,在名称空间内具有超级用户权限(访问*资源上的*动词)的用户将被允许使用该名称空间内的任何PodSecurityPolicy.

The use verb is a special verb that grants access to use a policy while not permitting any other access. Note that a user with superuser permissions within a namespace (access to * verbs on * resources) would be allowed to use any PodSecurityPolicy within that namespace.

我对提到该命名空间中的感到困惑.由于PodSecurityGroup不是命名空间",因此我假设没有命名空间中的ClusterRole/RoleBinding提供显式访问,就无法使用它们.似乎我错了...

I got confused by the mention of 'within that namespace'. Since PodSecurityGroup are not "namespaced", I assumed they could not be used without a ClusterRole/RoleBinding in the namespace giving explicit access. Seems I was wrong...

我修改了角色以指定以下内容:

I modified my role to specify the following:

rules:
- apiGroups: ["", "apps", "autoscaling", "batch"]
  resources: ["*"]
  verbs: ["*"]
- apiGroups: ["extensions"]
  resources: ["*"]
  # Avoid using * here to prevent use of 'use' verb for podsecuritypolicies resource
  verbs: ["create", "get", "watch", "list", "patch", "delete", "deletecollection", "update"]

现在,它会选择适当的PSP.一件有趣的事情是,它还阻止用户修改(创建/删除/更新/等)podsecuritypolicy.

And now it picks up the proper PSP. One interesting thing, it also prevent users from modifying (create/delete/update/etc) podsecuritypolicies.

使用"动词似乎毕竟很特别.....

It seems 'use' verb is quite special after all.....

这篇关于为什么即使我没有访问权限,我的PodSecurityPolicy也会被应用?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆