|
| 1 | +This script may be used to audit the namespace-scoped Roles/RoleBindings that are created by the GitOps operator's 'applications in any namespace/applicationsets in any namespace' features. |
| 2 | +(The 'apps/applications in any namespace' features are not enabled by default. They are enabled via `ArgoCD` CR `.spec.sourceNamespaces` and `.spec.applicationSet.sourceNamespaces`.) |
| 3 | + |
| 4 | +This is a simple script that will look for Roles/RoleBindings across ALL namespaces that meet ALL of the following criteria: |
| 5 | +- A) The Role allows access to `argoproj.io/Application` resource |
| 6 | +- B) The Role has label `app.kubernetes.io/part-of: argocd` |
| 7 | +- C) The RoleBinding references a service-account in another namespace (cross-namespace access) |
| 8 | + |
| 9 | +This criteria ensures that the Role/RoleBinding was likely created by GitOps operator, and that an Argo CD instance on the cluster has (or had) access to that namespace. |
| 10 | + |
| 11 | +## Procedure: |
| 12 | +1) Ensure that `jq` and `oc` executables are installed and on path. |
| 13 | +2) Ensure that you are logged into cluster via `oc` or `kubectl` CLI. |
| 14 | +3) Execute `./audit-operator-roles.sh` |
| 15 | +4) Examine the output list of Roles/RoleBindings. |
| 16 | + |
| 17 | +For each Role/RoleBinding that is listed: |
| 18 | +- If a Role/RoleBinding is listed, that means another namespace on the cluster has access to the namespace containing the Role/RoleBinding |
| 19 | +- Verify that it is correct for the namespace containing the Role/RoleBinding to be accessed by the namespace listed in subject field of the RoleBinding. |
| 20 | + - For example, it is correct if you need an Argo CD instance (installed in the namespace listed in subject field of the RoleBinding) to deploy to the namespace containing the RoleBinding. |
| 21 | + - In contrast, it is likely not correct if there exist Roles/RoleBindings in namespaces that Argo CD is not explicitly deploying to. |
| 22 | +- If a Role/RoleBinding exists that is not required, delete them. |
| 23 | + - NOTE: They will be recreated by the operator if there exists an `ArgoCD` CR that references the namespace via the `.spec.sourceNamespaces` or `.spec.applicationSet.sourceNamespaces`. |
| 24 | + - If this is the case, first remove the namespace from these fields, then delete the Role/RoleBinding. |
| 25 | + |
| 26 | + |
| 27 | +Example: |
| 28 | + |
| 29 | +In this example, the script indicates that the `my-argocd` namespace has access to the `app-ns` namespaces via multiple GitOps-operator-created Roles/RoleBindings: |
| 30 | + |
| 31 | +``` |
| 32 | +========================================================= |
| 33 | +SEARCH CRITERIA (Must match ALL): |
| 34 | + 1. API/Resource: argoproj.io / applications |
| 35 | + 2. Label: app.kubernetes.io/part-of=argocd |
| 36 | + 3. Scope: Cross-namespace only |
| 37 | +========================================================= |
| 38 | +
|
| 39 | +Scanning Cluster (this may take a moment)... |
| 40 | +
|
| 41 | +Roles with cross-namespace access: |
| 42 | + • Role: app-ns/example-my-argocd-applicationset |
| 43 | + • Role: app-ns/example_app-ns |
| 44 | +
|
| 45 | +Cross-namespace bindings detail: |
| 46 | +-------------------------------------------------- |
| 47 | +BINDING: app-ns / example-my-argocd-applicationset |
| 48 | +ROLE REF: example-my-argocd-applicationset |
| 49 | +SUBJECTS (cross-namespace only): |
| 50 | + • ServiceAccount: example-applicationset-controller (ns: my-argocd) |
| 51 | +
|
| 52 | +• Namespace my-argocd has access to app-ns |
| 53 | +
|
| 54 | +-------------------------------------------------- |
| 55 | +BINDING: app-ns / example_app-ns |
| 56 | +ROLE REF: example_app-ns |
| 57 | +SUBJECTS (cross-namespace only): |
| 58 | + • ServiceAccount: example-argocd-server (ns: my-argocd) |
| 59 | + • ServiceAccount: example-argocd-application-controller (ns: my-argocd) |
| 60 | +
|
| 61 | +• Namespace my-argocd has access to app-ns |
| 62 | +``` |
0 commit comments