Bug 1721444
Summary: | Incomplete RBAC rules for resource network-attachment-definitions | ||
---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | Qixuan Wang <qixuan.wang> |
Component: | Networking | Assignee: | Douglas Smith <dosmith> |
Networking sub component: | multus | QA Contact: | Weibin Liang <weliang> |
Status: | CLOSED WONTFIX | Docs Contact: | |
Severity: | medium | ||
Priority: | medium | CC: | aconstan, anbhat, aoconnor, aos-bugs, bbennett, cnv-qe-bugs, djuran, dosmith, gouyang, j.thadden, nagrawal, ncredi, phoracek, tjelinek |
Version: | 4.1.0 | Keywords: | Reopened, UpcomingSprint |
Target Milestone: | --- | Flags: | cdc:
needinfo-
|
Target Release: | 4.7.0 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | SDN-CI-IMPACT,SDN-STALE | ||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2024-04-30 18:04:53 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1743985 |
Description
Qixuan Wang
2019-06-18 10:13:55 UTC
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. OCP is no longer using Bugzilla and this bug appears to have been left in an orphaned state. If the bug is still relevant, please open a new issue in the OCPBUGS Jira project: https://issues.redhat.com/projects/OCPBUGS/summary |