Description of Problem

• When installing an namespace scoped instance following https://docs.openshift.com/gitops/1.15/multitenancy/multitenancy-support-in-gitops.html#gitops-namespace-scoped-instance_multitenancy-support-in-gitops
  the project admin of the name can use the redis instance argocd-redis ServiceAccounts which have a bit more privilege (`nonroot-v2`) than the standard `restricted-v2` SecurityContextConstraints.

Additional Info

• Probably the problem should be fixed in the redis container image. Instead of requiring a non-root uid (999) the redis image should follow https://docs.openshift.com/container-platform/4.17/openshift_images/create-images.html#use-uid_create-images

Reproducibility

• Always

Prerequisites/Environment

• No prerequisites

Steps to Reproduce

• Install the OpenShift Gitops Operator using the defaults.  Note that the OpenShift Gitops only supports the AllNamespaces InstallMode, thus the ArgoCD Custom Resource is available in all namespaces.

$ oc get csv openshift-gitops  -o yaml | yq '.spec.installModes' 
[
  {
    "supported": false,
    "type": "OwnNamespace"
  },
  {
    "supported": false,
    "type": "SingleNamespace"
  },
  {
    "supported": false,
    "type": "MultiNamespace"
  },
  {
    "supported": true,
    "type": "AllNamespaces"
  }
]

• As an unprivileged user, create a namespace and install an ArgoCD instance in it:

$ oc whoami
manu
$ oc new-project manu
$ cat ArgoCD.yaml 
apiVersion: argoproj.io/v1beta1
kind: ArgoCD
metadata:
  name: my-user-instance
  namespace: manu
$ oc apply -f ArgoCD.yaml

• Notice that the operator created two service accounts, and use one of this service account in a Pod `hellokube`

$ oc get sa my-user-instance-argocd-redis my-user-instance-argocd-redis-ha -n manu
NAME                               SECRETS   AGE
my-user-instance-argocd-redis      0         125m
my-user-instance-argocd-redis-ha   0         125m
$ cat pod.yaml
cat pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: hellokube
spec:
  containers:
  - name: app-py
    image: quay.io/manue/hellopy:6
  securityContext:
    runAsUser: 1000
  serviceAccountName: my-user-instance-argocd-red
$ oc apply -f pod.yaml

• The process running inside the pod is running inside the pod with uid1000 instead of a randomized uid.

$ oc debug  hellokube -- id 
uid=1000(1000) gid=0(root) groups=0(root)

• This can also be seen on the worker node where the pod is scheduled:

$ ps -efZ | grep '/app/app.py'
system_u:system_r:container_t:s0:c9,c27 1000720+ 1679241 1679228  0 Feb05 ? 00:00:53 /usr/bin/python3 /app/app.py

system_u:system_r:container_t:s0:c2,c28 core 1752241 1752231  0 13:01 ?    00:00:00 /usr/bin/python3 /app/app.py

The first line shows the pod running with a randomized uid, whereas the second shows  the same pod using the non-root-v2 SecurityContextContraint, running as UID 1000 which maps to the `core` user on the node.

Note that SELinux containments and kernel namespaces are still in place, so the Pod process is still confined, however this breaks the Principle of least privilege of the default SecurityContextConstraint.

Expected Results

• Unprivileged cluster users don't have access to a ServiceAccount with a higher privilege.

Actual Results

• Unprivileged cluster users don't have access to a ServiceAccount with a higher privilege.

Problem Analysis

• <Completed by engineering team as part of the triage/refinement process>

Root Cause

• Probably the problem should be fixed in the redis container image. Instead of requiring a non-root uid (999) the redis image should follow  https://docs.openshift.com/container-platform/4.17/openshift_images/create-images.html#use-uid_create-images

Workaround (If Possible)

• <Are there any workarounds we can provide to the customers?>

Fix Approaches

• <If we decide to fix this bug, how will we do it?>

Acceptance Criteria

• ...

Definition of Done

• Code Complete:
  • All code has been written, reviewed, and approved.
• Tested:
  • Unit tests have been written and passed.
  • Ensure code coverage is not reduced with the changes.
  • Integration tests have been automated.
  • System tests have been conducted, and all critical bugs have been fixed.
  • Tested and merged on OpenShift either upstream or downstream on a local build.
• Documentation:
  • User documentation or release notes have been written (if applicable).
• Build:
  • Code has been successfully built and integrated into the main repository / project.
  • Midstream changes (if applicable) are done, reviewed, approved and merged.
• Review:
  • Code has been peer-reviewed and meets coding standards.
  • All acceptance criteria defined in the user story have been met.
  • Tested by reviewer on OpenShift.
• Deployment:
  • The feature has been deployed on OpenShift cluster for testing.