> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/resilience-testing/chaos-testing/infrastructure/kubernetes/dedicated-delegate/limited-permissions.md).

# Limited Permissions install

Install the Harness Delegate scoped to a dedicated namespace with a least-privilege Role and ClusterRole, instead of the default cluster-admin.

Use this install when `cluster-admin` is not acceptable on the target cluster. You scope the Delegate to a dedicated namespace, replace the default `ClusterRoleBinding` with a namespace-scoped `Role`, and grant chaos access to only the workloads you plan to inject chaos into through an opt-in `ClusterRole`.

## Before you begin

* **Cluster access:** `kubectl` access to the target cluster with permission to create namespaces, service accounts, roles, and role bindings.
* **Delegate manifest:** The Delegate Helm values or YAML manifest you plan to install, so you can edit its bindings and service account. Go to [Basic install](/resilience-testing/chaos-testing/infrastructure/kubernetes/dedicated-delegate/basic.md#install-the-harness-delegate) to get the standard Delegate image.
* **Harness project access:** Permissions to create connectors and chaos infrastructure in the project. Go to [RBAC in Harness](https://developer.harness.io/harness-platform/use-harness-platform/platform-access-control) to configure roles.

## Step 1. Create a dedicated namespace <a href="#step-1-create-a-dedicated-namespace" id="step-1-create-a-dedicated-namespace"></a>

Create a dedicated namespace for the Harness Delegate. For example, `harness-delegate-ng`.

```bash
kubectl create ns harness-delegate-ng
```

## Step 2. Remove the cluster role binding from the delegate manifest <a href="#step-2-remove-the-cluster-role-binding-from-the-delegate-manifest" id="step-2-remove-the-cluster-role-binding-from-the-delegate-manifest"></a>

Edit the Delegate Helm values (or YAML manifest) and remove the `ClusterRoleBinding` whose `roleRef.name` is `cluster-admin`. In the default Helm chart this resource is named `<delegate-name>-cluster-admin`. Removing it stops the Delegate from inheriting cluster-wide privileges.

![Cluster role binding to remove in the Delegate manifest](https://3217710372-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FRmV5EkLS9r45VPaoUnJZ%2Fuploads%2Fgit-blob-beb40a1ea7e92e7a716ce725b8623b3de65d9699%2Fcluster.png?alt=media)

## Step 3. Create a new service account for the delegate <a href="#step-3-create-a-new-service-account-for-the-delegate" id="step-3-create-a-new-service-account-for-the-delegate"></a>

Create a service account in the dedicated namespace. The Delegate pod will run as this service account.

```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: chaos-delegate
  namespace: harness-delegate-ng
```

## Step 4. Attach the service account to the delegate <a href="#step-4-attach-the-service-account-to-the-delegate" id="step-4-attach-the-service-account-to-the-delegate"></a>

Reference the service account in the Delegate Helm values or manifest.

![Service account attached in the Delegate manifest](https://3217710372-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FRmV5EkLS9r45VPaoUnJZ%2Fuploads%2Fgit-blob-50f0f9df75198b110d87991520abf5634b530fd8%2Fattach.png?alt=media)

## Step 5. Apply chaos RBAC <a href="#step-5-apply-chaos-rbac" id="step-5-apply-chaos-rbac"></a>

Apply the **Dedicated delegate approach (Delegate in target cluster)** manifest set from [Cluster permissions → Example RBAC manifests](/resilience-testing/chaos-testing/infrastructure/kubernetes/permissions.md#example-rbac-manifests). The set contains:

1. A namespace `Role` and `RoleBinding` so the Delegate can manage chaos runner pods inside `harness-delegate-ng`.
2. A `ClusterRole` (`chaos-clusterrole`) with the discovery and chaos permissions the runner needs.
3. Either a `ClusterRoleBinding` (chaos can target any namespace) or per-namespace `RoleBinding`s (chaos can target only onboarded namespaces).

The manifests assume `chaos-delegate` as the service account and `harness-delegate-ng` as the namespace. Adjust both if you used different names in Steps 1 and 3.

{% hint style="info" %}
**PICK A BINDING MODE**

* **Bind to all namespaces** with a `ClusterRoleBinding`. Easier to manage; less precise.
* **Bind to specific namespaces** with one `RoleBinding` per application namespace. Explicit per-app onboarding.
  {% endhint %}

## Step 6. Create a Kubernetes connector that uses delegate permissions <a href="#step-6-create-a-kubernetes-connector-that-uses-delegate-permissions" id="step-6-create-a-kubernetes-connector-that-uses-delegate-permissions"></a>

In Harness, create a [Kubernetes Direct Connection connector](https://developer.harness.io/harness-platform/use-harness-platform/connectors/cloud-providers/ref-cloud-providers/kubernetes-cluster-connector-settings-reference) that authenticates via the Delegate's own credentials. The Delegate's service account drives the connection.

![Kubernetes connector with Delegate credentials](https://3217710372-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FRmV5EkLS9r45VPaoUnJZ%2Fuploads%2Fgit-blob-a9943e28f14cd12680238308a42fdb8ea622fe4c%2Fdelegate-perms.png?alt=media)

![Connector setup with the Delegate](https://3217710372-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FRmV5EkLS9r45VPaoUnJZ%2Fuploads%2Fgit-blob-748aceff97c11131271e3583f83ca15f045cfab1%2Fdelegate-setup.png?alt=media)

## Step 7. Create the Kubernetes infrastructure <a href="#step-7-create-the-kubernetes-infrastructure" id="step-7-create-the-kubernetes-infrastructure"></a>

Create the chaos infrastructure using the connector from Step 6. The form fields are identical to the [Basic install](/resilience-testing/chaos-testing/infrastructure/kubernetes/dedicated-delegate/basic.md#create-a-kubernetes-infrastructure) flow.

## Step 8. Edit the infrastructure to use the dedicated namespace <a href="#step-8-edit-the-infrastructure-to-use-the-dedicated-namespace" id="step-8-edit-the-infrastructure-to-use-the-dedicated-namespace"></a>

After saving, open the infrastructure and edit it so the chaos runner is created in `harness-delegate-ng` (the namespace where the Delegate runs) using the `chaos-delegate` service account. This ensures the runner picks up the namespace-scoped `Role` from Step 5.

![Edit infrastructure to set namespace and service account](https://3217710372-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FRmV5EkLS9r45VPaoUnJZ%2Fuploads%2Fgit-blob-ea5d11c683b6719855dc8905f2ec76d7c954e047%2Fedit-infra-sa.png?alt=media)

## Troubleshooting

<details>

<summary>A chaos experiment fails with a forbidden error in an application namespace</summary>

With per-namespace `RoleBinding`s, the chaos runner can act only in the namespaces you bound in Step 5. Add a `RoleBinding` for `chaos-clusterrole` in the application namespace, or switch to a `ClusterRoleBinding` if chaos must reach every namespace.

</details>

<details>

<summary>The chaos runner pod is not created in the dedicated namespace</summary>

The infrastructure still uses its default namespace and service account. Edit the infrastructure as described in Step 8 so the runner starts in `harness-delegate-ng` with the `chaos-delegate` service account.

</details>

<details>

<summary>The Delegate still has cluster-wide access after a limited permissions install</summary>

The `cluster-admin` `ClusterRoleBinding` from the default manifest is still in place. Remove the `<delegate-name>-cluster-admin` binding as described in Step 2, then redeploy the Delegate.

</details>

## Next steps

* [Cluster permissions](/resilience-testing/chaos-testing/infrastructure/kubernetes/permissions.md): Review every permission the chaos runner uses, and which ones are optional.
* [Centralized delegate approach](/resilience-testing/chaos-testing/infrastructure/kubernetes/centralized-delegate.md): Run one Delegate that reaches several target clusters instead.

{% @harness-feedback/feedback %}