> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Demo Configure Service Account with RBAC Settings > Configuring a dedicated ServiceAccount and RBAC so an Argo Events Sensor can securely submit Argo Workflows into a target namespace, avoiding permission errors. In this lesson you'll configure a dedicated ServiceAccount and RBAC rules so an Argo Events Sensor can submit Argo Workflows into a target namespace. This resolves "permission denied" errors when the Sensor attempts to create a Workflow using the cluster default ServiceAccount. Why this matters: * Using a scoped ServiceAccount with minimal RBAC permissions is more secure than relying on the default ServiceAccount. * It prevents permission errors and enables the Sensor to create Workflows in a separate namespace. Problem evidence (sensor error when using the default ServiceAccount): ```json theme={null} { "namespace": "argo-events", "sensorName": "webhook-sensor", "level": "error", "time": "2025-10-25T11:00:39Z", "msg": "Create request failed", "error": "workflows.argoproj.io is forbidden: User \"system:serviceaccount:argo-events:default\" cannot create resource \"workflows\" in API group \"argoproj.io\" in the namespace \"argo\"" } ``` This shows the Sensor (running in `argo-events`) attempted to create a Workflow in the `argo` namespace using the `default` ServiceAccount and was forbidden. Planned steps: 1. Create a ServiceAccount in the Sensor's namespace (`argo-events`). 2. Create a Role and RoleBinding in the target namespace (`argo`) to allow the ServiceAccount to create/read Workflows. 3. Update the Sensor to use the new ServiceAccount. 4. Trigger the Sensor and confirm the Workflow is created. *** ## Resources Overview | Resource Type | Purpose | Example | | ----------------- | ----------------------------------------------------------------- | ---------------------------------- | | ServiceAccount | Identity used by the Sensor when creating Workflows | `workflow-trigger-sa` | | Role | Grants Workflow permissions in the target namespace | `submit-workflow-role` | | RoleBinding | Binds the ServiceAccount from `argo-events` to the Role in `argo` | `trigger-workflow-binding` | | Sensor spec field | Instructs the Sensor which ServiceAccount to use | `spec.template.serviceAccountName` | References: * [Argo Events - Sensor](https://argoproj.github.io/argo-events/reference/sensor/) * [Argo Workflows](https://argoproj.github.io/argo-workflows/) * [Kubernetes RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) *** ## 1. Create the ServiceAccount First, list existing ServiceAccounts in the `argo-events` namespace, then create a new one called `workflow-trigger-sa`: ```bash theme={null} # List ServiceAccounts in the argo-events namespace kubectl -n argo-events get sa # Create the new ServiceAccount kubectl create sa workflow-trigger-sa -n argo-events # Verify it was created kubectl -n argo-events get sa ``` Expected output after creation: ```text theme={null} NAME SECRETS AGE argo-events-sa 0 40m default 0 40m workflow-trigger-sa 0 1s ``` *** ## 2. Create Role and RoleBinding for Argo Workflows Create a Role in the `argo` namespace that grants the minimum permissions the Sensor needs for Argo Workflows, and a RoleBinding that binds the `workflow-trigger-sa` ServiceAccount from the `argo-events` namespace to that Role. Manifest to apply: ```yaml theme={null} # sensor-rbac.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: submit-workflow-role namespace: argo rules: - apiGroups: ["argoproj.io"] resources: ["workflows"] verbs: ["create", "get", "list", "watch"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: trigger-workflow-binding namespace: argo subjects: - kind: ServiceAccount name: workflow-trigger-sa namespace: argo-events roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: submit-workflow-role ``` Apply the manifest: ```bash theme={null} kubectl apply -f https://gist.github.com/sidd-harth/e68c477696c7972fafb52171f5ce5a0f/raw/1e1104271876b953ed1592a8dc6553c80b2f86a9/sensor-rbac.yaml ``` Expected apply output: ```text theme={null} role.rbac.authorization.k8s.io/submit-workflow-role created rolebinding.rbac.authorization.k8s.io/trigger-workflow-binding created ``` If you see an error like "unknown command 'apply' for 'kubectl1'", it likely indicates an alias or PATH issue (for example, `k` pointing to an unexpected binary). Use the full `kubectl` binary or fix the alias so `k` maps to `kubectl`. *** ## 3. Update the Sensor to Use the ServiceAccount Edit your Sensor manifest to set `spec.template.serviceAccountName` to the ServiceAccount you created (`workflow-trigger-sa`). Below is a minimal Sensor snippet showing where to configure this: ```yaml theme={null} apiVersion: argoproj.io/v1alpha1 kind: Sensor metadata: name: webhook namespace: argo-events spec: template: serviceAccountName: workflow-trigger-sa dependencies: - name: my-webhook-dep eventSourceName: webhook eventName: my-webhook triggers: - template: name: hello-workflow-trigger argoWorkflow: source: resource: apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: generateName: hello-kodekloud- namespace: argo spec: entrypoint: cowsay templates: - name: cowsay container: image: rancher/cowsay command: ["cowsay"] args: ["Hello Kode Kloud from ArgoEvents!!"] ``` Apply the updated Sensor manifest or edit the resource directly: ```bash theme={null} kubectl apply -f sensor-updated.yaml -n argo-events # or edit in place kubectl edit sensor webhook -n argo-events ``` After updating, the Sensor will use `workflow-trigger-sa` when creating Workflows in the `argo` namespace. *** ## 4. Trigger the Sensor and Confirm Workflow Creation Trigger the webhook event source (example using curl): ```bash theme={null} curl -d '{"message":"hello"}' -H "Content-Type: application/json" -X POST http://localhost:13000/push ``` You should receive a success response from the event source (for example, `success`). Then check logs to confirm the event flow: Example event source logs: ```text theme={null} namespace=argo-events, eventSourceName=webhook, eventName=my-webhook, level=info, time=2025-10-25T11:12:45Z, msg="Succeeded to publish an event" namespace=argo-events, eventSourceName=webhook, eventName=my-webhook, level=info, time=2025-10-25T11:12:59Z, msg="Successfully dispatched the request to the event bus" ``` Example Sensor logs: ```json theme={null} {"level":"info","ts":"2025-10-25T11:12:42.920827Z","msg":"Sensor started.","sensorName":"webhook-sensor"} {"level":"info","ts":"2025-10-25T11:13:00.188816Z","msg":"Successfully processed trigger 'hello-workflow-trigger'","sensorName":"webhook-sensor","triggerName":"hello-workflow-trigger","triggerType":"ArgoWorkflow"} ``` Verify the Workflow exists in the `argo` namespace: ```bash theme={null} kubectl -n argo get wf ``` Describe the Workflow to inspect labels and the ServiceAccount used by the creator: ```bash theme={null} kubectl -n argo describe wf ``` You should see labels like `workflow.argoproj.io/creator` and evidence that the Workflow was submitted by the `workflow-trigger-sa` ServiceAccount. Check the Workflow pod logs to confirm the job ran successfully (example cowsay output): ```text theme={null} hello-kodekloud-xxxxx: < Hello Kode Kloud from ArgoEvents!! > hello-kodekloud-xxxxx: ------------------------------- hello-kodekloud-xxxxx: \ ^__^ hello-kodekloud-xxxxx: \ (oo)\_______ hello-kodekloud-xxxxx: (__)\ )\/\ hello-kodekloud-xxxxx: ||----w | hello-kodekloud-xxxxx: || || ``` *** ## Summary / Event Flow * The webhook EventSource receives the HTTP POST and publishes the event to the event bus. * The Sensor subscribes to the event bus, evaluates dependencies, and triggers the Argo Workflow. * The Sensor uses the configured `spec.template.serviceAccountName` (`workflow-trigger-sa`) to submit the Workflow into the `argo` namespace. * The Role and RoleBinding in the `argo` namespace grant the ServiceAccount the necessary permissions to create and read Argo Workflows. This setup ensures your Sensor submits Workflows securely using a limited, purpose-built ServiceAccount instead of the cluster default ServiceAccount.