Bug 2021191 - Project admins should be able to list available network attachment defintions
Summary: Project admins should be able to list available network attachment defintions
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Networking
Version: 4.10
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 4.10.0
Assignee: Douglas Smith
QA Contact: Weibin Liang
Depends On:
Blocks: 2025821 2032484
TreeView+ depends on / blocked
Reported: 2021-11-08 14:08 UTC by Petr Horáček
Modified: 2022-03-10 16:26 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2022-03-10 16:26:09 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github openshift cluster-network-operator pull 1226 0 None open Bug 2021191: Project admins should be able to list net-attach-defs in their namespaces 2021-11-12 19:23:20 UTC
Red Hat Product Errata RHSA-2022:0056 0 None None None 2022-03-10 16:26:27 UTC

Description Petr Horáček 2021-11-08 14:08:15 UTC
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:

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
  name: net-attach-def-project
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
- 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.

Comment 1 Douglas Smith 2021-11-08 18:21:39 UTC
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.

Comment 2 Petr Horáček 2021-11-12 14:30:01 UTC
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 (?).

Comment 3 Douglas Smith 2021-11-12 19:22:53 UTC
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!

Comment 6 Weibin Liang 2022-01-17 16:50:05 UTC
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]$

Comment 9 errata-xmlrpc 2022-03-10 16:26:09 UTC
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.


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