Add role for developer user to access resources on default namespace

[anjannath]

Without this role added, we get the following error when using the crc-developer context:

% oc project
error: you do not have rights to view project "default" specified in your config or the project doesn't exist

% oc get all -n default
Error from server (Forbidden): pods is forbidden: User "developer" cannot list resource "pods" in API group "" in the namespace "default"
Error from server (Forbidden): replicationcontrollers is forbidden: User "developer" cannot list resource "replicationcontrollers" in API group "" in the namespace "default"

After adding the role, rolebinding developer user is able to access resources on the namespace:

% oc get all -n default
Warning: apps.openshift.io/v1 DeploymentConfig is deprecated in v4.14+, unavailable in v4.10000+
NAME                 TYPE           CLUSTER-IP   EXTERNAL-IP                            PORT(S)   AGE
service/kubernetes   ClusterIP      10.217.4.1   <none>                                 443/TCP   41d
service/openshift    ExternalName   <none>       kubernetes.default.svc.cluster.local   <none>    41d

fixes #703

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from anjannath. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[praveenkumar]

Adding rbac for developer user for default group might cause security risk because as of now developer user have default password and default namespace might contain some cluster specific details in form or secret/configmap/svc . We are already going with security review exercise where it is flagged to have this static password for developer user (as of now exception is because it doesn't have any addition rbac) and it would be better to have it this way.

[anjannath]

Adding rbac for developer user for default group might cause security risk because as of now developer user have default password and default namespace might contain some cluster specific details in form or secret/configmap/svc . We are already going with security review exercise where it is flagged to have this static password for developer user (as of now exception is because it doesn't have any addition rbac) and it would be better to have it this way.

the Role gives the user 'developer' full access to the default namespace only, the default namespace has the following resources, having access to these doesn't have any security risks, the secrets and config maps resources are common to all namespaces.

% oc get secrets -n default
NAME                       TYPE                      DATA   AGE
builder-dockercfg-z8sw6    kubernetes.io/dockercfg   1      40d
default-dockercfg-hmb2j    kubernetes.io/dockercfg   1      40d
deployer-dockercfg-9zj56   kubernetes.io/dockercfg   1      40d

% oc get cm -n default
NAME                       DATA   AGE
kube-root-ca.crt           1      42d
openshift-service-ca.crt   1      42d

% oc get all -n default
Warning: apps.openshift.io/v1 DeploymentConfig is deprecated in v4.14+, unavailable in v4.10000+
NAME                 TYPE           CLUSTER-IP   EXTERNAL-IP                            PORT(S)   AGE
service/kubernetes   ClusterIP      10.217.4.1   <none>                                 443/TCP   41d
service/openshift    ExternalName   <none>       kubernetes.default.svc.cluster.local   <none>    41d

also after crc start we create a crc-developer context and that uses the default namespace, so users expect that by-default the developer user has access to this namespace, if we don't provide the necessary roles for accessing it then maybe we shouldn't add this context as otherwise its not usable without user modification

% oc config get-contexts
CURRENT   NAME                                                      CLUSTER                                 AUTHINFO                                          NAMESPACE
          /api-crc-testing:6443/developer                           api-crc-testing:6443                    developer/api-crc-testing:6443
          crc-admin                                                 api-crc-testing:6443                    kubeadmin/api-crc-testing:6443                    default
          crc-developer                                             api-crc-testing:6443                    developer/api-crc-testing:6443                    default

[anjannath]

closing, we decided to handle it in crc via crc-org/crc#4420