openshift 4.13 - mongodb scc issue

[inzagod]

Describe the bug

hi all,
i want to fresh install microcks operator on my openshift 4.13 cluster but i have a scc mongodb issue !

oc logs my-microcksinstall-mongodb-6db9745d95-bjjgj
2024-09-11T09:19:45.964236742Z chown: changing ownership of '/proc/1/fd/1': Permission denied
2024-09-11T09:19:45.964403149Z chown: changing ownership of '/proc/1/fd/2': Permission denied
2024-09-11T09:19:45.992234071Z warning: initdb logs cannot write to '/proc/1/fd/1', so they are in '/var/lib/mongodb/data/docker-initdb.log' instead
2024-09-11T09:19:46.024305564Z about to fork child process, waiting until server is ready for connections.
2024-09-11T09:19:46.025472733Z forked process: 27
2024-09-11T09:19:46.026814392Z ERROR: child process failed, exited with 1
2024-09-11T09:19:46.026814392Z To see additional information in this output, start without the "--fork" option.

i have another cluster in 4.14 and after fresh install i have no issue
so i compare both

i saw in the 2 mongodb pods (dev cluster that is ok and prd cluster that is failed) that there is a difference with the scc :

DEV CLUSTER :

      drop:
        - ALL
    privileged: false
    runAsUser: 1000860000
    runAsNonRoot: true
    allowPrivilegeEscalation: false

PRD CLUSTER :

      drop:
        - MKNOD
    privileged: false

but if i compare deployments or replicatsets i don't see any differences with securitycontext
i don't understand where this scc is set ?

i saw a difference in annotations but i don't know where is it come from ?

DEV :

bash-4.4 ~ $ oc get pod my-microcksinstall-mongodb-64f5db9fff-9j87k -n microcks -o=jsonpath='{.metadata.annotations}'
{"k8s.v1.cni.cncf.io/network-status":"[{\n "name": "openshift-sdn",\n "interface": "eth0",\n "ips": [\n "10.244.9.243"\n ],\n "default": true,\n "dns": {}\n}]","openshift.io/scc":"restricted-v2","seccomp.security.alpha.kubernetes.io/pod":"runtime/default"}
PRD :

bash-4.4 ~ $ oc get pod my-microcksinstall-mongodb-6db9745d95-bjjgj -n microcks -o=jsonpath='{.metadata.annotations}'
{"k8s.v1.cni.cncf.io/network-status":"[{\n "name": "openshift-sdn",\n "interface": "eth0",\n "ips": [\n "10.243.15.46"\n ],\n "default": true,\n "dns": {}\n}]","openshift.io/scc":"anyuid"}

i opened a redhat case but they saw ythe scc difference too but they cannot tell me where it is set !!!!
can you tell me where can i set this scc difference or why i have this issue ?

thanks a lot for your help

ludo

Expected behavior

mongodb pod start fine without crashloopback off

Actual behavior

crashloopbackoff with error message :

2024-09-11T09:19:45.964236742Z chown: changing ownership of '/proc/1/fd/1': Permission denied
2024-09-11T09:19:45.964403149Z chown: changing ownership of '/proc/1/fd/2': Permission denied
2024-09-11T09:19:45.992234071Z warning: initdb logs cannot write to '/proc/1/fd/1', so they are in '/var/lib/mongodb/data/docker-initdb.log' instead
2024-09-11T09:19:46.024305564Z about to fork child process, waiting until server is ready for connections.
2024-09-11T09:19:46.025472733Z forked process: 27
2024-09-11T09:19:46.026814392Z ERROR: child process failed, exited with 1
2024-09-11T09:19:46.026814392Z To see additional information in this output, start without the "--fork" option.

How to Reproduce?

install the operator from scratch

Microcks version or git rev

1.10

Install method (docker-compose, helm chart, operator, docker-desktop extension,...)

openshift operator

Additional information

No response

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 30 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. Microcks is a Cloud Native Computing Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

[inzagod]

hi,

the issue is close but noone take a part of this issue !
it is a little bit embarrassing !
no comment !

[lbroudoux]

Hey there!

Sorry, but I have to admit, I have no clue on what could be the origin of this SCC difference...
We don't set any annotations on the MongoDB pod as you can see here: https://github.com/microcks/microcks-ansible-operator/blob/master/k8s/mongodb-deployment.yml#L29

IIRC SCC can be applied at the project service account level. Is there any chance your projects have different service account settings on the different clusters?

[inzagod]

Hi, I cannot explain to you what happens it was difficult to solve the issue so, while we had not many objects in our microcks UI, we decided to erase all and restart from scratch. For me, the problem was the operator has been automatically update and with the version 1.10 there is too many major change (postgres, keycloak, mongo) So, without manual action to migrate data, the operator failed ! Not sure that it will be use in the future from our dev team. Thanks a lot for your reply ***@***.*** Ludovic LACHEVRE Administrateur Systèmes 71 Quai colbert, 76600 Le Havre Tél. : +33 02 32 74 99 47 - Mob. : +33 07 63 99 39 42 www.spb.eu<http://www.spb.eu/> SAS au capital de 11 000 000 euros soumise au contrôle de l'ACPR. Siège social : 71, quai Colbert - CS 90000 - 76600 Le Havre. Tél. : +33 02 32 74 20 20 N° RCS 305 109 779 (Le Havre) - N°ORIAS 07 002 642 (www.orias.fr<http://www.orias.fr/>). Ce mail est à l'attention exclusive des destinataires désignés et peut contenir des informations confidentielles. Si vous le recevez par erreur, merci d'en informer sans délai l'expéditeur et de détruire l'email. C1 - Internal De : Laurent Broudoux ***@***.***> Envoyé : jeudi 17 octobre 2024 16:44 À : microcks/microcks-ansible-operator ***@***.***> Cc : Ludovic LACHEVRE ***@***.***>; Author ***@***.***> Objet : Re: [microcks/microcks-ansible-operator] openshift 4.13 - mongodb scc issue (Issue #134) IMPORTANT ! - Cet e-mail provient de l'extérieur de l'organisation. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de reconnaître l'expéditeur et de savoir que le contenu est sûr. // This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hey there! Sorry, but I have to admit, I have no clue on what could be the origin of this SCC difference... We don't set any annotations on the MongoDB pod as you can see here: https://github.com/microcks/microcks-ansible-operator/blob/master/k8s/mongodb-deployment.yml#L29 IIRC SCC can be applied at the project service account level. Is there any chance your projects have different service account settings on the different clusters? - Reply to this email directly, view it on GitHub<#134 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKFDGVC3ZFCU5WWAQ5LMGJLZ37EKFAVCNFSM6AAAAABOIW4UD2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJZG42DSNRUGE>. You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>>

[lbroudoux]

Yeah, the release of the latest version embeds a breaking upgrade for MongoDB. We did communicate that point in the release notes, explained how to prevent this and that external dependencies were provided for convenience purposes only (eg: out of our scope).

Unfortunately, some users didn't see notice messages and - as OpenShift Operators are in "automatic update mode" by default - fell into the trap. We're very sorry for that. We started working on a new operator few months ago (see https://github.com/microcks/microcks-operator) and this is some kind of pitfalls we want to avoid in the future.

That said, I think the upgrade failure is independent of the SCC issues you encounter ... Did you have a look at the default service account associated SCC in both projects and clusters?