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): How reproducible: Always 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 Actual results: API refuses to list it Expected results: The user should be able to list available NetworkAttachmentDefinitions - those created in their project and those created in the `default` namespace. Additional info: In order to list net-attach-def in admins project, following Role can be created: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: net-attach-def-project labels: rbac.authorization.k8s.io/aggregate-to-admin: "true" rules: - apiGroups: ["k8s.cni.cncf.io"] resources: ["network-attachment-definitions"] 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 Login successful. 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 NAME AGE multus-bridge 35s [weliang@weliang tmp]$
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. https://access.redhat.com/errata/RHSA-2022:0056