github.com/argoproj/argo-events@v1.9.1/docs/service-accounts.md (about)

     1  # Service Accounts
     2  
     3  ## Service Account for EventSources
     4  
     5  A `Service Account` can be specified in the EventSource object with
     6  `spec.template.serviceAccountName`, however it is not needed for all the
     7  EventSource types except `resource`. For a `resource` EventSource, you need to
     8  specify a Service Account and give it `list` and `watch` permissions for the
     9  resource being watched.
    10  
    11  For example, if you want to watch actions on `Deployment` objects, you need to:
    12  
    13  1. Create a Service Account.
    14  
    15          kubectl -n your-namespace create sa my-sa
    16  
    17  2. Grant RBAC privileges to it.
    18  
    19          kubectl -n your-namespace create role deployments-watcher --verb=list,watch --resource=deployments.apps
    20  
    21          kubectl -n your-namespace create rolebinding deployments-watcher-role-binding --role=deployments-watcher --serviceaccount=your-namespace:my-sa
    22  
    23      or (if you want to watch cluster scope)
    24  
    25          kubectl create clusterrole deployments-watcher --verb=list,watch --resource=deployments.apps
    26  
    27          kubectl create clusterrolebinding deployments-watcher-clusterrole-binding --clusterrole=deployments-watcher --serviceaccount=your-namespace:my-sa
    28  
    29  ## Service Account for Sensors
    30  
    31  A `Service Account` also can be specified in a Sensor object via
    32  `spec.template.serviceAccountName`, this is only needed when `k8s` trigger or
    33  `argoWorkflow` trigger is defined in the Sensor object.
    34  
    35  The sensor examples provided by us use `operate-workflow-sa` service account to
    36  execute the triggers, but it has more permissions than needed, and you may want
    37  to limit those privileges based on your use-case. It's always a good practice to
    38  create a service account with minimum privileges to execute it.
    39  
    40  ### Argo Workflow Trigger
    41  
    42  - To `submit` a workflow through `argoWorkflow` trigger, make sure to grant the
    43    Service Account `create` and `list` access to `workflows.argoproj.io`.
    44  
    45  - To `resubmit`, `retry`, `resume` or `suspend` a workflow through
    46    `argoWorkflow` trigger, the service account needs `update` and `get` access to
    47    `workflows.argoproj.io`.
    48  
    49  ### K8s Resource Trigger
    50  
    51  To trigger a K8s resource including `workflows.argoproj.io` through `k8s`
    52  trigger, make sure to grant `create` permission to that resource.
    53  
    54  ### AWS Lambda, HTTP, Slack, NATS, Kafka, and OpenWhisk Triggers
    55  
    56  For these triggers, you **don't** need to specify a Service Account to the
    57  Sensor.
    58  
    59  ## Service Account for Triggered Workflows (or other K8s resources)
    60  
    61  When the Sensor is used to trigger a Workflow, you might need to configure the
    62  Service Account used in the Workflow spec (**NOT**
    63  `spec.template.serviceAccountName`) following Argo Workflow
    64  [instructions](https://github.com/argoproj/argo-workflows/blob/master/docs/service-accounts.md).
    65  
    66  If it is used to trigger other K8s resources (i.e. a Deployment), make sure to
    67  follow least privilege principle.