tiagomistral commented on issue #466:
URL: https://github.com/apache/solr-operator/issues/466#issuecomment-6499834400
Thanks for the ping. I'm still hitting #466 on OpenShift with the default
`restricted-v2` SCC. On our operator (`0.9.1`), patching the SolrCloud with
`podSecurityContext: {}` still results in `fsGroup: 8983` on the StatefulSet.
Some data points on how the restricted profile lines up with OpenShift, from
a real SolrCloud (Solr 9.8.1, Helm chart 0.9.1):
- I set pod-level `runAsNonRoot: true` and `seccompProfile: RuntimeDefault`,
plus container-level `allowPrivilegeEscalation: false` and `capabilities.drop:
[ALL]`. `restricted-v2` accepted all of them. The only rejection was `fsGroup:
8983`. So the fields this PR defaults are compatible with the SCC.
- What `restricted-v2` does not accept is a hardcoded numeric ID. It only
accepts a `runAsUser` inside the namespace's `openshift.io/sa.scc.uid-range`,
and an `fsGroup` equal to the first ID of
`openshift.io/sa.scc.supplemental-groups`. Both are namespace-specific. As far
as I understand the SCC validation, the `runAsUser: 8983` default for the
busybox init containers (only generated with a volume backup repository) would
be rejected too, and the existing `fsGroup` default is exactly #466.
- With merge-over-defaults, a user cannot unset a numeric field such as
`fsGroup` or `runAsUser`, because omitted or empty means "use the default". So
for these two a dedicated opt-out would be needed, e.g. a boolean in
`podOptions` that skips the default IDs and lets the platform assign them. That
fits the "no platform detection" principle of this PR, since it is just "don't
set IDs", and it would also fix #466.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
