Question

我有2个团队：

devs：每次部署应用程序的分支/标签时，它们都会创建一个新的Kubernetes命名空间
ops：他们使用（群集）角色和（群集）角色绑定管理对群集的访问控制

问题在于，在“ ops”创建RBAC资源之前，“ devs”无法kubectl其名称空间。而且'devs'本身无法创建RBAC资源，因为它们没有要放入角色绑定资源中的主题列表（共享列表不是一种选择）。

我已经阅读了有关Admission webhooks的官方文档，但据我了解，它们仅对触发Webhook的资源起作用。

在创建新名称空间时，Kubernetes中是否存在本机和/或简单的方法来应用资源？

Answer 1

我通过编写自定义控制器提出了一个解决方案。

部署了以下自定义资源后，控制器会将role和rolebinding注入与dev-.*和fix-.*匹配的命名空间中：

kind: NamespaceResourcesInjector
apiVersion: blakelead.com/v1alpha1
metadata:
  name: nri-test
spec:
  namespaces:
  - dev-.*
  - fix-.*
  resources:
  - |
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: dev-role
    rules:
      - apiGroups: [""]
        resources: ["pods","pods/portforward", "services", "deployments", "ingresses"]
        verbs: ["list", "get"]
      - apiGroups: [""]
        resources: ["pods/portforward"]
        verbs: ["create"]
      - apiGroups: [""]
        resources: ["namespaces"]
        verbs: ["list", "get"]
  - |
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: dev-rolebinding
    subjects:
    - kind: User
      name: dev
    roleRef:
      kind: Role
      name: dev-role
      apiGroup: rbac.authorization.k8s.io

该控制器仍处于开发的早期阶段，但我正在越来越多的集群中成功使用它。

这里是那些有兴趣的人：https://github.com/blakelead/nsinjector

Answer 2

是的，有一种本机方式，但没有开箱即用的功能。

您可以通过使用/创建operator来完成您描述的操作。本质上可以扩展您的Kubernetes API。

由于运算符只是一个开放的模式，可以通过多种方式实现事物，在这种情况下，您给出了一种控制流的样子：

具有创建RBAC特权的操作员已部署并预订对k8s名称空间对象种类的更改
开发人员创建包含约定标签的名称空间
通知操作员有关集群的更改
操作员检查名称空间验证（也可以通过单独的接纳网络钩子来完成）
操作员在新创建的名称空间中创建RBAC
如果RBAC是集群范围的，则删除命名空间后，同一运营商可以执行RBAC清理

Answer 3

这与用户如何向集群进行身份验证以及如何获取kubeconfig文件有关。您可以将组放入kubectl从kubeconfig中使用的客户端证书或承载令牌中。事先，您可以定义一个具有与该组绑定的clusterrole的clusterrole，从而赋予他们对某些资源上的某些动词的权限（例如创建名称空间的能力）

此外，您可以使用准入网络挂钩来验证用户是否应该属于该组。

创建名称空间后自动创建Kubernetes资源

3 个答案: