Role Base access report
Based on the past limited usage of this feature. We've decided to remove it. To look at your cluster permission, look at Self service RBAC documentation
Context
Kubernetes is one of the most famous container orchestration framework. The robustness of the solution depend on the configuration of both kubernetes, and the containers which run into kubernetes.
Based on the shared responsibility model, the responsibility is shared between the k8saas team and its customers.
To both help the k8saas customers, and provide more insights on the k8saas configuration. The k8saas provides a configuration reporting service.
Online example: here
Use case
- Look at the RBAC configuration in the k8saas cluster
- List both internal and external namespaces
- List the service accounts used
- Ask for a configuration/security report -> Request form
Design & Architecture
Note: The vision is described here. Currently, only the "User accesses and roles" has been developed. New feature will be delivered in the coming release.
Business View
The following diagram shows the final reports. The process to ask for its generation is described in the next chapter. The report includes 4 parts:
- a description of the environment (containing the access, the exposed URL etc...)
- a list of the incidents
- a secured score
- a list vulnerability & risks assessment
Legend:
- green: capability documented and running
- yellow: documented, running soon
- red: manual / on demand
Applicative view
Currently, there is a microservice deployed in every cluster that exposed "the user accesses and roles". A scheduler is deployed in transversal/internal resources. The analysis of the vulnerability and risk is manual.
Technology view
What to do ?
Nothing ! The service is enabled by default.
HOWTO
List all the user accesses
the RBAC microservice exposed its service internally. You can access to it using the peered network, or directly internally using the following command:
echo $(kubectl run -i --rm --tty busybox --image=radial/busyboxplus:curl --restart=Never -- curl -k https://rbac-service.$(kubectl config current-context).kaas.thalesdigital.io) | jq .
{
"user_accesses_by_perimeter": {
"loic.jardin@thalesdigital.io": {
"kind": "User",
"perimeters": {
"all": {
"kind": "cluster"
},
"dev": {
"kind": "namespace"
}
}
}
},
"user_accesses_by_role": {
"loic.jardin@thalesdigital.io": {
"kind": "User",
"roles": {
"cluster-admin": {
"kind": "ClusterRole"
},
"developer-role": {
"kind": "ClusterRole"
}
}
}
}
}
Explanations:
- the role in kubernetes are scoped by namespace (role_binding) or by cluster (cluster_role_binding). Look at the next steps to deep dive on RBAC subjects.
- roles are described here
List of the namespaces
echo $(kubectl run -i --rm --tty busybox --image=radial/busyboxplus:curl --restart=Never -- curl -k https://rbac-service.$(kubectl config current-context).kaas.thalesdigital.io/raw) | jq ".role_bindings[].namespace"|uniq
"cert-manager"
"dev"
"gatekeeper-system"
"kube-public"
"kube-system"
"linkerd"
"monitoring"
"nginx-ingress"
"velero"
List of the accesses for a given namespace
Example for dev:
echo $(kubectl run -i --rm --tty busybox --image=radial/busyboxplus:curl --restart=Never -- curl -k https://rbac-service.$(kubectl config current-context).kaas.thalesdigital.io/raw) | jq '.role_bindings[] | select(.namespace=="dev")'
{
"name": "k8saas-generic-sa-cicd_role_binding",
"role_name": "developer-role",
"kind": "ClusterRole",
"namespace": "dev",
"subjects": [
{
"name": "k8saas-generic-sa-cicd",
"kind": "ServiceAccount"
}
]
}
{
"name": "k8saas_developer-role_dev_role_binding",
"role_name": "developer-role",
"kind": "ClusterRole",
"namespace": "dev",
"subjects": [
{
"name": "loic.jardin@thalesdigital.io",
"kind": "User"
}
]
}
Next steps:
Few resources for RBAC on kubernetes: