Grant access to a namespace for non-admin user

If you are a user with administrator privileges and if you want to provide non-admin permissions to a service account user1 to access a specific namespace ns1, perform the following steps:

1. Create a service account user1 in the namespace ns1:

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: user1
     namespace: ns1

   NOTE: If your Kubernetes version is below v1.22, use rbac.authorization.k8s.io/v1beta1 API version of ClusterRole, ClusterRoleBinding, Role, and RoleBinding. For more information, refer RBAC resources.

2. Create a clusterRole and clusterRolebinding for the service account with the required permissions:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: user1-clusterrole
   rules:
   - apiGroups: ["*"]
     resources: ["namespaces", "clusterrolebindings", "persistentvolumes", "clusterroles", "nodes", "storageclasses"]
     verbs: ["get", "list", "watch", "create"]
   - apiGroups: ["stork.libopenstorage.org"]
     resources: ["schedulepolicies"]
     verbs: ["create", "delete", "deletecollection", "get", "list", "patch", "update", "watch"]
   - apiGroups: ["stork.libopenstorage.org"] # for controller support
     resources: ["*"]
     verbs: ["list", "get", "watch"]
   - apiGroups: ["snapshot.storage.k8s.io"]
     resources: ["volumesnapshotclasses"]
     verbs: ["get", "list"]

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: user1-clusterrolebinding
   subjects:
   - kind: ServiceAccount
     name: user1
     namespace: ns1
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: user1-clusterrole

3. Create a role and rolebinding for the namespace with the required permission in the namespace ns1:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: ns1-role
     namespace: ns1
   rules:
   - apiGroups: ["", "extensions", "apps"]
     resources: ["*"]
     verbs: ["*"]
   - apiGroups: ["batch"]
     resources:
     - jobs
     - cronjobs
     verbs: ["*"]
   - apiGroups:
     - stork.libopenstorage.org
     resources: ["*"]
     verbs:
     - create
     - delete
     - deletecollection
     - get
     - list
     - patch
     - update
     - watch

   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: ns1-rolebinding
     namespace: ns1
   subjects:
   - kind: ServiceAccount
     name: user1
     namespace: ns1
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: ns1-role

4. Provide the read permissions for the get and list operations for the configmap in the kube-system namespace. You need to link user1 service account created in the namespace ns1 in the rolebinding. You need not create a new service account in the kube-system.

   NOTE: Regardless of the namespace, you need these permissions for configmap in the kube-system namespace to read the configmap created by Stork.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: ks-role
     namespace: kube-system
   rules:
   - apiGroups: [""]
     resources: ["configmaps"]
     verbs: ["get", "list"]

   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: ks-rolebinding
     namespace: kube-system
   subjects:
   - kind: ServiceAccount
     name: user1
     namespace: ns1
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: ks-role

5. Create the secret token for the service account user1.

   NOTE: If your Kubernetes version is 1.24 and above, the secret token does not get assigned to the service account token by default. If your Kubernetes version is below 1.24, skip this step.

   apiVersion: v1
   kind: Secret
   metadata:
     name: user1-token
     namespace: ns1
     annotations:
       kubernetes.io/service-account.name: user1
   type: kubernetes.io/service-account-token

6. Fetch the service account token and certificate to update the kube-config:

   kubectl get secret user1-token -n ns1 -o "jsonpath={.data.token}" | base64 -d

   kubectl get secret user1-token -n ns1 -o "jsonpath={.data['ca\.crt']}"

7. Create a kube-config file in the below format, update the required values along with certificate and service account token obtained from previous step.

   apiVersion: v1
   clusters:
   - cluster:
       certificate-authority-data: <certificate>
       server: https://<cluster-IP>:6443
     name: cluster.local
   contexts:
   - context:
       cluster: cluster.local
       namespace: <namespace-name>
       user: <service-account-name>
     name: <service-account>@cluster.local
   current-context: <service-account>@cluster.local
   kind: Config
   preferences: {}
   users:
   - name: <service-account>
     user:
       token: <service-account-token>
       client-key-data: <certificate>

   Sample kube-config for the service account user1:

   apiVersion: v1
   clusters:
   - cluster:
       certificate-authority-data: LS0tLSJQ0FURS0tLS0tCTkJnq..................aTXHWlFBYU5aTUZjd0==
       server: https://x.x.x.x:6443
     name: cluster.local
   contexts:
   - context:
       cluster: cluster.local
       namespace: ns1
       user: user1
     name: user1@cluster.local
   current-context: user1@cluster.local
   kind: Config
   preferences: {}
   users:
   - name: user1
     user:
       token: ABgHtLSJQ0FURSOpha0tCTkJnq..................aTXHWlFBYU5aTUZjd0
       client-key-data: LS0tLSJQ0FURS0tLS0tCTkJnq..................aTXHWlFBYU5aTUZjd0==