版本：v1.3

ServiceAccount Integration for RBAC

KubeVela applies Components and runs Workflow with the controller service account, which allows you to manage components across namespaces.

However, in the soft-multitenancy environments, such as Namespaces as a Service, you may need to limit Applications to allow applying components or running workflows in the authorized namespaces only.

You can limit by setting app.oam.dev/service-account-name annotation with the specific ServiceAccount name. If defined, KubeVela will use the given ServiceAccount instead of the controller ServiceAccount when applying Components and running Workflow.

Let’s assume that we have two namespaces:

  • demo-service: for managing application
  • demo-service-prod: to deploy components for the production environment

In this example, we will make the Application use a specific ServiceAccount instead of the controller ServiceAccount.

Create deployer ServiceAccount in demo-service namespace.

  1. apiVersion: v1
  2. kind: ServiceAccount
  3. metadata:
  4.   name: deployer
  5.   namespace: demo-service

Allow deployer ServiceAccount in demo-service to manage Deployments in demo-service-prod by creating Role/RoleBinding.

  1. apiVersion: rbac.authorization.k8s.io/v1
  2. kind: Role
  3. metadata:
  4.   name: deployments:admin
  5.   namespace: demo-service-prod
  6. rules:
  7.   - apiGroups: ["apps"]
  8.     resources: ["deployments"]
  9.     verbs: ["*"]
  10. ---
  11. apiVersion: rbac.authorization.k8s.io/v1
  12. kind: RoleBinding
  13. metadata:
  14.   name: deployments:admin
  15.   namespace: demo-service-prod
  16. roleRef:
  17.   apiGroup: rbac.authorization.k8s.io
  18.   kind: Role
  19.   name: deployments:admin
  20. subjects:
  21.   - kind: ServiceAccount
  22.     name: deployer
  23.     namespace: demo-service
  1. apiVersion: core.oam.dev/v1beta1
  2. kind: Application
  3. metadata:
  4.   name: multi-env-demo-with-service-account
  5.   namespace: demo-service
  6.   annotations:
  7.     app.oam.dev/service-account-name: deployer # the name of the ServiceAccount we created
  8. spec:
  9.   components:
  10.     - name: nginx-server
  11.       type: webservice
  12.       properties:
  13.         image: nginx:1.21
  14.         port: 80
  15.   policies:
  16.     - name: env
  17.       type: env-binding
  18.       properties:
  19.         created: false
  20.         envs:
  21.           - name: prod
  22.             patch:
  23.               components:
  24.                 - name: nginx-server
  25.                   type: webservice
  26.                   properties:
  27.                     image: nginx:1.20
  28.                     port: 80
  29.             placement:
  30.               namespaceSelector:
  31.                 name: demo-service-prod
  32.   workflow:
  33.     steps:
  34.       - name: deploy-prod-server
  35.         type: deploy2env
  36.         properties:
  37.           policy: env
  38.           env: prod

After deploying the Application, you can check the Application is deployed successfully.

  1. NAME                                  COMPONENT      TYPE         PHASE              HEALTHY   STATUS      AGE
  2. multi-env-demo-with-service-account   nginx-server   webservice   workflowFinished   true      Ready:1/1   18s

If you set non-authorized ServiceAccount to the annotation, you can find an error message like below in the Application status.

  1. Dispatch: Found 1 errors. [(cannot get object: deployments.apps "nginx-server" is forbidden: User "system:serviceaccount:demo-service:non-authorized-account" cannot get resource "deployments" in API group "apps" in the namespace "demo-service-prod")]

ServiceAccount Integration doesn’t support Multi-Cluster Application Delivery. Even if you set ServiceAccount name to the annotation, KubeVela will ignore it if the scope is a non-local cluster.

You can follow up about this issue on GitHub.

Last updated on 2022年11月1日 by Tianxin Dong