Add restrictive security context to registry pod and init containers - #7040
Open
kaovilai wants to merge 1 commit into
Open
Add restrictive security context to registry pod and init containers#7040kaovilai wants to merge 1 commit into
kaovilai wants to merge 1 commit into
Conversation
kaovilai
force-pushed
the
secContextInitContainer
branch
from
January 16, 2026 10:30
79fd63e to
e9a876b
Compare
There was a problem hiding this comment.
Pull request overview
This PR enhances security by applying restrictive security contexts to init containers in the FBC registry pod, addressing issue #7039. Previously, only the main container received the restrictive security context when the --security-context-config=restricted flag was used.
Changes:
- Refactored security context creation into a reusable variable
- Added security context application to all init containers in the FBC registry pod
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+163
to
+166
| // Update all init containers with the same restrictive security context | ||
| for i := range f.pod.Spec.InitContainers { | ||
| f.pod.Spec.InitContainers[i].SecurityContext = restrictedSecurityContext | ||
| } |
There was a problem hiding this comment.
The new functionality that applies the restrictive security context to init containers lacks test coverage. The test file fbc_registry_pod_test.go has comprehensive tests for other functionality but does not verify that init containers receive the security context when SecurityContext is set to 'restricted'. Consider adding a test case that creates an FBCRegistryPod with SecurityContext: 'restricted' and verifies that both the main container and init containers have the expected security context settings.
Contributor
There was a problem hiding this comment.
@kaovilai Would you mind adding a test for this?
Contributor
Author
|
Those with similar issue and cannot wait for this PR can copy openshift/oadp-operator#2078 |
Contributor
|
@kaovilai Could you rebase this pr? |
Fixes operator-framework#7039 Signed-off-by: Tiger Kaovilai <passawit.kaovilai@gmail.com> Add changelog fragment for init container security context fix Signed-off-by: Tiger Kaovilai <passawit.kaovilai@gmail.com> Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
kaovilai
force-pushed
the
secContextInitContainer
branch
from
March 12, 2026 15:09
e9a876b to
5daef89
Compare
Contributor
Author
|
dun dun dun! |
kaovilai
added a commit
to kaovilai/release
that referenced
this pull request
Aug 12, 2026
…isk) operator-sdk run bundle spins up its own registry/grpc pod to serve the bundle to OLM, and that pod's containers don't reliably get a PodSecurity "restricted"-compliant securityContext on all containers even with --security-context-config=restricted passed (operator-framework/operator-sdk#7040, open upstream). oadp-operator's own team hit this deterministically on OCP 4.21 and abandoned operator-sdk run bundle entirely in their own deploy-olm Makefile target (openshift/oadp-operator#2078), switching to a real opm catalog + CatalogSource (with grpcPodConfig.securityContextConfig: restricted) + OperatorGroup + Subscription instead -- exactly what this repo's optional-operators-subscribe step already implements correctly. Add a new step-registry step, optional-operators-opm-index-from-bundle, that builds a fresh opm sqlite index from an already-promoted bundle image (OO_BUNDLE) using opm index add + rootless umoci/skopeo assembly (no podman/buildah, no daemon), pushes it to this job's own namespace on the CI registry (reachable externally for the job's lifetime, same profile OO_BUNDLE itself already proves works), and writes the resulting pullspec to ${SHARED_DIR}/oo-index-pullspec. Patch optional-operators-subscribe-commands.sh to read that file as an OO_INDEX override, mirroring its existing SHARED_DIR override pattern for OO_INSTALL_NAMESPACE -- fully backward compatible for every other current consumer of this step. Switch the 4 KDM (kubevirt-datamover-controller/plugin x oadp-dev/1.6) consuming configs from optional-operators-operator-sdk-non-ci-bundle-image back to optional-operators-subscribe, restoring OO_PACKAGE/OO_CHANNEL/ OO_TARGET_NAMESPACES from the original pre-operator-sdk-pivot config. Revert set-related-image's Subscription discovery to read ${SHARED_DIR}/oo-subscription directly, since optional-operators-subscribe (unlike operator-sdk run bundle) already writes it. A placeholder `dependencies: {OO_INDEX: src}` is needed in each config purely to satisfy ci-operator's static validation of optional-operators-subscribe-ref.yaml's own declared `ci-index` dependency -- the actual value is overwritten by the SHARED_DIR read above before use. Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
kaovilai
added a commit
to kaovilai/release
that referenced
this pull request
Aug 12, 2026
…isk) operator-sdk run bundle spins up its own registry/grpc pod to serve the bundle to OLM, and that pod's containers don't reliably get a PodSecurity "restricted"-compliant securityContext on all containers even with --security-context-config=restricted passed (operator-framework/operator-sdk#7040, open upstream). oadp-operator's own team hit this deterministically on OCP 4.21 and abandoned operator-sdk run bundle entirely in their own deploy-olm Makefile target (openshift/oadp-operator#2078), switching to a real opm catalog + CatalogSource (with grpcPodConfig.securityContextConfig: restricted) + OperatorGroup + Subscription instead -- exactly what this repo's optional-operators-subscribe step already implements correctly. Add a new step-registry step, optional-operators-opm-index-from-bundle, that builds a fresh opm sqlite index from an already-promoted bundle image (OO_BUNDLE) using opm index add + rootless umoci/skopeo assembly (no podman/buildah, no daemon), pushes it to this job's own namespace on the CI registry (reachable externally for the job's lifetime, same profile OO_BUNDLE itself already proves works), and writes the resulting pullspec to ${SHARED_DIR}/oo-index-pullspec. Patch optional-operators-subscribe-commands.sh to read that file as an OO_INDEX override, mirroring its existing SHARED_DIR override pattern for OO_INSTALL_NAMESPACE -- fully backward compatible for every other current consumer of this step. Switch the 4 KDM (kubevirt-datamover-controller/plugin x oadp-dev/1.6) consuming configs from optional-operators-operator-sdk-non-ci-bundle-image back to optional-operators-subscribe, restoring OO_PACKAGE/OO_CHANNEL/ OO_TARGET_NAMESPACES from the original pre-operator-sdk-pivot config. Revert set-related-image's Subscription discovery to read ${SHARED_DIR}/oo-subscription directly, since optional-operators-subscribe (unlike operator-sdk run bundle) already writes it. A placeholder `dependencies: {OO_INDEX: src}` is needed in each config purely to satisfy ci-operator's static validation of optional-operators-subscribe-ref.yaml's own declared `ci-index` dependency -- the actual value is overwritten by the SHARED_DIR read above before use. Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
kaovilai
added a commit
to kaovilai/release
that referenced
this pull request
Aug 12, 2026
…isk) operator-sdk run bundle spins up its own registry/grpc pod to serve the bundle to OLM, and that pod's containers don't reliably get a PodSecurity "restricted"-compliant securityContext on all containers even with --security-context-config=restricted passed (operator-framework/operator-sdk#7040, open upstream). oadp-operator's own team hit this deterministically on OCP 4.21 and abandoned operator-sdk run bundle entirely in their own deploy-olm Makefile target (openshift/oadp-operator#2078), switching to a real opm catalog + CatalogSource (with grpcPodConfig.securityContextConfig: restricted) + OperatorGroup + Subscription instead -- exactly what this repo's optional-operators-subscribe step already implements correctly. Add a new step-registry step, optional-operators-opm-index-from-bundle, that builds a fresh opm sqlite index from an already-promoted bundle image (OO_BUNDLE) using opm index add + rootless umoci/skopeo assembly (no podman/buildah, no daemon), pushes it to this job's own namespace on the CI registry (reachable externally for the job's lifetime, same profile OO_BUNDLE itself already proves works), and writes the resulting pullspec to ${SHARED_DIR}/oo-index-pullspec. Patch optional-operators-subscribe-commands.sh to read that file as an OO_INDEX override, mirroring its existing SHARED_DIR override pattern for OO_INSTALL_NAMESPACE -- fully backward compatible for every other current consumer of this step. Switch the 4 KDM (kubevirt-datamover-controller/plugin x oadp-dev/1.6) consuming configs from optional-operators-operator-sdk-non-ci-bundle-image back to optional-operators-subscribe, restoring OO_PACKAGE/OO_CHANNEL/ OO_TARGET_NAMESPACES from the original pre-operator-sdk-pivot config. Revert set-related-image's Subscription discovery to read ${SHARED_DIR}/oo-subscription directly, since optional-operators-subscribe (unlike operator-sdk run bundle) already writes it. A placeholder `dependencies: {OO_INDEX: src}` is needed in each config purely to satisfy ci-operator's static validation of optional-operators-subscribe-ref.yaml's own declared `ci-index` dependency -- the actual value is overwritten by the SHARED_DIR read above before use. Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
kaovilai
added a commit
to kaovilai/release
that referenced
this pull request
Aug 12, 2026
…isk) operator-sdk run bundle spins up its own registry/grpc pod to serve the bundle to OLM, and that pod's containers don't reliably get a PodSecurity "restricted"-compliant securityContext on all containers even with --security-context-config=restricted passed (operator-framework/operator-sdk#7040, open upstream). oadp-operator's own team hit this deterministically on OCP 4.21 and abandoned operator-sdk run bundle entirely in their own deploy-olm Makefile target (openshift/oadp-operator#2078), switching to a real opm catalog + CatalogSource (with grpcPodConfig.securityContextConfig: restricted) + OperatorGroup + Subscription instead -- exactly what this repo's optional-operators-subscribe step already implements correctly. Add a new step-registry step, optional-operators-opm-index-from-bundle, that builds a fresh opm sqlite index from an already-promoted bundle image (OO_BUNDLE) using opm index add + rootless umoci/skopeo assembly (no podman/buildah, no daemon), pushes it to this job's own namespace on the CI registry (reachable externally for the job's lifetime, same profile OO_BUNDLE itself already proves works), and writes the resulting pullspec to ${SHARED_DIR}/oo-index-pullspec. Patch optional-operators-subscribe-commands.sh to read that file as an OO_INDEX override, mirroring its existing SHARED_DIR override pattern for OO_INSTALL_NAMESPACE -- fully backward compatible for every other current consumer of this step. Switch the 4 KDM (kubevirt-datamover-controller/plugin x oadp-dev/1.6) consuming configs from optional-operators-operator-sdk-non-ci-bundle-image back to optional-operators-subscribe, restoring OO_PACKAGE/OO_CHANNEL/ OO_TARGET_NAMESPACES from the original pre-operator-sdk-pivot config. Revert set-related-image's Subscription discovery to read ${SHARED_DIR}/oo-subscription directly, since optional-operators-subscribe (unlike operator-sdk run bundle) already writes it. A placeholder `dependencies: {OO_INDEX: src}` is needed in each config purely to satisfy ci-operator's static validation of optional-operators-subscribe-ref.yaml's own declared `ci-index` dependency -- the actual value is overwritten by the SHARED_DIR read above before use. Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
kaovilai
added a commit
to kaovilai/release
that referenced
this pull request
Aug 12, 2026
…isk) operator-sdk run bundle spins up its own registry/grpc pod to serve the bundle to OLM, and that pod's containers don't reliably get a PodSecurity "restricted"-compliant securityContext on all containers even with --security-context-config=restricted passed (operator-framework/operator-sdk#7040, open upstream). oadp-operator's own team hit this deterministically on OCP 4.21 and abandoned operator-sdk run bundle entirely in their own deploy-olm Makefile target (openshift/oadp-operator#2078), switching to a real opm catalog + CatalogSource (with grpcPodConfig.securityContextConfig: restricted) + OperatorGroup + Subscription instead -- exactly what this repo's optional-operators-subscribe step already implements correctly. Add a new step-registry step, optional-operators-opm-index-from-bundle, that builds a fresh opm sqlite index from an already-promoted bundle image (OO_BUNDLE) using opm index add + rootless umoci/skopeo assembly (no podman/buildah, no daemon), pushes it to this job's own namespace on the CI registry (reachable externally for the job's lifetime, same profile OO_BUNDLE itself already proves works), and writes the resulting pullspec to ${SHARED_DIR}/oo-index-pullspec. Patch optional-operators-subscribe-commands.sh to read that file as an OO_INDEX override, mirroring its existing SHARED_DIR override pattern for OO_INSTALL_NAMESPACE -- fully backward compatible for every other current consumer of this step. Switch the 4 KDM (kubevirt-datamover-controller/plugin x oadp-dev/1.6) consuming configs from optional-operators-operator-sdk-non-ci-bundle-image back to optional-operators-subscribe, restoring OO_PACKAGE/OO_CHANNEL/ OO_TARGET_NAMESPACES from the original pre-operator-sdk-pivot config. Revert set-related-image's Subscription discovery to read ${SHARED_DIR}/oo-subscription directly, since optional-operators-subscribe (unlike operator-sdk run bundle) already writes it. A placeholder `dependencies: {OO_INDEX: src}` is needed in each config purely to satisfy ci-operator's static validation of optional-operators-subscribe-ref.yaml's own declared `ci-index` dependency -- the actual value is overwritten by the SHARED_DIR read above before use. Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
kaovilai
added a commit
to kaovilai/release
that referenced
this pull request
Aug 12, 2026
…isk) operator-sdk run bundle spins up its own registry/grpc pod to serve the bundle to OLM, and that pod's containers don't reliably get a PodSecurity "restricted"-compliant securityContext on all containers even with --security-context-config=restricted passed (operator-framework/operator-sdk#7040, open upstream). oadp-operator's own team hit this deterministically on OCP 4.21 and abandoned operator-sdk run bundle entirely in their own deploy-olm Makefile target (openshift/oadp-operator#2078), switching to a real opm catalog + CatalogSource (with grpcPodConfig.securityContextConfig: restricted) + OperatorGroup + Subscription instead -- exactly what this repo's optional-operators-subscribe step already implements correctly. Add a new step-registry step, optional-operators-opm-index-from-bundle, that builds a fresh opm sqlite index from an already-promoted bundle image (OO_BUNDLE) using opm index add + rootless umoci/skopeo assembly (no podman/buildah, no daemon), pushes it to this job's own namespace on the CI registry (reachable externally for the job's lifetime, same profile OO_BUNDLE itself already proves works), and writes the resulting pullspec to ${SHARED_DIR}/oo-index-pullspec. Patch optional-operators-subscribe-commands.sh to read that file as an OO_INDEX override, mirroring its existing SHARED_DIR override pattern for OO_INSTALL_NAMESPACE -- fully backward compatible for every other current consumer of this step. Switch the 4 KDM (kubevirt-datamover-controller/plugin x oadp-dev/1.6) consuming configs from optional-operators-operator-sdk-non-ci-bundle-image back to optional-operators-subscribe, restoring OO_PACKAGE/OO_CHANNEL/ OO_TARGET_NAMESPACES from the original pre-operator-sdk-pivot config. Revert set-related-image's Subscription discovery to read ${SHARED_DIR}/oo-subscription directly, since optional-operators-subscribe (unlike operator-sdk run bundle) already writes it. A placeholder `dependencies: {OO_INDEX: src}` is needed in each config purely to satisfy ci-operator's static validation of optional-operators-subscribe-ref.yaml's own declared `ci-index` dependency -- the actual value is overwritten by the SHARED_DIR read above before use. Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
kaovilai
added a commit
to kaovilai/release
that referenced
this pull request
Aug 12, 2026
…isk) operator-sdk run bundle spins up its own registry/grpc pod to serve the bundle to OLM, and that pod's containers don't reliably get a PodSecurity "restricted"-compliant securityContext on all containers even with --security-context-config=restricted passed (operator-framework/operator-sdk#7040, open upstream). oadp-operator's own team hit this deterministically on OCP 4.21 and abandoned operator-sdk run bundle entirely in their own deploy-olm Makefile target (openshift/oadp-operator#2078), switching to a real opm catalog + CatalogSource (with grpcPodConfig.securityContextConfig: restricted) + OperatorGroup + Subscription instead -- exactly what this repo's optional-operators-subscribe step already implements correctly. Add a new step-registry step, optional-operators-opm-index-from-bundle, that builds a fresh opm sqlite index from an already-promoted bundle image (OO_BUNDLE) using opm index add + rootless umoci/skopeo assembly (no podman/buildah, no daemon), pushes it to this job's own namespace on the CI registry (reachable externally for the job's lifetime, same profile OO_BUNDLE itself already proves works), and writes the resulting pullspec to ${SHARED_DIR}/oo-index-pullspec. Patch optional-operators-subscribe-commands.sh to read that file as an OO_INDEX override, mirroring its existing SHARED_DIR override pattern for OO_INSTALL_NAMESPACE -- fully backward compatible for every other current consumer of this step. Switch the 4 KDM (kubevirt-datamover-controller/plugin x oadp-dev/1.6) consuming configs from optional-operators-operator-sdk-non-ci-bundle-image back to optional-operators-subscribe, restoring OO_PACKAGE/OO_CHANNEL/ OO_TARGET_NAMESPACES from the original pre-operator-sdk-pivot config. Revert set-related-image's Subscription discovery to read ${SHARED_DIR}/oo-subscription directly, since optional-operators-subscribe (unlike operator-sdk run bundle) already writes it. A placeholder `dependencies: {OO_INDEX: src}` is needed in each config purely to satisfy ci-operator's static validation of optional-operators-subscribe-ref.yaml's own declared `ci-index` dependency -- the actual value is overwritten by the SHARED_DIR read above before use. Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
kaovilai
added a commit
to kaovilai/release
that referenced
this pull request
Aug 12, 2026
…isk) operator-sdk run bundle spins up its own registry/grpc pod to serve the bundle to OLM, and that pod's containers don't reliably get a PodSecurity "restricted"-compliant securityContext on all containers even with --security-context-config=restricted passed (operator-framework/operator-sdk#7040, open upstream). oadp-operator's own team hit this deterministically on OCP 4.21 and abandoned operator-sdk run bundle entirely in their own deploy-olm Makefile target (openshift/oadp-operator#2078), switching to a real opm catalog + CatalogSource (with grpcPodConfig.securityContextConfig: restricted) + OperatorGroup + Subscription instead -- exactly what this repo's optional-operators-subscribe step already implements correctly. Add a new step-registry step, optional-operators-opm-index-from-bundle, that builds a fresh opm sqlite index from an already-promoted bundle image (OO_BUNDLE) using opm index add + rootless umoci/skopeo assembly (no podman/buildah, no daemon), pushes it to this job's own namespace on the CI registry (reachable externally for the job's lifetime, same profile OO_BUNDLE itself already proves works), and writes the resulting pullspec to ${SHARED_DIR}/oo-index-pullspec. Patch optional-operators-subscribe-commands.sh to read that file as an OO_INDEX override, mirroring its existing SHARED_DIR override pattern for OO_INSTALL_NAMESPACE -- fully backward compatible for every other current consumer of this step. Switch the 4 KDM (kubevirt-datamover-controller/plugin x oadp-dev/1.6) consuming configs from optional-operators-operator-sdk-non-ci-bundle-image back to optional-operators-subscribe, restoring OO_PACKAGE/OO_CHANNEL/ OO_TARGET_NAMESPACES from the original pre-operator-sdk-pivot config. Revert set-related-image's Subscription discovery to read ${SHARED_DIR}/oo-subscription directly, since optional-operators-subscribe (unlike operator-sdk run bundle) already writes it. A placeholder `dependencies: {OO_INDEX: src}` is needed in each config purely to satisfy ci-operator's static validation of optional-operators-subscribe-ref.yaml's own declared `ci-index` dependency -- the actual value is overwritten by the SHARED_DIR read above before use. Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
kaovilai
added a commit
to kaovilai/release
that referenced
this pull request
Aug 12, 2026
…isk) operator-sdk run bundle spins up its own registry/grpc pod to serve the bundle to OLM, and that pod's containers don't reliably get a PodSecurity "restricted"-compliant securityContext on all containers even with --security-context-config=restricted passed (operator-framework/operator-sdk#7040, open upstream). oadp-operator's own team hit this deterministically on OCP 4.21 and abandoned operator-sdk run bundle entirely in their own deploy-olm Makefile target (openshift/oadp-operator#2078), switching to a real opm catalog + CatalogSource (with grpcPodConfig.securityContextConfig: restricted) + OperatorGroup + Subscription instead -- exactly what this repo's optional-operators-subscribe step already implements correctly. Add a new step-registry step, optional-operators-opm-index-from-bundle, that builds a fresh opm sqlite index from an already-promoted bundle image (OO_BUNDLE) using opm index add + rootless umoci/skopeo assembly (no podman/buildah, no daemon), pushes it to this job's own namespace on the CI registry (reachable externally for the job's lifetime, same profile OO_BUNDLE itself already proves works), and writes the resulting pullspec to ${SHARED_DIR}/oo-index-pullspec. Patch optional-operators-subscribe-commands.sh to read that file as an OO_INDEX override, mirroring its existing SHARED_DIR override pattern for OO_INSTALL_NAMESPACE -- fully backward compatible for every other current consumer of this step. Switch the 4 KDM (kubevirt-datamover-controller/plugin x oadp-dev/1.6) consuming configs from optional-operators-operator-sdk-non-ci-bundle-image back to optional-operators-subscribe, restoring OO_PACKAGE/OO_CHANNEL/ OO_TARGET_NAMESPACES from the original pre-operator-sdk-pivot config. Revert set-related-image's Subscription discovery to read ${SHARED_DIR}/oo-subscription directly, since optional-operators-subscribe (unlike operator-sdk run bundle) already writes it. A placeholder `dependencies: {OO_INDEX: src}` is needed in each config purely to satisfy ci-operator's static validation of optional-operators-subscribe-ref.yaml's own declared `ci-index` dependency -- the actual value is overwritten by the SHARED_DIR read above before use. Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
kaovilai
added a commit
to kaovilai/release
that referenced
this pull request
Aug 13, 2026
…isk) operator-sdk run bundle spins up its own registry/grpc pod to serve the bundle to OLM, and that pod's containers don't reliably get a PodSecurity "restricted"-compliant securityContext on all containers even with --security-context-config=restricted passed (operator-framework/operator-sdk#7040, open upstream). oadp-operator's own team hit this deterministically on OCP 4.21 and abandoned operator-sdk run bundle entirely in their own deploy-olm Makefile target (openshift/oadp-operator#2078), switching to a real opm catalog + CatalogSource (with grpcPodConfig.securityContextConfig: restricted) + OperatorGroup + Subscription instead -- exactly what this repo's optional-operators-subscribe step already implements correctly. Add a new step-registry step, optional-operators-opm-index-from-bundle, that builds a fresh opm sqlite index from an already-promoted bundle image (OO_BUNDLE) using opm index add + rootless umoci/skopeo assembly (no podman/buildah, no daemon), pushes it to this job's own namespace on the CI registry (reachable externally for the job's lifetime, same profile OO_BUNDLE itself already proves works), and writes the resulting pullspec to ${SHARED_DIR}/oo-index-pullspec. Patch optional-operators-subscribe-commands.sh to read that file as an OO_INDEX override, mirroring its existing SHARED_DIR override pattern for OO_INSTALL_NAMESPACE -- fully backward compatible for every other current consumer of this step. Switch the 4 KDM (kubevirt-datamover-controller/plugin x oadp-dev/1.6) consuming configs from optional-operators-operator-sdk-non-ci-bundle-image back to optional-operators-subscribe, restoring OO_PACKAGE/OO_CHANNEL/ OO_TARGET_NAMESPACES from the original pre-operator-sdk-pivot config. Revert set-related-image's Subscription discovery to read ${SHARED_DIR}/oo-subscription directly, since optional-operators-subscribe (unlike operator-sdk run bundle) already writes it. A placeholder `dependencies: {OO_INDEX: src}` is needed in each config purely to satisfy ci-operator's static validation of optional-operators-subscribe-ref.yaml's own declared `ci-index` dependency -- the actual value is overwritten by the SHARED_DIR read above before use. Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
kaovilai
added a commit
to kaovilai/release
that referenced
this pull request
Aug 15, 2026
…isk) operator-sdk run bundle spins up its own registry/grpc pod to serve the bundle to OLM, and that pod's containers don't reliably get a PodSecurity "restricted"-compliant securityContext on all containers even with --security-context-config=restricted passed (operator-framework/operator-sdk#7040, open upstream). oadp-operator's own team hit this deterministically on OCP 4.21 and abandoned operator-sdk run bundle entirely in their own deploy-olm Makefile target (openshift/oadp-operator#2078), switching to a real opm catalog + CatalogSource (with grpcPodConfig.securityContextConfig: restricted) + OperatorGroup + Subscription instead -- exactly what this repo's optional-operators-subscribe step already implements correctly. Add a new step-registry step, optional-operators-opm-index-from-bundle, that builds a fresh opm sqlite index from an already-promoted bundle image (OO_BUNDLE) using opm index add + rootless umoci/skopeo assembly (no podman/buildah, no daemon), pushes it to this job's own namespace on the CI registry (reachable externally for the job's lifetime, same profile OO_BUNDLE itself already proves works), and writes the resulting pullspec to ${SHARED_DIR}/oo-index-pullspec. Patch optional-operators-subscribe-commands.sh to read that file as an OO_INDEX override, mirroring its existing SHARED_DIR override pattern for OO_INSTALL_NAMESPACE -- fully backward compatible for every other current consumer of this step. Switch the 4 KDM (kubevirt-datamover-controller/plugin x oadp-dev/1.6) consuming configs from optional-operators-operator-sdk-non-ci-bundle-image back to optional-operators-subscribe, restoring OO_PACKAGE/OO_CHANNEL/ OO_TARGET_NAMESPACES from the original pre-operator-sdk-pivot config. Revert set-related-image's Subscription discovery to read ${SHARED_DIR}/oo-subscription directly, since optional-operators-subscribe (unlike operator-sdk run bundle) already writes it. A placeholder `dependencies: {OO_INDEX: src}` is needed in each config purely to satisfy ci-operator's static validation of optional-operators-subscribe-ref.yaml's own declared `ci-index` dependency -- the actual value is overwritten by the SHARED_DIR read above before use. Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
kaovilai
added a commit
to kaovilai/release
that referenced
this pull request
Aug 15, 2026
…isk) operator-sdk run bundle spins up its own registry/grpc pod to serve the bundle to OLM, and that pod's containers don't reliably get a PodSecurity "restricted"-compliant securityContext on all containers even with --security-context-config=restricted passed (operator-framework/operator-sdk#7040, open upstream). oadp-operator's own team hit this deterministically on OCP 4.21 and abandoned operator-sdk run bundle entirely in their own deploy-olm Makefile target (openshift/oadp-operator#2078), switching to a real opm catalog + CatalogSource (with grpcPodConfig.securityContextConfig: restricted) + OperatorGroup + Subscription instead -- exactly what this repo's optional-operators-subscribe step already implements correctly. Add a new step-registry step, optional-operators-opm-index-from-bundle, that builds a fresh opm sqlite index from an already-promoted bundle image (OO_BUNDLE) using opm index add + rootless umoci/skopeo assembly (no podman/buildah, no daemon), pushes it to this job's own namespace on the CI registry (reachable externally for the job's lifetime, same profile OO_BUNDLE itself already proves works), and writes the resulting pullspec to ${SHARED_DIR}/oo-index-pullspec. Patch optional-operators-subscribe-commands.sh to read that file as an OO_INDEX override, mirroring its existing SHARED_DIR override pattern for OO_INSTALL_NAMESPACE -- fully backward compatible for every other current consumer of this step. Switch the 4 KDM (kubevirt-datamover-controller/plugin x oadp-dev/1.6) consuming configs from optional-operators-operator-sdk-non-ci-bundle-image back to optional-operators-subscribe, restoring OO_PACKAGE/OO_CHANNEL/ OO_TARGET_NAMESPACES from the original pre-operator-sdk-pivot config. Revert set-related-image's Subscription discovery to read ${SHARED_DIR}/oo-subscription directly, since optional-operators-subscribe (unlike operator-sdk run bundle) already writes it. A placeholder `dependencies: {OO_INDEX: src}` is needed in each config purely to satisfy ci-operator's static validation of optional-operators-subscribe-ref.yaml's own declared `ci-index` dependency -- the actual value is overwritten by the SHARED_DIR read above before use. Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
kaovilai
added a commit
to kaovilai/release
that referenced
this pull request
Aug 15, 2026
…isk) operator-sdk run bundle spins up its own registry/grpc pod to serve the bundle to OLM, and that pod's containers don't reliably get a PodSecurity "restricted"-compliant securityContext on all containers even with --security-context-config=restricted passed (operator-framework/operator-sdk#7040, open upstream). oadp-operator's own team hit this deterministically on OCP 4.21 and abandoned operator-sdk run bundle entirely in their own deploy-olm Makefile target (openshift/oadp-operator#2078), switching to a real opm catalog + CatalogSource (with grpcPodConfig.securityContextConfig: restricted) + OperatorGroup + Subscription instead -- exactly what this repo's optional-operators-subscribe step already implements correctly. Add a new step-registry step, optional-operators-opm-index-from-bundle, that builds a fresh opm sqlite index from an already-promoted bundle image (OO_BUNDLE) using opm index add + rootless umoci/skopeo assembly (no podman/buildah, no daemon), pushes it to this job's own namespace on the CI registry (reachable externally for the job's lifetime, same profile OO_BUNDLE itself already proves works), and writes the resulting pullspec to ${SHARED_DIR}/oo-index-pullspec. Patch optional-operators-subscribe-commands.sh to read that file as an OO_INDEX override, mirroring its existing SHARED_DIR override pattern for OO_INSTALL_NAMESPACE -- fully backward compatible for every other current consumer of this step. Switch the 4 KDM (kubevirt-datamover-controller/plugin x oadp-dev/1.6) consuming configs from optional-operators-operator-sdk-non-ci-bundle-image back to optional-operators-subscribe, restoring OO_PACKAGE/OO_CHANNEL/ OO_TARGET_NAMESPACES from the original pre-operator-sdk-pivot config. Revert set-related-image's Subscription discovery to read ${SHARED_DIR}/oo-subscription directly, since optional-operators-subscribe (unlike operator-sdk run bundle) already writes it. A placeholder `dependencies: {OO_INDEX: src}` is needed in each config purely to satisfy ci-operator's static validation of optional-operators-subscribe-ref.yaml's own declared `ci-index` dependency -- the actual value is overwritten by the SHARED_DIR read above before use. Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
kaovilai
added a commit
to kaovilai/release
that referenced
this pull request
Aug 15, 2026
…isk) operator-sdk run bundle spins up its own registry/grpc pod to serve the bundle to OLM, and that pod's containers don't reliably get a PodSecurity "restricted"-compliant securityContext on all containers even with --security-context-config=restricted passed (operator-framework/operator-sdk#7040, open upstream). oadp-operator's own team hit this deterministically on OCP 4.21 and abandoned operator-sdk run bundle entirely in their own deploy-olm Makefile target (openshift/oadp-operator#2078), switching to a real opm catalog + CatalogSource (with grpcPodConfig.securityContextConfig: restricted) + OperatorGroup + Subscription instead -- exactly what this repo's optional-operators-subscribe step already implements correctly. Add a new step-registry step, optional-operators-opm-index-from-bundle, that builds a fresh opm sqlite index from an already-promoted bundle image (OO_BUNDLE) using opm index add + rootless umoci/skopeo assembly (no podman/buildah, no daemon), pushes it to this job's own namespace on the CI registry (reachable externally for the job's lifetime, same profile OO_BUNDLE itself already proves works), and writes the resulting pullspec to ${SHARED_DIR}/oo-index-pullspec. Patch optional-operators-subscribe-commands.sh to read that file as an OO_INDEX override, mirroring its existing SHARED_DIR override pattern for OO_INSTALL_NAMESPACE -- fully backward compatible for every other current consumer of this step. Switch the 4 KDM (kubevirt-datamover-controller/plugin x oadp-dev/1.6) consuming configs from optional-operators-operator-sdk-non-ci-bundle-image back to optional-operators-subscribe, restoring OO_PACKAGE/OO_CHANNEL/ OO_TARGET_NAMESPACES from the original pre-operator-sdk-pivot config. Revert set-related-image's Subscription discovery to read ${SHARED_DIR}/oo-subscription directly, since optional-operators-subscribe (unlike operator-sdk run bundle) already writes it. A placeholder `dependencies: {OO_INDEX: src}` is needed in each config purely to satisfy ci-operator's static validation of optional-operators-subscribe-ref.yaml's own declared `ci-index` dependency -- the actual value is overwritten by the SHARED_DIR read above before use. Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
kaovilai
added a commit
to kaovilai/release
that referenced
this pull request
Aug 16, 2026
…isk) operator-sdk run bundle spins up its own registry/grpc pod to serve the bundle to OLM, and that pod's containers don't reliably get a PodSecurity "restricted"-compliant securityContext on all containers even with --security-context-config=restricted passed (operator-framework/operator-sdk#7040, open upstream). oadp-operator's own team hit this deterministically on OCP 4.21 and abandoned operator-sdk run bundle entirely in their own deploy-olm Makefile target (openshift/oadp-operator#2078), switching to a real opm catalog + CatalogSource (with grpcPodConfig.securityContextConfig: restricted) + OperatorGroup + Subscription instead -- exactly what this repo's optional-operators-subscribe step already implements correctly. Add a new step-registry step, optional-operators-opm-index-from-bundle, that builds a fresh opm sqlite index from an already-promoted bundle image (OO_BUNDLE) using opm index add + rootless umoci/skopeo assembly (no podman/buildah, no daemon), pushes it to this job's own namespace on the CI registry (reachable externally for the job's lifetime, same profile OO_BUNDLE itself already proves works), and writes the resulting pullspec to ${SHARED_DIR}/oo-index-pullspec. Patch optional-operators-subscribe-commands.sh to read that file as an OO_INDEX override, mirroring its existing SHARED_DIR override pattern for OO_INSTALL_NAMESPACE -- fully backward compatible for every other current consumer of this step. Switch the 4 KDM (kubevirt-datamover-controller/plugin x oadp-dev/1.6) consuming configs from optional-operators-operator-sdk-non-ci-bundle-image back to optional-operators-subscribe, restoring OO_PACKAGE/OO_CHANNEL/ OO_TARGET_NAMESPACES from the original pre-operator-sdk-pivot config. Revert set-related-image's Subscription discovery to read ${SHARED_DIR}/oo-subscription directly, since optional-operators-subscribe (unlike operator-sdk run bundle) already writes it. A placeholder `dependencies: {OO_INDEX: src}` is needed in each config purely to satisfy ci-operator's static validation of optional-operators-subscribe-ref.yaml's own declared `ci-index` dependency -- the actual value is overwritten by the SHARED_DIR read above before use. Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
kaovilai
added a commit
to kaovilai/release
that referenced
this pull request
Aug 16, 2026
…isk) operator-sdk run bundle spins up its own registry/grpc pod to serve the bundle to OLM, and that pod's containers don't reliably get a PodSecurity "restricted"-compliant securityContext on all containers even with --security-context-config=restricted passed (operator-framework/operator-sdk#7040, open upstream). oadp-operator's own team hit this deterministically on OCP 4.21 and abandoned operator-sdk run bundle entirely in their own deploy-olm Makefile target (openshift/oadp-operator#2078), switching to a real opm catalog + CatalogSource (with grpcPodConfig.securityContextConfig: restricted) + OperatorGroup + Subscription instead -- exactly what this repo's optional-operators-subscribe step already implements correctly. Add a new step-registry step, optional-operators-opm-index-from-bundle, that builds a fresh opm sqlite index from an already-promoted bundle image (OO_BUNDLE) using opm index add + rootless umoci/skopeo assembly (no podman/buildah, no daemon), pushes it to this job's own namespace on the CI registry (reachable externally for the job's lifetime, same profile OO_BUNDLE itself already proves works), and writes the resulting pullspec to ${SHARED_DIR}/oo-index-pullspec. Patch optional-operators-subscribe-commands.sh to read that file as an OO_INDEX override, mirroring its existing SHARED_DIR override pattern for OO_INSTALL_NAMESPACE -- fully backward compatible for every other current consumer of this step. Switch the 4 KDM (kubevirt-datamover-controller/plugin x oadp-dev/1.6) consuming configs from optional-operators-operator-sdk-non-ci-bundle-image back to optional-operators-subscribe, restoring OO_PACKAGE/OO_CHANNEL/ OO_TARGET_NAMESPACES from the original pre-operator-sdk-pivot config. Revert set-related-image's Subscription discovery to read ${SHARED_DIR}/oo-subscription directly, since optional-operators-subscribe (unlike operator-sdk run bundle) already writes it. A placeholder `dependencies: {OO_INDEX: src}` is needed in each config purely to satisfy ci-operator's static validation of optional-operators-subscribe-ref.yaml's own declared `ci-index` dependency -- the actual value is overwritten by the SHARED_DIR read above before use. Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #7039
Signed-off-by: Tiger Kaovilai passawit.kaovilai@gmail.com
Description of the change:
Motivation for the change:
Checklist
If the pull request includes user-facing changes, extra documentation is required:
changelog/fragments(seechangelog/fragments/00-template.yaml)website/content/en/docs