Grant Namespace Access for Non-admin User

Applicable to both Classic and Federated modes

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, see 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: ["customresourcedefinitions","virtualmachines","virtualmachineinstances","csidrivers", "services", "namespaces", "clusterrolebindings", "persistentvolumes", "clusterroles", "nodes", "storageclasses"]
     verbs: ["get", "list", "watch", "create"]
   - apiGroups: ["stork.libopenstorage.org"]
     resources: ["schedulepolicies","backuplocations","applicationbackups"]
     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

   In current Kubernetes versions, a Secret-based token is not created automatically for a service account. Create it manually as shown below.

   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 following format, and update the required values along with the certificate and service account token obtained from the previous step.

    apiVersion: v1
    kind: Config
    clusters:
    - name: my-cluster
      cluster:
        server: https://<KUBERNETES_API_SERVER>
        certificate-authority-data: <BASE64_ENCODED_CA_CERT>
    users:
    - name: user1
      user:
        token: <SERVICE_ACCOUNT_TOKEN>
    contexts:
    - name: user1-context
      context:
        cluster: my-cluster
        user: user1
        namespace: ns1
    current-context: user1-context

   Sample kube-config for the service account user1:

   apiVersion: v1
   kind: Config
   clusters:
   - name: my-cluster
     cluster:
       server: https://xx.xx.xx.xxx:6443
       certificate-authority-data: <alpha-numeric-certificate-key>
   users:
   - name: user1
     user:
       token: <alpha-numeric-certificate-token>
   contexts:
   - name: user1-context
     context:
       cluster: my-cluster
       user: user1
       namespace: ns1
   current-context: user1-context