-
Bug
-
Resolution: Done
-
Critical
-
1.6.0, 1.4.11, 1.5.5
-
5
-
False
-
None
-
False
-
Previous GitOps releases were affected by an issue with dex pods failing with CreateContainerConfigError when a SCC of 'anyuid' is assigned to the dex serviceAccount. This issue is fixed by assigning a default user id to the dex container.
-
GITOPS Sprint 223, GITOPS Sprint 224
Reliably (3 times now), using the following repo and branch:
https://github.com/mhjacks/multicloud-gitops/tree/repro-dex-failure
(Installing the pattern, by running `make install` on a fresh cluster)
The dex pod in the multicloud-gitops-hub namespace will fail to come up:
container has runAsNonRoot and image will run as root (pod: "hub-gitops-dex-server-68bfc4bf9-656k7_multicloud-gitops-hub(ea242591-5b38-4c8b-b4c5-d4dd04144ebf)", container: dex)
The same manifests will apply without error on Gitops 1.5.
The cluster-scoped installation dex pod in openshift-gitops comes up without error and works for Oauth with the default cluster-admin account.
Cluster-scoped dex pod securityContext:
```
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL
- KILL
- MKNOD
- SETGID
- SETUID
runAsNonRoot: true
runAsUser: 1000650000
```
non-cluster-scoped securityContext:
```
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL
- MKNOD
runAsNonRoot: true
```
- links to
- mentioned on
[GITOPS-2235] OCP < 4.11: Dex pod in less privileged namespace fails to come up, citing containerconfigerror
GitLab CEE Bot
added a comment - rjeczkow mentioned this issue in a merge request of gitops / operator-e2e on branch cherry-pick-610cd13e-3:
GITOPS-2235Dex pod in less privileged namespace fails to come up
GitLab CEE Bot
added a comment - rjeczkow mentioned this issue in a merge request of gitops / operator-e2e on branch cherry-pick-610cd13e-3 : GITOPS-2235 Dex pod in less privileged namespace fails to come up GitLab CEE Bot
added a comment - rjeczkow mentioned this issue in a merge request of gitops / operator-e2e on branch cherry-pick-610cd13e-2:
GITOPS-2235Dex pod in less privileged namespace fails to come up
GitLab CEE Bot
added a comment - rjeczkow mentioned this issue in a merge request of gitops / operator-e2e on branch cherry-pick-610cd13e-2 : GITOPS-2235 Dex pod in less privileged namespace fails to come up GitLab CEE Bot
added a comment - rjeczkow mentioned this issue in a merge request of gitops / operator-e2e on branch cherry-pick-610cd13e:
GITOPS-2235Dex pod in less privileged namespace fails to come up
GitLab CEE Bot
added a comment - rjeczkow mentioned this issue in a merge request of gitops / operator-e2e on branch cherry-pick-610cd13e : GITOPS-2235 Dex pod in less privileged namespace fails to come up GitLab CEE Bot
added a comment - rjeczkow mentioned this issue in a merge request of gitops / operator-e2e on branch cherry_pick_dex:
GITOPS-2235Dex pod in less privileged namespace fails to come up
GitLab CEE Bot
added a comment - rjeczkow mentioned this issue in a merge request of gitops / operator-e2e on branch cherry_pick_dex : GITOPS-2235 Dex pod in less privileged namespace fails to come up wtam_at_redhat Since this bug was affecting only gitops >= 1.5.5 I guedd the '1.4.12' fix version is not needed here
GitLab CEE Bot
added a comment - rjeczkow mentioned this issue in a merge request of gitops / operator-e2e on branch validate_dex:
GITOPS-2235Dex pod in less privileged namespace fails to come up
GitLab CEE Bot
added a comment - rjeczkow mentioned this issue in a merge request of gitops / operator-e2e on branch validate_dex : GITOPS-2235 Dex pod in less privileged namespace fails to come up rjeczkow
I was able to verify the fix by doing the following:
on a 1.6.0 operator installation:
- install operator
- create a namespace scoped argo-cd instance with dex enabled and make sure it comes up
- `run oc adm policy add-scc-to-user anyuid -z argocd-argocd-dex-server -n test` to grant the dex service account an anyuid SCC
- delete the dex pod and wait for it to come back
- dex pod fails with `CreateContainerConfigError`
on installing 1.6.1 operator build containing fix, and performing the same steps the dex pod was able to come up despite the anyuid SCC being assigned to the serviceaccount
jrao@redhat.com hey, we'd like to add an e2e test case for this bug fix. What would be the steps to reproduce the issue ?
Thanks
rjeczkow mentioned this issue in a merge request of gitops / operator-e2e on branch cherry-pick-610cd13e-3: