Cluster reporting

Every BKE cluster sends us a short report once a day. This page says exactly what is in it, exactly what it cannot see, how to verify both on your own cluster, and how to turn it off.

Secrets covered what never leaves your cluster. This is the counterpart: the one recurring thing that does.

What it is

A CronJob called bke-report, in the bahriya-system namespace, installed by apply.sh on every cluster. It runs once a day, reads three things from your cluster, sends them to us, and exits. It is enabled by default.

It gates nothing. No licence state, no download, no upgrade and no feature depends on it, and a cluster we hear nothing from is treated as evidence of nothing — a cluster with restricted egress cannot report, and turning reporting off is a supported choice.

Exactly what is sent

Licence id	Which licence this cluster holds. Not the licence key — see below.
Cluster UID	The UID of your kube-system namespace. The closest thing Kubernetes has to a stable cluster identity, and what tells a rebuilt cluster apart from a new one.
Machine fingerprint	The fingerprint this cluster registered with. A hash.
BKE version	What BKE believes it installed.
Kubernetes version	What your API server actually reports, which is not always what the version graph pins.
Node counts	Two integers: control-plane nodes and workers.
Components	Component name to chart version, read from BKE’s own bke-state ConfigMap.

That is the whole report. There is nothing else in it.

A timestamp is not sent. We stamp the report when we receive it, so your clock is never something we depend on.

What it cannot see

This is not a promise about what we choose to read. It is what the job’s own permissions allow, and you can check them:

kubectl get clusterrole bke-report -o yaml
kubectl -n bahriya-system get role bke-report -o yaml

The whole of it:

• get on the one namespace object called kube-system — for the cluster UID;
• list on nodes — for two counts;
• get on the one ConfigMap called bke-state in bahriya-system — BKE’s own record of what it installed.

There is no permission to read Secrets, no permission to list namespaces, no permission to read workloads, pods, logs, events, ingresses or PersistentVolumeClaims, and no permission to read any ConfigMap other than BKE’s own. Names of your namespaces, your workloads and your data are not merely absent from the report — the job could not read them if it tried.

The licence key is never on your cluster at all. /etc/bke/license is read by install.sh, upgrade.sh and apply.sh on a node and is never copied into Kubernetes. The reporting job identifies itself with the licence id, which is an identifier and not a credential, and it sits in the pod’s environment where any cluster administrator can read it:

kubectl -n bahriya-system get cronjob bke-report \
  -o jsonpath='{.spec.jobTemplate.spec.template.spec.containers[0].env}' | tr ',' '\n'

A disclosure you can inspect is worth more than one you have to take on trust, which is why those values are in plain environment variables rather than a Secret.

Reading the report yourself

There is no special tooling. Run the job now and read what it did:

kubectl -n bahriya-system create job --from=cronjob/bke-report bke-report-now
kubectl -n bahriya-system logs job/bke-report-now

Delete it when you are finished:

kubectl -n bahriya-system delete job bke-report-now

To see when it last ran, and whether it succeeded:

kubectl -n bahriya-system get cronjob bke-report
kubectl -n bahriya-system get jobs -l job-name --sort-by=.status.startTime

The console shows the same reports from our side, under the licence: what the cluster last told us it is running, and the reports before that.

What has to be reachable

The job sends one HTTPS request a day to the same API host your nodes already use for installs and upgrades. If that host is reachable from your nodes, nothing further is needed.

If egress from pods is restricted separately from egress from nodes — which is common, and correct — then the job runs and fails until pods in bahriya-system can reach that host. That failure costs you nothing except the failed Jobs in the namespace. If you do not intend to allow it, turn reporting off rather than leaving a job failing daily.

Turning it off

One key in /etc/bke/config.yaml:

reporting:
  enabled: false

Then apply it:

curl -sL https://bke.maml.uk/apply.sh | sh -s -- --version 2.0.0
curl -sL https://bke.maml.uk/apply.sh | sh -s -- --version 2.0.0 --commit

The job is removed, not skipped. On that run BKE deletes the CronJob, its ServiceAccount, and all four of its RBAC objects. A cluster that reported yesterday stops reporting today, and nothing is left behind holding permissions. Confirm it:

kubectl -n bahriya-system get cronjob,serviceaccount,role,rolebinding -l app.kubernetes.io/managed-by=bke
kubectl get clusterrole,clusterrolebinding bke-report

The second command should report that nothing was found.

Turning it off is a supported choice, not a degraded one. Some regulated deployments forbid any telemetry leaving a cluster at all, and BKE is installable there. Nothing expires, no feature is withheld, no download is refused and no request is treated differently. The only difference is that we will not already know your versions when you open a support ticket, so you may be asked for them.

To turn it back on, set enabled: true and run apply.sh --commit again. The job and its permissions are recreated on that run.

reporting.enabled is the only key. Nothing in config.yaml sets the schedule: the job runs once a day, at a fixed minute chosen so that a fleet of clusters does not all report in the same second.

Where this is written down

The licence terms state the same thing contractually, in the clause headed “Cluster reporting”: what the report contains, that it gates nothing, and that disabling it carries no consequence of any kind. The terms also record that the report contains no personal data within the meaning of Federal Decree-Law No. 45 of 2021.

We will not add a field to this report without amending those terms first.