Built-in roles base access with Thales identity
Introduction
Identity
There are several ways to be authenticated to TDP Kubernetes Landing Zone:
- with your nominative kubeconfig (User)
- with a generic service account (sa)
Note: By design, a service account is limited to a namespace. So you should have a service account per namespace.
Roles
In terms of security, you should use as much as possible the nominative account because it's configured with MFA and then allow you to access to the cluster from anywhere. The service account must be used only in CI/CD pipelines or applications inside kubernetes. The source ip used by the service account outside kubernetes are under monitoring, and all suspect activities will lead to service account revocation.
Once authenticate, you have to be authorised by the RBAC system to access to kubernetes APIs. We use cluster roles to list the permission. For instances:
| Role name | Description | Summarized Resource Access | Who can have it? |
|---|---|---|---|
| cluster-admin | This role provides complete access to the cluster | Full access | Only the production operators have those rights. Note: the k8saas development team does not have access to the production clusters. |
| develop | This role is for application development | configmap, cronjob, deamonset, deployment, event, ingress, issuers, pvc, pod, replicaset, secret and service | Customer developers |
| devops | This role is for cluster configuration | develop access + certificates, rolebinding, service account, sub-namespaces, stop and start aks cluster | Customer devops |
| reader | This role only allow to view information in the cluster | provides Read only access | Customer viewers |
Mapping
Finally, the mapping between the identities and the roles depends on the scope :
- for a cluster role binding: the scope if the overall cluster
- for a role binding: the scope is limited to a namespace
Detail Access
The kubectl plugin access-matrix shows an access matrix for server resources. rakkess installation instructions
Show your cluster access
kubectl access-matrix
Show your namespaced access on a specific namespace
kubectl access-matrix -n <namespace>
Show cluster access for a particular user
This must be executed by an user with at least devops rights
# List group id
kubectl get -n customer-namespaces rolebinding -o json | jq -r '.items[] | select(.metadata.name | endswith("dev_role_binding")) | {NAME: .metadata.name, ID: .subjects[].name}'
# List user permissions belonging to the group
kubectl access-matrix --as <particular-user-email> --as-group <group-id-of-the-particular-user>
Show namespaced access for a particular user on a specific namespace
This must be executed by an user with at least devops rights
# List group id
kubectl get -n customer-namespaces rolebinding -o json | jq -r '.items[] | select(.metadata.name | endswith("dev_role_binding")) | {NAME: .metadata.name, ID: .subjects[].name}'
# List user permissions belonging to the group
kubectl access-matrix --as <particular-user-email> --as-group <group-id-of-the-particular-user> -n <namespace>