Systems Integration

KubeVela application natively supports impersonation even without the Authentication flag enabled. That means when the Authentication flag is disabled, you can manually set the identity to impersonate in the application’s annotation fields. For example, the following guide will give an example on how to manually set the application to impersonate as a ServiceAccount.

Example

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.

Creating ServiceAccount

Create deployer ServiceAccount in demo-service namespace.

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

Creating Role/RoleBinding

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

Notice that KubeVela application requires the identity to impersonate to have the privileges for writing ControllerRevision. If you use --optimize-disable-component-revision in the KubeVela controller, you can ignore this requirement.

  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

Deploying an Application with ServiceAccount

  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. $ vela status multi-env-demo-with-service-account -n demo-service     
  2. About:
  4.   Name:         multi-env-demo-with-service-account
  5.   Namespace:    demo-service                       
  6.   Created at:   2022-05-31 17:58:14 +0800 CST      
  7.   Status:       running                            
  9. Workflow:
  11.   mode: StepByStep
  12.   finished: true
  13.   Suspend: false
  14.   Terminated: false
  15.   Steps
  16.   - id:ut3bxuisoy
  17.     name:deploy-prod-server
  18.     type:deploy2env
  19.     phase:succeeded 
  20.     message:
  22. Services:
  24.   - Name: nginx-server  
  25.     Cluster: local  Namespace: demo-service-prod
  26.     Type: webservice
  27.     Healthy Ready:1/1
  28.     No trait applied

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")]

Impersonate as User/Groups

If you would like to let the application to impersonate as specific user and group, you can set the annotation app.oam.dev/username and app.oam.dev/group in the application respectively.