NO-ISSUE: Enabled readonlyRootFilesystem by default

[dusk125]

Description of the change:

Enforce readOnlyRootFilesystem: true for enhanced security (and provide brief justification for false exceptions)
Motivation for the change:

Reviewer Checklist

• Implementation matches the proposed design, or proposal is updated to match implementation
• Sufficient unit test coverage
• Sufficient end-to-end test coverage
• Docs updated or added to /docs
• Commit messages sensible and descriptive

[openshift-ci]

Hi @dusk125. Thanks for your PR.

I'm waiting for a operator-framework member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[kevinrizza]

/ok-to-test

[tmshort]

/approve

[tmshort]

@dusk125 - this seems to be failing all our tests...

[grokspawn]

/lgtm

[grokspawn]

/lgtm

[jianzhangbjz]

Just to confirm, if grpcPodConfig.ExtractContent == nil, then pod.Spec.Containers[0].SecurityContext.ReadOnlyRootFilesystem will be set to false. Is that the expected behavior? Thanks!

[grokspawn]

Correct. If we're using extractContent, then we are pulling out the catalog+cache and running it in a catalogsource using an in-cluster opm version.
If we're not using extractContent, then we're "just running an arbitrary pod", which is expected to speak GRPC on port 50051.

[jianzhangbjz]

Thanks for the confirmation! I have one more question—if we don’t use extractContent, the command running in the Pod is /bin/opm serve /configs --cache-dir=/tmp/cache, which requires readOnlyRootFilesystem: false. However, I believe mounting /tmp as a volume should also work if we set readOnlyRootFilesystem: true. So, my question is: why not set readOnlyRootFilesystem: true when extractContent is not used? Or am I missing something? Thanks!

[grokspawn]

go version has not changed as a result of this PR, but the go-verdiff assesses any delta between this PR and its destination branch (master).

I'll override.

/lgtm

[grokspawn]

/label override-go-verdiff

[openshift-ci]

@grokspawn: The label(s) /label override-go-verdiff cannot be applied. These labels are supported: acknowledge-critical-fixes-only, platform/aws, platform/azure, platform/baremetal, platform/google, platform/libvirt, platform/openstack, ga, tide/merge-method-merge, tide/merge-method-rebase, tide/merge-method-squash, px-approved, docs-approved, qe-approved, ux-approved, no-qe, downstream-change-needed, rebase/manual, cluster-config-api-changed, run-integration-tests, approved, backport-risk-assessed, bugzilla/valid-bug, cherry-pick-approved, jira/valid-bug, stability-fix-approved, staff-eng-approved. Is this label configured under labels -> additional_labels or labels -> restricted_labels in plugin.yaml?

Details

In response to this:

/label override-go-verdiff

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: grokspawn, tmshort

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [grokspawn,tmshort]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment