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.

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.

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
  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:
  3. Name: multi-env-demo-with-service-account
  4. Namespace: demo-service
  5. Created at: 2022-05-31 17:58:14 +0800 CST
  6. Status: running
  7. Workflow:
  8. mode: StepByStep
  9. finished: true
  10. Suspend: false
  11. Terminated: false
  12. Steps
  13. - id:ut3bxuisoy
  14. name:deploy-prod-server
  15. type:deploy2env
  16. phase:succeeded
  17. message:
  18. Services:
  19. - Name: nginx-server
  20. Cluster: local Namespace: demo-service-prod
  21. Type: webservice
  22. Healthy Ready:1/1
  23. 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")]

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.

Last updated on 2023年8月4日 by Daniel Higuero