Kuberentes RBAC 规则允许仅从 CronJob 创建作业

发布于 2025-01-10 08:34:23 字数 354 浏览 0 评论 0原文

是否可以创建一个 kubernetes RBAC 规则,允许从现有 CronJob 创建作业,但阻止以其他方式创建作业?

我们希望严格锁定我们的集群,以避免不受 CICD 管理的任意部署 - 但我们还需要促进 CronJobs 的手动测试,或者不按计划重新运行失败的作业。我希望开发人员能够运行以下命令:

kubectl create job --from=cronjob/my-job my-job-test-run-1

但不能运行以下命令:

kubectl create job my-evil-job -f evil-job.yaml

这可能吗?

Is it possible to create a kubernetes RBAC rule that allows creating a Job from an existing CronJob, but prevents creating a Job any other way?

We want to keep our clusters tightly locked down to avoid arbitrary deployments not managed by CICD - but we also need to facilitate manual testing of CronJobs, or rerunning failed jobs off schedule. I'd like developers to be able to run a command like:

kubectl create job --from=cronjob/my-job my-job-test-run-1

But not be able to run something like:

kubectl create job my-evil-job -f evil-job.yaml

Is that possible?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

梦断已成空 2025-01-17 08:34:23

在这种情况下,为了成功执行此命令:

kubectl create job --from=cronjob/<cronjob_name>  

User/ServiceAccount 应该具有正确的 RBAC 规则(下面提供的输出中至少有两条,创建 Jobs 并获取 CronJobs

在第一个示例中,我授予了创建 Jobs 的访问权限代码>并获取 CronJobs 并且我能够创建 JobJob --from CronJob

user@minikube:~$ cat test_role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: job
rules:
- apiGroups: ["batch"]
  resources: ["jobs"]
  verbs: ["create"]
- apiGroups: ["batch"]
  resources: ["cronjobs"]
  verbs: ["get"]
user@minikube:~$ kubectl create job --image=inginx testjob20
job.batch/testjob20 created
user@minikube:~$ kubectl create job --from=cronjobs/hello testjob21
job.batch/testjob21 created

但如果我仅授予访问权限来创建 Job< /code> 没有 get CronJob,我能够创建 Job 但不能创建 Job --from CronJob

user@minikube:~$ cat test_role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: job
rules:
- apiGroups: ["batch"]
  resources: ["jobs"]
  verbs: ["create"]
user@minikube:~$ kubectl create job --image=nginx testjob3
job.batch/testjob3 created
user@minikube:~$ kubectl create job --from=cronjobs/hello testjob4
Error from server (Forbidden): cronjobs.batch "hello" is forbidden: User "system:serviceaccount:default:t1" cannot get resource "cronjobs" in API group "batch" in the namespace "default"

当我删除创建的访问权限时乔布斯,我无法创建 Job 以及 Job --from CronJob

user@minikube:~$ cat test_role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: job
rules:
- apiGroups: ["batch"]
  resources: ["cronjobs"]
  verbs: ["get"]
user@minikube:~$ kubectl create job --image=inginx testjob10
error: failed to create job: jobs.batch is forbidden: User "system:serviceaccount:default:t1" cannot create resource "jobs" in API group "batch" in the namespace "default"  
user@minikube:~$ kubectl create job --from=cronjobs/hello testjob11
error: failed to create job: jobs.batch is forbidden: User "system:serviceaccount:default:t1" cannot create resource "jobs" in API group "batch" in the namespace "default"

如您所见,如果 User/ServiceAccount 在这种情况下没有这两种权限,则无法创建(JobJob --from CronJob),因此不可能仅使用 RABC 规则来创建此类限制。

一种可能的解决方案是将此权限拆分为两个不同的 User/ServiceAccount 来执行两个不同的任务(第一个用户可以创建 Jobs + 获取 CronJobs,第二个用户没有权限创建 >工作)。

另一种可能性是尝试将 k8s 准入控制器与 fe 开放策略代理一起使用

In this scenario in order to successfully execute this command:

kubectl create job --from=cronjob/<cronjob_name>  

User/ServiceAccount should have proper RBAC rules (at least two from the output provided below, create Jobs and get CronJobs.

In first example I granted access to create Jobs and get CronJobs and I was able to create Job and Job --from CronJob

user@minikube:~$ cat test_role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: job
rules:
- apiGroups: ["batch"]
  resources: ["jobs"]
  verbs: ["create"]
- apiGroups: ["batch"]
  resources: ["cronjobs"]
  verbs: ["get"]
user@minikube:~$ kubectl create job --image=inginx testjob20
job.batch/testjob20 created
user@minikube:~$ kubectl create job --from=cronjobs/hello testjob21
job.batch/testjob21 created

But if I granted access only to create Job without get CronJob, I was be able to create Job but not to create Job --from CronJob

user@minikube:~$ cat test_role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: job
rules:
- apiGroups: ["batch"]
  resources: ["jobs"]
  verbs: ["create"]
user@minikube:~$ kubectl create job --image=nginx testjob3
job.batch/testjob3 created
user@minikube:~$ kubectl create job --from=cronjobs/hello testjob4
Error from server (Forbidden): cronjobs.batch "hello" is forbidden: User "system:serviceaccount:default:t1" cannot get resource "cronjobs" in API group "batch" in the namespace "default"

When I deleted access to create Jobs, I couldn't create Job and also Job --from CronJob

user@minikube:~$ cat test_role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: job
rules:
- apiGroups: ["batch"]
  resources: ["cronjobs"]
  verbs: ["get"]
user@minikube:~$ kubectl create job --image=inginx testjob10
error: failed to create job: jobs.batch is forbidden: User "system:serviceaccount:default:t1" cannot create resource "jobs" in API group "batch" in the namespace "default"  
user@minikube:~$ kubectl create job --from=cronjobs/hello testjob11
error: failed to create job: jobs.batch is forbidden: User "system:serviceaccount:default:t1" cannot create resource "jobs" in API group "batch" in the namespace "default"

As you can see if User/ServiceAccount doesn't have both permission in this scenario it's impossible to create (Job or Job --from CronJob) so it's impossible to create such restrictions using only RABC rules.

One possible solution is to split this permission into two different User/ServiceAccount for two different tasks (first user can create Jobs + get CronJobs, second user without permission to create Jobs).

Another possibility is to try to use k8s admission Controller with f.e. Open Policy agent

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文