feat(argo-workflows): don't run as namespaced

Make the Argo Server, the UI and API component, and the Workflow
Controller, the actual workflow engine, not run as namespaced so the UI
and API can see and manage Argo Events. This is because Argo Events uses
the same Argo Server for its UI and we run the EventSources and Sensors
in a different namespace. Changed the Workflow Controller as well
because it was easier and cleaner to do so and allowed us to use the
upstream manifests more cleanly. To achieve the same protection and
separation, switch to the ClusterRole and just use a RoleBinding to bind
it to specific namespaces. This makes using the upstream manifests a
little more cleaner and they already have separate roles for what we
called the runtime so we can delete those.

Author: cardoe

components/argo-events/argo-server-rb.yaml renamed to components/argo-events/argo-server-rolebinding.yaml

@@ -2,6 +2,10 @@ apiVersion: apps/v1
 kind: RoleBinding
 metadata:
   name: argo-server-binding
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: argo-server-cluster-role
 subjects:
 - kind: ServiceAccount
   name: argo-server

components/argo-events/kustomization.yaml

@@ -8,8 +8,9 @@ resources:
   - https://github.com/argoproj/argo-events/releases/download/v1.9.7/install-validating-webhook.yaml
 
   # grant the argo-workflows the ability to run workflows in this namespace
-  - https://github.com/argoproj/argo-workflows/manifests/namespace-install/argo-server-rbac?ref=v3.5.10
-  - https://github.com/argoproj/argo-workflows/manifests/namespace-install/workflow-controller-rbac?ref=v3.5.10
+  - workflow-controller-rolebinding.yaml
+  # grant the argo-server the ability to see workflows in this namespace
+  - argo-server-rolebinding.yaml
 
   ## configure webhook Sensor and associated role
   - sensor-workflow-role.yaml
@@ -19,14 +20,3 @@ resources:
 
   ## copy openstack/cinder-netapp-config to argo-events/netapp-config
   - secret-netapp.yaml
-
-patches:
-- target:
-    kind: RoleBinding
-    name: argo-binding
-  path: controller-rb.yaml
-
-- target:
-    kind: RoleBinding
-    name: argo-server-binding
-  path: argo-server-rb.yaml

components/argo-events/controller-rb.yaml renamed to components/argo-events/workflow-controller-rolebinding.yaml

@@ -2,6 +2,10 @@ apiVersion: apps/v1
 kind: RoleBinding
 metadata:
   name: argo-binding
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: argo-cluster-role
 subjects:
 - kind: ServiceAccount
   name: argo

components/argo/argo-server-deployment.yaml

@@ -13,8 +13,3 @@ spec:
         - --auth-mode=sso
         # all other auth via Kubernetes bearer tokens
         - --auth-mode=client
-        # running in namespaced mode and not cluster wide
-        - --namespaced
-        # configures the namespace where workflows actually run
-        - --managed-namespace
-        - argo-events

components/argo/argo-server-runtime.yaml

@@ -0,0 +1,6 @@
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+  name: argo-server-binding
+$patch: delete

components/argo/delete-argo-server-crb.yaml

@@ -0,0 +1,6 @@
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+  name: argo-binding
+$patch: delete

components/argo/delete-workflow-controller-crb.yaml

@@ -3,14 +3,13 @@ apiVersion: kustomize.config.k8s.io/v1beta1
 kind: Kustomization
 
 resources:
-  # We are doing upstream's namespace-install.yaml but since we
-  # want the actual workflows to run in a different namespace
-  # the roles are created there
-  - https://github.com/argoproj/argo-workflows/manifests/base?ref=v3.5.10
-  # give the workflow controller access it needs
-  - workflow-controller-runtime.yaml
-  # give the argo-server access it needs
-  - argo-server-runtime.yaml
+  # We are wanting to limit the scope and access down to
+  # just the namespaces we want to give access for workflows
+  # to run and the argo-server to be able to see workflows and
+  # argo events so we need to split up what we install. So
+  # we delete the ClusterRoleBinding and instead create RoleBindings
+  # to the ClusterRole for just the namespaces we want.
+  - https://github.com/argoproj/argo-workflows/manifests/cluster-install/?ref=v3.5.10
 
   # ingress for workflows.${DNS_ZONE} to the argo server for the UI
   - ingress.yaml
@@ -28,6 +27,20 @@ images:
     newTag: v3.5.10
 
 patches:
+- target:
+    group: rbac.authorization.k8s.io
+    version: v1
+    kind: ClusterRoleBinding
+    name: argo-binding
+  path: delete-workflow-controller-crb.yaml
+
+- target:
+    group: rbac.authorization.k8s.io
+    version: v1
+    kind: ClusterRoleBinding
+    name: argo-server-binding
+  path: delete-argo-server-crb.yaml
+
 # see the patch for details on the change
 - target:
     group: apps

components/argo/kustomization.yaml

@@ -13,28 +13,33 @@ and maintenance tasks.
 while the actual workflows run in another dedicated namespace (argo-events),
 to ensure proper security isolation and resource control. This separation
 is provided by [Argo Workflows][argo-wf] but poorly documented upstream which
-they call [Managed Namespace][argo-wf-managed-ns].
+they call [Managed Namespace][argo-wf-managed-ns]. Unfortunately the
+likely better approach at achieving this managed namespace installation
+would be to use the cluster based install which uses ClusterRoles but then
+binds the ClusterRole to a specific namespace instead of a ClusterRoleBinding.
+This is the approach we take.
 
 ### Argo Workflows Configuration
 
 We do not use the `namespace-install.yaml` provided by the project as it
-combines everything into one YAML and we need to split it out. It combines:
+combines everything into one YAML and focuses on running everything in
+one namespace while we want separation. What we ultimately need:
 
 * CRDs
 * Argo Server, which is the UI and the API for Argo Workflows and Argo Events
 * Argo Workflows Controller, which is the executor for the workflow and creates
 the pods
-* Server Role, which is the Role and RoleBinding for the Argo Server to access
+* Server RBAC, which is the ClusterRole and RoleBinding for the Argo Server to access
 the workflow, the pods, the logs, and inputs for user visibility
-* Workflow Controller Role, which is the Role and RoleBinding to give the controller
+* Workflow Controller RBAC, which is the ClusterRole and RoleBinding to give the controller
 access to run and manage the workflows.
 
 The CRDs, the Argo Server, and the Argo Workflow Controller will all be installed
-into the (argo) namespace while the 2 Roles and RoleBindings need to be installed
+into the (argo) namespace while the 2 RoleBindings need to be installed
 into the namespace where the workflow execute, which is (argo-events).
 
 The Argo Server and the Workflow Controller additionally need access to additional
-resources. The Argo Server needs access to the configmap, the SSO secret
+resources. The Argo Server needs access to the configmap, the SSO secret.
 
 ## Template-Only Execution Model