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==