> 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-5-0/cybus-helm-charts/connectware-helm-chart/existing-serviceaccounts.md).

# Using Existing ServiceAccounts

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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

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

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.