Description of problem:
As a user creating Pods in a namespace, I'd like to know which NetworkAttachmentDefinitions are available to me. However, with the default cluster settings, that is not possible.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create a net-attach-def in user's namespace
2. As the unprivileged user (project admin) try to list net-attach-def
API refuses to list it
The user should be able to list available NetworkAttachmentDefinitions - those created in their project and those created in the `default` namespace.
In order to list net-attach-def in admins project, following Role can be created:
- apiGroups: ["k8s.cni.cncf.io"]
verbs: ["watch", "list"]
I don't know how to globally expose the default namespace to all admins.
We had a previously opened similar BZ @ https://bugzilla.redhat.com/show_bug.cgi?id=1721444
And we had a previous similar PR @ https://github.com/openshift/cluster-network-operator/pull/208
However, we weren't able to appropriately come up with a consensus on it, and the PR was closed.
I'll chat it up with folks, but, it's kind of a touchy one as far as privs.
Thanks a lot Doug.
Reading https://bugzilla.redhat.com/show_bug.cgi?id=1721444#c16 it seems that the concern was that project admin could read net-attach-defs of different projects, is that right? The role definition above should be safe - it binds to each project admin and their respective project/namespace, it only allows them to read resources from that namespace. Project admin role is given automatically to you when you create a new project. It allows you to create Pods in your namespace and with this extension, it would allow you to list networks that are available to you.
The only security concern I see here is that it allows project admins to see into details of the host networking (e.g. name of the host interface) which may be abused (?).
No prob Petr -- you've sold me, I think this is a good approach for allowing users to list the net-attach-defs in their own projects, and it definitely makes sense.
I'm a little more... apprehensive about how to open the access to the default namespace / what that could potentially mean for administrators as a whole to have any project admins listing resources in the default ns. I think it might be reasonable for users that require this access to be added to the default project.
I've got a PR up against the CNO with your suggested RBAC, I gave it a whirl, and it appears to work how I'd expect.
Thanks for bringing this up so we can give users more access to do reasonable things -- it makes sense!
Tested and verified in 4.10.0-0.nightly-2022-01-17-091922
[weliang@weliang tmp]$ oc login -u test -p test
You have one project on this server: "test-multus-bridge"
Using project "test-multus-bridge".
[weliang@weliang tmp]$ oc get all
NAME READY STATUS RESTARTS AGE
pod/multus-bridge-pod-6f7c48c6c-2pft7 1/1 Running 0 13s
pod/multus-bridge-pod-6f7c48c6c-6fqnx 1/1 Running 0 13s
pod/multus-bridge-pod-6f7c48c6c-t5dkz 1/1 Running 0 13s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/multus-bridge-pod 3/3 3 3 13s
NAME DESIRED CURRENT READY AGE
replicaset.apps/multus-bridge-pod-6f7c48c6c 3 3 3 13s
[weliang@weliang tmp]$ oc get net-attach-def
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (Moderate: OpenShift Container Platform 4.10.3 security update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.