Skip to main content
Version: Next

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.

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.

apiVersion: v1
kind: ServiceAccount
metadata:
name: deployer
namespace: demo-service

Creating Role/RoleBinding#

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

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: deployments:admin
namespace: demo-service-prod
rules:
- apiGroups: ["apps"]
resources: ["deployments"]
verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: deployments:admin
namespace: demo-service-prod
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: deployments:admin
subjects:
- kind: ServiceAccount
name: deployer
namespace: demo-service

Deploying an Application with ServiceAccount#

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: multi-env-demo-with-service-account
namespace: demo-service
annotations:
app.oam.dev/service-account-name: deployer # the name of the ServiceAccount we created
spec:
components:
- name: nginx-server
type: webservice
properties:
image: nginx:1.21
port: 80
policies:
- name: env
type: env-binding
properties:
created: false
envs:
- name: prod
patch:
components:
- name: nginx-server
type: webservice
properties:
image: nginx:1.20
port: 80
placement:
namespaceSelector:
name: demo-service-prod
workflow:
steps:
- name: deploy-prod-server
type: deploy2env
properties:
policy: env
env: prod

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

NAME COMPONENT TYPE PHASE HEALTHY STATUS AGE
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.

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

Limitations#

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 by Jianbo Sun