The most flexible way to generate badges representing what happens in your cluster.
Basically, you can turn every information available from the kubernetes API into a badge:
To generate a badge, you pass the full link to a kubernetes API resource and an optional jq
string to filter the resource to the badger:
https://<YOUR-CLUSTER>/badge/<API-RESOURCE>?jq=<FILTER>&<ADDITIONAL-PARAMS>
Suppose you have a deployment in your cluster:
{
"apiVersion": "extensions/v1beta1",
"kind": "Deployment",
"metadata": {
"labels": {
"version": "2"
},
"name": "petstore",
"selfLink": "/apis/extensions/v1beta1/namespaces/default/deployments/petstore"
},
"spec": {}
}
Now, let's say you wanted a badge stating the currently deployed version. You request it like so (note how you pass the full selfLink
of the deployment):
https://your-badger-installation/badge/apis/extensions/v1beta1/namespaces/default/deployments/petstore?jq=.metadata.labels.version
You will receive the following badge:
You can customize the badge by passing some more query parameters:
&label=petstore-version
&color=green
Simple:
helm install https://github.com/tobilarscheid/kube-badger/releases/download/0.1.0/kube-badger-0.1.0.tgz --values=myvalues.yaml
Make sure to provide a values yaml specifiying what API resources your kube-badger should be allowed to access. For details see the chart README.
Running the kube badger in your cluster can potentially provide an attacker with full read access to your clusters API server. You can either restrict this through RBAC
(by restricting the kube-badgers serviceaccount
) or through Ingress
(by restricting the paths someone can pass to the kube-badger). Both ways are described in detail in the helm chart's README.
All badges are generated by shields.io.