Change securityContext on operator, so that scc is 'restricted' #220
Conversation
|
Holding until CI starts. /hold |
|
Do you have a reference explaining why this fixes the bug? I'm lacking context on why this change is required and if it is okay/safe to remove the uid. |
|
I have added the UID as part of my PR that updated operator-sdk and manifests to a newer version. It was generated automatically, and I kept it there, because I thought that it would not cause any problem. This PR updates the I don't know why this changes the SCC. |
|
/hold cancel |
|
/cc @ksimon1 @omeryahud |
|
/lgtm |
|
Thanks |
|
The kubevirt-bot is not working on this PR, can you approve it manually? |
|
@akrejcir Do you think adding a test verifying your expectations here is necessary? |
|
Not necessary, but a good idea in case we change manifests in the future and SCC will change. I will add them. |
kubevirt-bot
added
dco-signoff: yes
|
Canceling approval. Test IDs are needed. /approve cancel |
|
/remove-approve |
This change will allow the SCC to be 'restricted', otherwise it will be 'privileged' Signed-off-by: Andrej Krejcir <akrejcir@redhat.com>
|
/retest |
|
This is ready for review. |
kubevirt-bot
requested review from
ksimon1,
kwiesmueller,
omeryahud and
vatsalparekh
|
/lgtm |
|
Kudos, SonarCloud Quality Gate passed!
|
|
sorry, I pressed wrong button |
|
/lgtm |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ksimon1, kwiesmueller The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/retest |
What this PR does / why we need it:
Changing the security context on the deployment, changes the assigned SCC from
privilegedtorestricted.Which issue(s) this PR fixes:
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1995295
Release note: