Using Existing ServiceAccounts

Point the connectware Helm chart at pre-provisioned ServiceAccounts instead of letting the chart create its own RBAC resources.

By default, the connectware Helm chart creates the ServiceAccounts, Roles, and RoleBindings that its workloads need. In environments with governed role-based access control (RBAC), you can point the chart at ServiceAccounts that your platform team has already provisioned.

When to Use This

Use this when your platform team owns RBAC. In governed environments, an application chart is often not permitted to create ServiceAccounts, Roles, and RoleBindings. Instead, the platform team reviews, approves, and provisions these resources, and you point the chart at the ServiceAccounts they provide.

This feature is opt-in and set per component. If you set no values, the chart continues to create and manage its own RBAC resources, so existing installations are unaffected. To hand RBAC to your platform team, set the values described in Configuration Values.

Configuration Values

Each value lets you supply an existing ServiceAccount for one component:

Value	Component
containerManager.existingServiceAccount	Container manager
broker.existingServiceAccount	Broker

Each value behaves the same way:

• Unset or empty (default): The chart creates the ServiceAccount, Role, and RoleBinding for the component, and the workload uses them.

• Set to a name: The chart does not render the ServiceAccount, Role, or RoleBinding for the component. Instead, it sets the workload's serviceAccountName to the name you provide.

The two values are independent. You can override one while letting the chart manage the other, or override both.

Reference Manifests

When you supply an existing ServiceAccount, your platform team must pre-provision an equivalent ServiceAccount, Role, and RoleBinding with the exact permissions the component requires. The RoleBinding must bind the supplied ServiceAccount to the corresponding Role, in the release namespace.

Use the following manifests as a starting point. Replace ${SERVICE_ACCOUNT_NAME} with the name you plan to pass to the Helm value, and ${NAMESPACE} with the namespace of your Connectware installation.

The ServiceAccount must exist before you deploy

If the referenced ServiceAccount does not exist when Connectware is deployed, the helm upgrade succeeds, but Kubernetes rejects creation of the workload's pods. No pods start, and an error event such as serviceaccount "<name>" not found appears on the affected Deployment or StatefulSet.

Make sure the ServiceAccount and its Role and RoleBinding exist before deploying.

Container Manager

The container manager requires get, list, and watch on pods and pods/log.

cm-role.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: ${SERVICE_ACCOUNT_NAME}
  namespace: ${NAMESPACE}
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: ${SERVICE_ACCOUNT_NAME}
  namespace: ${NAMESPACE}
rules:
  - apiGroups: ['']
    resources: ['pods', 'pods/log']
    verbs: ['get', 'list', 'watch']
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ${SERVICE_ACCOUNT_NAME}
  namespace: ${NAMESPACE}
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: ${SERVICE_ACCOUNT_NAME}
subjects:
  - kind: ServiceAccount
    name: ${SERVICE_ACCOUNT_NAME}
    namespace: ${NAMESPACE}

Broker

The broker requires get, list, and watch on pods and on statefulsets in the apps API group.

broker-role.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: ${SERVICE_ACCOUNT_NAME}
  namespace: ${NAMESPACE}
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: ${SERVICE_ACCOUNT_NAME}
  namespace: ${NAMESPACE}
rules:
  - apiGroups: ['']
    resources: ['pods']
    verbs: ['get', 'list', 'watch']
  - apiGroups: ['apps']
    resources: ['statefulsets']
    verbs: ['get', 'list', 'watch']
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ${SERVICE_ACCOUNT_NAME}
  namespace: ${NAMESPACE}
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: ${SERVICE_ACCOUNT_NAME}
subjects:
  - kind: ServiceAccount
    name: ${SERVICE_ACCOUNT_NAME}
    namespace: ${NAMESPACE}

Governed-Deployment Workflow

Follow these steps to deploy Connectware against pre-provisioned ServiceAccounts:

1. Have your platform team apply the manifests from Reference Manifests with the names and namespace agreed for your installation.

2. Set containerManager.existingServiceAccount and broker.existingServiceAccount to the ServiceAccount names your platform team provisioned:

values.yaml

containerManager:
  existingServiceAccount: connectware-container-manager
broker:
  existingServiceAccount: connectware-broker

• Replace connectware-container-manager with the name of the ServiceAccount your platform team provisioned for the container manager.

• Replace connectware-broker with the name of the ServiceAccount your platform team provisioned for the broker.

1. Install or upgrade Connectware with your updated values.yaml file.

Result

The chart skips creating RBAC resources for each component you overrode, and the corresponding workloads run under the ServiceAccounts your platform team provisioned. Any component you did not override continues to use the chart-managed RBAC resources.