> For the complete documentation index, see [llms.txt](https://docs.cybus.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cybus.io/2-6-1/cybus-helm-charts/connectware-helm-chart/existing-serviceaccounts.md).

# 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).

## 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.

{% hint style="warning" %}

## 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.
{% endhint %}

### Container Manager

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

{% code title="cm-role.yaml" lineNumbers="true" %}

```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}
```

{% endcode %}

### Broker

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

{% code title="broker-role.yaml" lineNumbers="true" %}

```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}
```

{% endcode %}

## Governed-Deployment Workflow

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

1. Have your platform team apply the manifests from [Reference Manifests](#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:

{% code title="values.yaml" lineNumbers="true" %}

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

{% endcode %}

* 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.

3. 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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.cybus.io/2-6-1/cybus-helm-charts/connectware-helm-chart/existing-serviceaccounts.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.