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

Automatically create Kubernetes resources after namespace creation

我有 2 个团队:

问题是 'devs' 在 'ops' 创建 RBAC 资源之前无法 kubectl 其命名空间。并且 'devs' 无法自行创建 RBAC 资源,因为它们没有要放入角色绑定资源的主题列表(共享列表不是一种选择)。

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

Kubernetes 中是否有原生的 and/or 简单方法来在创建新命名空间时应用资源?

这与用户如何向集群进行身份验证以及他们如何获得 kubeconfig 有关 file.You 可以将组放入客户端证书或 kubectl 从 kubeconfig 使用的持有者令牌。您可以提前定义一个 clusterrole,该 clusterrole 具有与该组的 clusterrole 绑定,这使他们能够访问某些资源上的某些动词(例如创建命名空间的能力)

此外,您可以使用 admission webhook 来验证用户是否应该属于该组。

是的,有原生方式,但没有开箱即用的功能。

您可以按照 using/creating 和 operator 所描述的进行操作。本质上是根据您的需要扩展 Kubernetes API。

由于运算符只是一种开放模式,可以通过多种方式实现事物,在您提供一种方式的场景中,控制流可能如下所示:

  1. 具有创建 RBAC 权限的操作员已部署并订阅了对 k8s 命名空间对象种类的更改
  2. 开发者创建包含约定标签的命名空间
  3. 操作员收到有关集群更改的通知
  4. 操作员检查命名空间验证(这也可以通过单独的准入网络钩子来完成)
  5. 运算符在新创建的命名空间中创建 RBAC
  6. 如果 RBAC 是集群范围的,则同一操作员可以在删除命名空间后执行 RBAC 清理

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

部署了以下自定义资源后,控制器将 rolerolebinding 注入匹配 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