Skip to main content

Role Base access report

warning

Based on the past limited usage of this feature. We've decided to remove it from Babel 2.1. 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

img

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.

img

Technology view

img

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: