Bug 1834839 - cluster-network-addons-operator SCC is anyuid, which appears too relaxed
Summary: cluster-network-addons-operator SCC is anyuid, which appears too relaxed
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Container Native Virtualization (CNV)
Classification: Red Hat
Component: Networking
Version: 2.3.0
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
: ---
Assignee: Ram Lavi
QA Contact: Yossi Segev
URL:
Whiteboard:
Depends On: 1847594
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-05-12 14:05 UTC by Kedar Bidarkar
Modified: 2022-06-14 07:00 UTC (History)
6 users (show)

Fixed In Version: cluster-network-addons-operator-container-v2.4.0-31
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-05-26 09:29:15 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Kedar Bidarkar 2020-05-12 14:05:36 UTC
Description of problem:

The current "cluster-network-addons-operator" Pods SCC is "anyuid".

Version-Release number of selected component (if applicable):


How reproducible:

[kbidarka@kbidarka-host auth]$ oc get pod cluster-network-addons-operator-5d6fbdfc56-9slhn -o yaml -n openshift-cnv | grep scc 
    openshift.io/scc: anyuid



Steps to Reproduce:
1.  check for cluster-network-addons-operator pod SCC
2.  oc get pod cluster-network-addons-operator-5d6fbdfc56-9slhn -o yaml -n openshift-cnv | grep scc 
3.

Actual results:

Current SCC "anyuid" seems too open.
Should have an SCC, which is not too open.


Expected results:

Should not have an no-restricted SCC. 
Current SCC "anyuid" seems too open.

Additional info:

Comment 1 Petr Horáček 2020-05-18 13:12:36 UTC
I believe this issue is caused by USER set in our Dockerfiles.

Comment 3 Petr Horáček 2020-06-04 17:58:37 UTC
I have to bring this back to ASSIGNED. This indeed fixed the issue with SCC, but caused many others where we are unable to deploy operands. See https://bugzilla.redhat.com/show_bug.cgi?id=1844057

Comment 4 Ram Lavi 2020-06-11 07:55:17 UTC
posted new PR fix: https://github.com/kubevirt/cluster-network-addons-operator/pull/419

Comment 5 Petr Horáček 2020-06-17 18:39:39 UTC
I am embarrassed but we have to move this back to dev again.

Comment 6 Petr Horáček 2020-06-21 19:59:51 UTC
Kedar, we may need to move this to 2.5 unless you suggest it should be a blocker.

You see, we made a several attempts to drop it, but every time we did, we failed on D/S with some missing rights. It needs careful consideration and I'm afraid we don't have enough time now.

Are you ok with this being moved to 2.5? I know you'll have to adjust some tests, sorry about that.

Comment 8 ibesso 2021-02-18 16:44:24 UTC
After an upgrade (2.5.3 -> 2.6.0), the scc annotation was changed to anyuid.

[cloud-user@ocp-psi-executor ~]$ oc get pods -n openshift-cnv vm-import-controller-5588f6cd98-dcnxv -oyaml |grep scc
    openshift.io/scc: anyuid

[cloud-user@ocp-psi-executor ~]$ oc get ip -n openshift-cnv
NAME            CSV                                       APPROVAL   APPROVED
install-8v9dh   kubevirt-hyperconverged-operator.v2.5.3   Manual     true
install-cjcmx   kubevirt-hyperconverged-operator.v2.6.0   Manual     true
[cloud-user@ocp-psi-executor ~]$ 

In 2.5:
oc get pod -n openshift-cnv vm-import-controller-74d785b999-7vnl2 -oyaml|grep scc
    openshift.io/scc: restricted

Comment 10 ibesso 2021-02-18 21:41:01 UTC
Please disregard my last comment regarding upgrade. Not related to this entry.

Comment 12 Kedar Bidarkar 2022-05-26 08:03:54 UTC
As per comment7, dropping needinfo.

Comment 13 Petr Horáček 2022-05-26 09:29:15 UTC
Since components we deploy need access to host network and be able to write to host filesystem, we cannot make CNAO restricted. I'm closing this. If anybody has a specific reason why we should avoid anyuid and replace it with an explicit SCC as done for e.g. bridge-marker, feel free to reopen the case.


Note You need to log in before you can comment on or make changes to this bug.