argo-events service account additional namespaces

[rconjaerts]

Hi,

In an older helm chart (before v1.7) there was the possibility to add additional namespaces to the service account. The whole file got a huge overhaul in this commit, and I'm wondering where I can set this value now. Underneath rbac, namespaced has been said to false, but is that all? Because my deployments in a different namespace are still not able to find the service account.

[pdrastil]

Hi,
@rconjaerts chart 2.x got overhaul because 3 controllers were merged into single one. Cluster-wide installation of the controller is now default so it can manage resources in a whole cluster via ClusterRole. If you opt-in for namespace installation you get a fresh SA in that namespace that will use only namespace scoped Role instead of ClusterRole to manage Argo Event resources.

[rconjaerts]

The reason why I asked is because the issue I have after upgrading is that 3 of my deployments underneath the import namespace aren't able to find the the proper service account now, and I'm not sure what I need to change in their deployment files to make it work.

All 3 of them have in their deployment file for the spec field:

template:
    serviceAccountName: argo-events-sa

Which is the only mention of argo-events-sa in our whole organization in Github. So I guess that with the old helm chart it added the service account to the import namespace as well as the infra namespace? Now that it's cluster wise, what do I need to do such that the 3 deployments search for the service account cluster wide instead of only in their namespace?

P.S. If it wasn't clear yet, I'm still learning a lot about k8s and argo. I've taken over the whole argo setup from someone who left the company, who also managed our k8s cluster, but there wasn't a proper handover.

[pdrastil]

I'm not sure what do you mean "by your deploymens" or import / infra namespace as this is different for each user. Do you mean just argo-events controller deployments? Or do you mean other deployments for EventBuses etc. created by the controller? For the argo-events controller service account is automatically created and RBAC is either set to cluster-wide mode (1 controller per cluster) or you install in namespace mode (multiple controllers that can manage things only inside 1 namespace). For both cases service account is automatically created for argo-events and proper RBAC is used for given installation and there is nothing extra to configure.

[rconjaerts]

My apologies for not being more detailed and clear. Within our k8s cluster (on GCP) we have 2 namespaces, import and infra. argo-workflow and argo-events are deployed within the infra namespace.

We have 2 pubsub's and 1 webhook that are deployed within the import namespace. Those 3 workloads used to have access to the service account created by the old helm chart from argo-events. Because in that deployment file we had:

-- Create service accounts in additional namespaces specified
-- The SA will always be created in the release namespaces
additionalSaNamespaces:

• import

Does this mean that there was 1 service account that had access in both namespaces, or did this create 2 service accounts? One for import and one for the default infra namespace.

Nevertheless, currently there is a service account created that has access throughout the whole cluster since this is specified by default in the new helm chart. Currently my 3 workloads are giving me the error that they can't find this service account, more specifically it says: error looking up service account import/argo-events-sa: serviceaccount "argo-events-sa" not found. So now I'm searching for a solution that would tell my 3 workloads where the new service account created by the new helm chart can be found. I guess I have to specify this in their own deployment files, but I can't find where. The only mention of argo-events-sa is in the spec field. This is one of the deployment files, you can see on line 8 that I put in the service account name, but I think it can't find it because it's looking specifically in the import namespace.

apiVersion: argoproj.io/v1alpha1
kind: Sensor
metadata:
  name: pubsub-import-integration
  namespace: import
spec:
  template:
    serviceAccountName: argo-events-sa
  dependencies:
    - name: pubsub-dep
      eventSourceName: gcp-pubsub-import-integration
      eventName: import-integration
  triggers:
    - template:
        name: argo-workflow-trigger
        argoWorkflow:
          group: argoproj.io
          version: v1alpha1
          resource: workflows
          operation: submit
          source:
            resource:
              apiVersion: argoproj.io/v1alpha1
              kind: Workflow
              metadata:
                generateName: integration-import-
              spec:
                entrypoint: import
                arguments:
                  parameters:
                    - name: provider
                    - name: type
                    - name: entityId
                    - name: integrationId
                templates:
                  - name: import
                    inputs:
                      parameters:
                        - name: provider
                        - name: type
                        - name: entityId
                        - name: integrationId
                    steps:
                      - - name: call-generic-integration-import
                          templateRef:
                            name: generic-integration-import
                            template: import
                          arguments:
                            parameters:
                              - name: provider
                                value: "{{inputs.parameters.provider}}"
                              - name: type
                                value: "{{inputs.parameters.type}}"
                              - name: entityId
                                value: "{{inputs.parameters.entityId}}"
                              - name: integrationId
                                value: "{{inputs.parameters.integrationId}}"
          parameters:
            - src:
                dependencyName: pubsub-dep
                dataKey: attributes.provider
              dest: spec.arguments.parameters.0.value
            - src:
                dependencyName: pubsub-dep
                dataKey: attributes.type
              dest: spec.arguments.parameters.1.value
            - src:
                dependencyName: pubsub-dep
                dataKey: body.entityId
              dest: spec.arguments.parameters.2.value
            - src:
                dependencyName: pubsub-dep
                dataKey: body.integrationId
              dest: spec.arguments.parameters.3.value

[pdrastil]

Ok now I see :). The serviceAccountName undertemplate is used by your custom Sensor pod to grant it RBAC to manipulate the trigger resource. You should create your own service account and grant it proper RBAC permissions if needed instead of reusing service account of argo-events controller (really not a good security practice as Sensor pod suddenly gets all extra permissions controller had including modification of other Sensor resources or EventBuses). This security hole was closed in 2.x. For your use case - create a new SA for the Sensor and grant it proper RBAC access to apiGroup: argoproj.io/v1alpha1 and resource Workflow it manipulates (in 1.x chart this extra RBAC was defined under additionalServiceAccountRules option).

[rconjaerts]

Thank you for this extra information, I'll try to make it work. Have a great weekend!