Bug 1721444 - Incomplete RBAC rules for resource network-attachment-definitions
Summary: Incomplete RBAC rules for resource network-attachment-definitions
Status: ON_QA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Networking
Version: 4.1.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 4.7.0
Assignee: Douglas Smith
QA Contact: Weibin Liang
: 1743985 (view as bug list)
Depends On:
Blocks: 1743985
TreeView+ depends on / blocked
Reported: 2019-06-18 10:13 UTC by Qixuan Wang
Modified: 2024-01-20 01:17 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2021-01-27 14:10:04 UTC
Target Upstream Version:
cdc: needinfo-

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github openshift cluster-network-operator pull 208 0 'None' closed Adds RBAC aggregation for the net-attach-def 2021-01-27 14:09:19 UTC

Description Qixuan Wang 2019-06-18 10:13:55 UTC
Description of problem:
Non-admin users are forbidden to list network-attachment-definitions.

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

How reproducible:

Steps to Reproduce:
1. Login as an ordinary user.
2. Create a project.
3. List resource network-attachment-definitions under the project.

Actual results:
3. # oc get network-attachment-definitions
No resources found.
Error from server (Forbidden): network-attachment-definitions.k8s.cni.cncf.io is forbidden: User "pm4" cannot list resource "network-attachment-definitions" in API group "k8s.cni.cncf.io" in the namespace "pm4"

Expected results:
Users with view/edit/admin role on this project can list the new resource network-attachment-definitions.

Additional info:
From bug https://bugzilla.redhat.com/show_bug.cgi?id=1720603#c6
And a similar bug https://bugzilla.redhat.com/show_bug.cgi?id=1721016

Comment 1 Dan Kenigsberg 2019-06-20 12:03:09 UTC
This is interesting, but most probably not our bug, as network-attachment-definitions custom resource is created by Multus, not CNV.

Comment 2 Casey Callendrello 2019-06-20 12:14:02 UTC
Doug, can you take a look or assign someone?

Comment 3 Douglas Smith 2019-06-20 20:23:27 UTC
I've been able to replicate the issue and also provide a method by which to give a user access to a custom resource.

Here's the steps that I used to recreate the problem. However, I'm not sure how I would setup RBAC aggregation for "any user created under openshift" or, if that's correct. Happy to take any suggestions here and I'll continue to look for a path forward that makes it so that administrators don't have to specifically give access.

However, here's an example of how I replicated the issue -- and remedied it by creating a clusterrole/clusterrolebinding that gives a user access to these resources.


# create a user

used process from: https://docs.openshift.com/container-platform/4.1/authentication/identity_providers/configuring-htpasswd-identity-provider.html#configuring-htpasswd-identity-provider

$ htpasswd -c -B -b doug.htpasswd doug testing123
$ ./oc create secret generic dougsecret --from-file=htpasswd=doug.htpasswd -n openshift-config

$ cat identity.yaml 
apiVersion: config.openshift.io/v1
kind: OAuth
  name: cluster
  - name: doug_identity_provider 
    mappingMethod: claim 
    type: HTPasswd
        name: dougsecret

$ ./oc apply -f identity.yaml

Then login...

./oc login -u doug
Authentication required for https://api.dougrbac.highfive.delivery:6443 (openshift)
Username: doug
Login successful.

You don't have any projects. You can try to create a new project, by running

    oc new-project <projectname>

# Replicate issue...

Create a project...

./oc new-project dougtest

Try creating a net-attach-def...

$ cat nad.yaml 
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
  name: macvlan-conf
  config: '{
      "cniVersion": "0.3.0",
      "type": "macvlan",
      "master": "eth0",
      "mode": "bridge",
      "ipam": {
        "type": "host-local",
        "subnet": "",
        "rangeStart": "",
        "rangeEnd": "",
        "routes": [
          { "dst": "" }
        "gateway": ""

$ ./oc create -f nad.yaml 
Error from server (Forbidden): error when creating "nad.yaml": network-attachment-definitions.k8s.cni.cncf.io is forbidden: User "doug" cannot create resource "network-attachment-definitions" in API group "k8s.cni.cncf.io" in the namespace "dougtest"


# Try to make a fix to it...

Create a cluster role and a rolebinding.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
  name: cni-resources
- apiGroups: ["k8s.cni.cncf.io"]
  resources: ["*"]
  verbs: ["*"]

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
  name: doug-cni-resources
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cni-resources
- kind: User
  name: doug
  namespace: dougtest

Now perform the creation again, and you can create & list the net-attach-def...

$ ./oc create -f nad.yaml 
networkattachmentdefinition.k8s.cni.cncf.io/macvlan-conf created
$ ./oc get networkattachmentdefinition.k8s.cni.cncf.io
NAME           AGE
macvlan-conf   10s

Comment 4 Douglas Smith 2019-06-20 20:36:30 UTC
Thank you for the referenced BZs, that did give me some direction. I have a PR open @ https://github.com/openshift/cluster-network-operator/pull/208

Comment 8 Tomas Jelinek 2020-02-27 12:28:55 UTC
*** Bug 1743985 has been marked as a duplicate of this bug. ***

Comment 15 Petr Horáček 2020-10-09 11:12:40 UTC
Assuming this is still an issue, is there any progress or estimation for the fix?

Comment 16 Douglas Smith 2020-11-11 20:41:12 UTC
I've returned to this BZ after some time, and after some trials with it, I've determined that this might not be straight-foward for NetworkAttachmentDefinitions (net-attach-defs).

The problem I'm encountering is two-fold:

A. If we use a Role with an aggregate-to-view, this generally would achieve the desired effect. However, with the current design of the cluster-network-operator, there's no controller for net-attach-defs -- which would be necessary in order to determine which namespaces to add Roles to, as Roles are namespace-scoped resources. To add this would be a feature (and while it might prove useful in some other scenarios, it had been decided against in previous design discussions). Even with that in place, we still wouldn't know which users would need the "view" RoleBinding, so it'd still be left to an administrator to give this privilege.

B. If we use a ClusterRole, which is for permissions across namespaces, we would wind up violating the privilege structure that we use for net-attach-defs. In OCP, we allow users only to reference net-attach-defs in the same namespace as a given pod. This is to allow for "more privileged" net-attach-defs that may live in namespaces that users do not have access to. By using a ClusterRole, we would expose net-attach-defs from other namespaces, which may not be desirable as it may expose information that would allow a user to attach to a more privileged network. Lastly, it would still suffer the same ill as the latter part of A -- you'd still need to have ClusterRoleBindings to give a user this permission, as well.

That being said, I think it may be appropriate to add documentation to describe how to give a regular user access to read (or possibly write) net-attach-defs. I will sync with docs team regarding how we might handle this.

Comment 20 Joachim von Thadden 2024-01-16 11:21:14 UTC
Opening up again because of OVN 2ndary: This new feature allows for true SDN networks that are completely isolated when used with layer2 topology. A user should be able to create his/her own NAD for those layer2 OVN networks. This is the core idea of SDN: a user can create own networks not interfering with others.

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