This is interesting, but most probably not our bug, as network-attachment-definitions custom resource is created by Multus, not CNV.

Doug, can you take a look or assign someone?

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
metadata:
  name: cluster
spec:
  identityProviders:
  - name: doug_identity_provider 
    mappingMethod: claim 
    type: HTPasswd
    htpasswd:
      fileData:
        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
Password: 
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
metadata:
  name: macvlan-conf
spec:
  config: '{
      "cniVersion": "0.3.0",
      "type": "macvlan",
      "master": "eth0",
      "mode": "bridge",
      "ipam": {
        "type": "host-local",
        "subnet": "192.168.1.0/24",
        "rangeStart": "192.168.1.200",
        "rangeEnd": "192.168.1.216",
        "routes": [
          { "dst": "0.0.0.0/0" }
        ],
        "gateway": "192.168.1.1"
      }
    }'

$ ./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
metadata:
  name: cni-resources
rules:
- apiGroups: ["k8s.cni.cncf.io"]
  resources: ["*"]
  verbs: ["*"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: doug-cni-resources
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cni-resources
subjects:
- 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
```

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

*** Bug 1743985 has been marked as a duplicate of this bug. ***

Assuming this is still an issue, is there any progress or estimation for the fix?

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.

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.