From 19d44a37610635b7f363801a30799d5c82556588 Mon Sep 17 00:00:00 2001 From: Timur Tukaev Date: Tue, 18 Aug 2026 17:02:08 +0600 Subject: [PATCH 1/3] docs(compliance): add CIS Benchmark and Kubernetes conformance pages MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Two more frameworks under Compliance, written the same way as the PCI DSS page: measured on a live cluster, with the commands to reproduce every claim. CIS Benchmark reports a full kube-bench run — 54 pass, 24 fail, 53 warn — and then does the work that makes the report usable: fifteen failures are file-mode checks against paths an immutable node does not keep, three test a flag that structured authorization replaced, two target components that are not installed, and four are real. Three of those four are deliberate platform decisions with their reasoning stated, and the page says what closing each one would cost. The audit-policy section deserves its own note. The obvious remedy for a Metadata-level policy is to raise everything to RequestResponse, and that is the wrong move: request bodies carry Secret values and personal data, so the audit log becomes a second copy of what it was meant to protect. The page recommends a per-resource split instead, which is also how the upstream reference policy handles Secrets. The PCI DSS page carried the naive advice and is corrected here. Kubernetes conformance explains what the CNCF suite proves and what it does not, points at the published results in cncf/k8s-conformance, and names the submitting entity and product rather than hinting at them — the project holds no listing of its own and says so. It also documents two traps found while running the suite here: the default systemd-logs plugin never finishes on Talos, and sonobuoy status can report zero progress while tests are completing. Trademark note: 'Certified Kubernetes' is licensed to a product, not to an upstream project, and the page carries that disclaimer. Signed-off-by: Timur Tukaev --- content/en/compliance/_index.md | 6 + content/en/compliance/cis-benchmark.md | 318 ++++++++++++++++++ .../en/compliance/kubernetes-conformance.md | 190 +++++++++++ content/en/compliance/pci-dss.md | 9 +- hugo.yaml | 8 + 5 files changed, 528 insertions(+), 3 deletions(-) create mode 100644 content/en/compliance/cis-benchmark.md create mode 100644 content/en/compliance/kubernetes-conformance.md diff --git a/content/en/compliance/_index.md b/content/en/compliance/_index.md index eb943e64..2d3b317d 100644 --- a/content/en/compliance/_index.md +++ b/content/en/compliance/_index.md @@ -22,3 +22,9 @@ command you can run against your own cluster. - **[PCI DSS](/compliance/pci-dss/)** — a requirement-by-requirement mapping of what Cozystack enforces by default, what is opt-in, and what stays with you, with commands to verify each control on your own cluster. +- **[CIS Benchmark](/compliance/cis-benchmark/)** — a full kube-bench run against Cozystack + on Talos Linux, with every failure sorted into real deviations, controls met another way, + and checks that do not apply. +- **[Kubernetes Conformance](/compliance/kubernetes-conformance/)** — what CNCF conformance + proves, where Cozystack-based clusters appear in the CNCF results, and how to run the + suite yourself. diff --git a/content/en/compliance/cis-benchmark.md b/content/en/compliance/cis-benchmark.md new file mode 100644 index 00000000..f5e1a2e1 --- /dev/null +++ b/content/en/compliance/cis-benchmark.md @@ -0,0 +1,318 @@ +--- +title: "CIS Kubernetes Benchmark Results on Cozystack and Talos" +linkTitle: "CIS Benchmark" +description: "Full kube-bench run against Cozystack v1.6 on Talos Linux: 54 pass, 24 fail, and why only four failures are real. Includes the job manifest to reproduce it." +date: 2026-08-18 +type: "page" +weight: 20 +--- + +**A raw kube-bench report on Cozystack shows two dozen failures, and four of them matter.** The rest are the benchmark looking for files that Talos Linux does not have, or +checking a Kubernetes flag that newer releases replaced. This page shows the whole run, +sorts every failure into one of three buckets, and gives you the manifest to reproduce it on +your own cluster. + +That sorting is the work. Handing an auditor an unannotated kube-bench report is worse than +handing them nothing: they see twenty-four red lines, and you spend the rest of the meeting +explaining architecture instead of security. + +## What the kube-bench run covered + +CIS Kubernetes Benchmark v1.12, executed by [kube-bench](https://github.com/aquasec/kube-bench) +against Cozystack v1.6 on Kubernetes v1.34.3. Control plane checks ran on a control-plane +node, worker checks on a worker. + +Scope: this is the management cluster — the Talos nodes and the Kubernetes +control plane that Cozystack itself runs on. Tenant Kubernetes clusters are not covered by +these numbers. Their control planes are Kamaji Deployments with their own API server flags +and their own etcd, so sections 1, 2 and 3 have to be evaluated separately for them. If +tenant clusters fall inside your assessment, ask for that run as well. + +| Section | Pass | Fail | Warn | +|---|---|---|---| +| 1 — Control plane security configuration | 29 | 22 | 9 | +| 2 — etcd node configuration | 7 | 0 | 0 | +| 3 — Control plane configuration | 1 | 0 | 4 | +| 4 — Worker node security configuration | 17 | 2 | 6 | +| 5 — Kubernetes policies | 0 | 0 | 34 | +| **Total** | **54** | **24** | **53** | + +Section 2 is worth a moment: every etcd flag check passes — client and peer certificates, +`--client-cert-auth`, no `--auto-tls`. The one etcd-related failure sits in section 1 and +concerns the data directory owner; it is discussed below. + +## Why most failures are not findings + +### The benchmark is looking for kubeadm + +Fifteen of the twenty-four failures are file checks — permissions and ownership of the API +server, controller manager, scheduler and etcd pod manifests, and of `admin.conf`, +`scheduler.conf` and `controller-manager.conf`. + +Every one of them reports an empty value. Look at the node and you see why: + +``` +# /etc/kubernetes on a Talos control-plane node +bootstrap-kubeconfig +kubeconfig-kubelet +kubelet.yaml +manifests/ <- empty +pki/ +``` + +The `manifests` directory exists and holds nothing: Talos renders the control plane pods +from its own configuration under `/system`, not from files an administrator edits, and +`/etc/kubernetes/manifests` is left for static pods *you* choose to add. The administrator +kubeconfigs the benchmark looks for — `admin.conf`, `scheduler.conf`, +`controller-manager.conf` — are absent entirely, because credentials are issued through the +Talos API instead of being left on disk. + +Check it on your own node rather than taking this on trust: + +```bash +talosctl -n list -l /etc/kubernetes /etc/kubernetes/manifests +``` + +The honest reading is not "fifteen controls failed" but "fifteen controls are inapplicable, +and the risk they exist to manage — an attacker or a mistake altering control plane +configuration on disk — is handled by immutability instead of by file modes". One check in the same group, 1.1.12, fails for a different reason. The etcd data directory +exists and is readable — check 1.1.11 confirms it is mode 0700 — but etcd runs as root, there +is no system `etcd` account on a Talos node, and the scanning container cannot resolve the +numeric owner to a name. The intent of the control, restricting who can read the etcd data +directory, is met; the literal `etcd:etcd` ownership it asks for cannot exist on a system +with no user accounts. + +### Three checks predate structured authorization + +Checks 1.2.6, 1.2.7 and 1.2.8 require the `--authorization-mode` flag to exclude +`AlwaysAllow` and to include `Node` and `RBAC`. Kubernetes 1.30 introduced a structured +authorization configuration file, and Talos uses it, so the flag is absent and the checks +fail. + +The configuration itself is exactly what the benchmark wants: + +```yaml +apiVersion: apiserver.config.k8s.io/v1beta1 +kind: AuthorizationConfiguration +authorizers: +- name: node + type: Node +- name: rbac + type: RBAC +``` + +Both authorizers are enabled, and `AlwaysAllow` is nowhere. This is not a case of running an +out-of-date benchmark: CIS v1.12 is the current revision and covers Kubernetes 1.32 through +1.34, while structured authorization reached general availability in 1.32. The control simply +still tests for a flag that a conformant modern cluster is entitled not to have. Expect more +false positives like it. Disproving them means reading the configuration, not rerunning the +tool. + +### Both worker failures are architectural + +Check 4.1.1 wants a kubelet service file, which Talos does not use. Check 4.3.1 wants the +kube-proxy metrics endpoint bound to localhost — and there is no kube-proxy to bind: +Cozystack runs Cilium with `kube-proxy-replacement` enabled, so the component the check +targets is not installed. The exposure the control was written about did not vanish, though — +it moved to the Cilium agent's own metrics and health ports on each node, which the benchmark +does not examine at all. Bind those to the node's internal address and firewall them the way +you would have treated kube-proxy. + +## What actually needs attention + +Four failures survive the sort. None of them is exotic, and all four are settings in the +Talos machine configuration rather than platform changes. + +Three of the four are deliberate choices by the platform maintainers rather than oversights, +and knowing the reasoning is more useful than knowing the score. + +| Check | What it means | How to treat it | +|---|---|---| +| 1.2.5 — `--kubelet-certificate-authority` not set | The API server presents a client certificate to the kubelet but does not verify the kubelet's serving certificate against a CA | Deliberate: on bare metal there is no metadata service to issue and distribute kubelet serving certificates. Closing it means building that mechanism | +| 1.3.7 — controller manager `--bind-address=0.0.0.0` | The secure port (10257) listens on every interface rather than loopback, and exposes metrics only. Metrics require authentication and authorization; `/healthz`, `/readyz` and `/livez` do not | Deliberate: this is how metrics are collected today. The cleaner shape is loopback plus an authorizing proxy in front | +| 1.4.2 — scheduler `--bind-address=0.0.0.0` | The same, on port 10259 | As above | +| 1.2.30 — `--service-account-extend-token-expiration` not `false` | Extended service account token lifetime remains on, a compatibility default for older clients | Not a considered decision — the default was simply never changed | + +If your assessor treats any of these as a finding, the answer is a compensating control plus +a plan, not a denial. The first three are each a day or two of engineering to close properly; +the fourth is a flag. What follows is what closing them actually involves. + +One caution before acting on 1.2.5: the flag alone is not the fix, and on its own it breaks +things. By default the kubelet serves a self-signed certificate, so an API server told to +verify it against a CA stops being able to run `kubectl logs`, `exec`, `port-forward` or +metrics-server. Closing this control is a three-part change — enable `serverTLSBootstrap` on +the kubelet, run a signer that approves kubelet serving CSRs, and only then set +`--kubelet-certificate-authority`. Do it on a test cluster and check `kubectl logs` against +every node before calling it done. + +The benchmark's remediation for 1.3.7 and 1.4.2 is `--bind-address=127.0.0.1`, and applying +it literally has a cost: Prometheus scrapes the controller manager and scheduler across +nodes, and loopback-only endpoints stop being scrapable. The proportionate answer is to leave +the bind address alone, close ports 10257 and 10259 to everything but the monitoring path +using the Talos ingress firewall, and record that as a compensating control rather than as a +passed check. + +Before switching off extended token expiration, watch `serviceaccount_stale_tokens_total` on +the API server: while it is above zero, something still depends on the compatibility +behavior. + +### Where these settings live + +All four sit in the Talos machine configuration you apply at install time — Cozystack does +not generate it for you, which is also why the same run on your cluster may differ. Verify +what yours actually runs before changing anything: + +```bash +talosctl -n get authorizationconfig -o yaml +``` + +## Kubernetes audit policy: the check kube-bench leaves to you + +Check 3.2.2 — "ensure that the audit policy covers key security concerns" — is a manual +check, so kube-bench reports a warning and moves on. It is worth doing by hand. + +On the cluster examined here the audit policy is set to `level: Metadata`. That records who +called what and when, but not request or response bodies. For day-to-day operations it is a +reasonable default; for a regime that expects reconstruction of what actually changed — PCI +DSS requirement 10.2.1, for one — it is not enough on its own. + +Resist the obvious fix. Raising everything to `RequestResponse` writes the bodies of every +request into the audit log, and those bodies contain Secret values, tokens and whatever +personal data your users put in annotations. The log stops being a record of access and +becomes a second copy of the data it was meant to protect — now in a file with different +retention, different access control and, quite possibly, a different compliance scope. +Kubernetes' own reference policy keeps Secrets and ConfigMaps at `Metadata` for exactly this +reason. + +The workable shape is per-resource. Log role bindings, webhook configurations and admission +policy at `RequestResponse`, because knowing what changed there is the point; keep Secrets at +`Metadata`, because knowing that a Secret was read is useful and knowing its contents is a +liability. Decide the split deliberately and write down why — an assessor will accept a +reasoned policy far more readily than a maximal one. See the +[PCI DSS page](/compliance/pci-dss/) for how audit logging fits a compliance program more +broadly. + +## Which of the 53 manual checks Cozystack already answers + +Warnings are manual checks: the benchmark cannot decide them, so a human must. Thirty-four +of them are section 5, on RBAC, Pod Security and network policies, and several are already +answered by how Cozystack builds a tenant: + +- Pod Security admission enforces `baseline` and warns at `restricted`. That answers the + section 5.2 checks on privileged containers, host namespaces and hostPath — but not the + ones on running as root, dropped capabilities and seccomp profiles, which need + `restricted`, a namespace label away +- every tenant is created with a set of Cilium network policies that deny traffic from other + tenants, which you can verify with a cross-tenant probe +- the tenant role carries no `get secrets` verb. Read that as least privilege at the API + surface rather than as a confidentiality boundary: anyone who can schedule a workload in a + namespace can mount that namespace's secrets into a pod + +The remaining warnings — client certificates and service account tokens used as user +credentials, in particular — depend on how you run the cluster, not on how it ships. + +## How to run kube-bench on your own cluster + +Two things to get right before you run it. Pass `--benchmark` +explicitly — otherwise kube-bench picks one from the detected Kubernetes version, and a +different pick produces a different set of checks and different totals. And pin the image: +`latest` is not evidence, and an assessor is entitled to ask which version of which tool +produced the report. + +Create a namespace that permits host access, run the job, read the output: + +```bash +kubectl create namespace kube-bench +kubectl label namespace kube-bench pod-security.kubernetes.io/enforce=privileged +``` + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: kube-bench-master + namespace: kube-bench +spec: + backoffLimit: 1 + template: + spec: + hostPID: true + nodeName: + restartPolicy: Never + containers: + - name: kube-bench + image: docker.io/aquasec/kube-bench:v0.12.0 # pin a version, or a digest + command: ["kube-bench"] + args: + - "run" + - "--benchmark" + - "cis-1.12" + - "--targets" + - "master,controlplane,etcd,policies" + - "--json" + volumeMounts: + - { name: var-lib-etcd, mountPath: /var/lib/etcd, readOnly: true } + - { name: var-lib-kubelet, mountPath: /var/lib/kubelet, readOnly: true } + - { name: etc-kubernetes, mountPath: /etc/kubernetes, readOnly: true } + - { name: usr-bin, mountPath: /usr/local/mount-from-host/bin, readOnly: true } + volumes: + - { name: var-lib-etcd, hostPath: { path: /var/lib/etcd } } + - { name: var-lib-kubelet, hostPath: { path: /var/lib/kubelet } } + - { name: etc-kubernetes, hostPath: { path: /etc/kubernetes } } + - { name: usr-bin, hostPath: { path: /usr/bin } } +``` + +For worker checks, run the same job on a worker with `--targets node` and drop the etcd +mount. + +Treat this job as what it is: a privileged, short-lived diagnostic. It runs with `hostPID`, +in a namespace where Pod Security enforcement is switched off, and it mounts +`/var/lib/kubelet` — which holds the node's kubelet client key and the projected service +account tokens of every pod on that node. Anyone who can exec into the pod inherits the +node's identity. So run it in a namespace only cluster administrators can reach, never inside +a tenant, add `automountServiceAccountToken: false` to the pod spec, collect the JSON, and +remove the namespace as soon as you have it: + +```bash +kubectl delete namespace kube-bench +``` + +The exception this job needs from admission is deliberate and temporary — it changes nothing +about enforcement in the namespaces where workloads actually run. + +## Frequently asked questions + +### Is Cozystack CIS Kubernetes Benchmark compliant? + +The benchmark has no pass or fail verdict to award — it is a list of controls, and +compliance is a judgment about a specific cluster. On the run above, 54 controls pass and +four deviations are worth closing. Of the remaining twenty, fifteen test file modes on an +immutable node, three test a flag that structured authorization replaced, one wants a kubelet +unit file Talos has no use for, and one wants a kube-proxy that Cilium replaced. + +### Why do so many CIS checks fail on Talos Linux? + +Because most of section 1.1 checks file permissions and ownership under `/etc/kubernetes`, +and Talos keeps no such files. The controls assume a kubeadm cluster where an administrator +can edit manifests on disk. The risk those controls address is handled differently, not +ignored. + +### Can we run kube-bench ourselves? + +Yes, and you should. The manifest above is the one used for this page. Run it against your +own cluster before an assessment, and keep the output alongside your notes on which failures +are architectural. + +### Does a CIS report satisfy an auditor? + +Not on its own. An unannotated report raises more questions than it answers. What works is +the report plus a mapping: for each failure, whether it is a real deviation, a control met by +other means, or a check that does not apply — which is what this page is. + +## Notes + +This page describes Cozystack v1.6 on Kubernetes v1.34.3 as observed on a single reference +cluster — the management cluster only — measured with CIS Kubernetes Benchmark v1.12 via +kube-bench on August 18, 2026. Your installation may differ, particularly in the Talos +machine configuration, which supplies several of the settings discussed here. This page is +informational, not an assessment or a certification. diff --git a/content/en/compliance/kubernetes-conformance.md b/content/en/compliance/kubernetes-conformance.md new file mode 100644 index 00000000..4c2f224c --- /dev/null +++ b/content/en/compliance/kubernetes-conformance.md @@ -0,0 +1,190 @@ +--- +title: "CNCF Kubernetes Conformance and Cozystack" +linkTitle: "Kubernetes Conformance" +description: "What CNCF conformance testing proves, where Cozystack clusters appear in the CNCF results, and how to run the Sonobuoy conformance suite yourself." +date: 2026-08-18 +type: "page" +weight: 30 +--- + +**Kubernetes clusters created by Cozystack have passed the CNCF conformance suite on three +consecutive Kubernetes releases, and the runs are in the CNCF's public record — submitted by +a vendor, against its own installation, as the program requires.** Conformance answers a +narrow but important question: is this real Kubernetes, or something Kubernetes-shaped? A +conformant cluster runs standard manifests, Helm charts and operators without a vendor +dialect. It is not a property the project carries by itself: the CNCF certifies a named +product at a named version, and a result describes the cluster that was tested. + +## What conformance actually tests + +The Certified Kubernetes program is run by the CNCF. It has one test set — the end-to-end +tests in the Kubernetes source tree tagged `[Conformance]` — and one rule: a certification +run may skip none of them. + +The suite checks portable behavior, and only where that behavior is generally available. Do +the core APIs behave as specified, does scheduling work, do services route, do namespaces +isolate. Alpha and beta APIs sit outside the profile, and so do most of the extension points +a real workload leans on: ingress controllers, CSI drivers and their storage classes, +LoadBalancer provisioning, NetworkPolicy enforcement, performance and hardening. + +Read the badge accordingly. Conformance says *code written against the stable Kubernetes API +behaves here as the specification says it should*. It is not a promise that an arbitrary +workload runs unchanged — that depends on the extensions above, none of which a conformance +run covers. It says nothing about whether the cluster is secure, fast or well operated — for the security +posture of the platform, see [CIS Benchmark](/compliance/cis-benchmark/) and +[PCI DSS](/compliance/pci-dss/). + +## Where the Cozystack conformance results are published + +Conformance results are submitted as pull requests to +[cncf/k8s-conformance](https://github.com/cncf/k8s-conformance) and stay there permanently: +the test log, the machine-readable results, and a description of how to reproduce the run. + +Cozystack-based clusters appear in that repository for **Kubernetes v1.33, v1.34 and v1.35**, +in the folders [`v1.33/hikube`](https://github.com/cncf/k8s-conformance/tree/master/v1.33/hikube), +[`v1.34/hikube`](https://github.com/cncf/k8s-conformance/tree/master/v1.34/hikube) and +[`v1.35/hikube`](https://github.com/cncf/k8s-conformance/tree/master/v1.35/hikube). The +submitting entity is Hidora and the certified product is Hikube. The Cozystack project is not +a party to those submissions, does not certify products, and has no listing of its own — the +program certifies products, not upstream projects. Each folder holds the full `e2e.log` and +`junit_01.xml` from the run, and the reproduction steps use the platform's own API: + +```yaml +apiVersion: apps.cozystack.io/v1alpha1 +kind: Kubernetes +metadata: + name: my-first-cluster + namespace: tenant-example +spec: + controlPlane: + replicas: 3 + nodeGroups: + general: + minReplicas: 1 + maxReplicas: 5 + instanceType: "u1.xlarge" + storageClass: "replicated" +``` + +That is the same resource a tenant creates from the catalog, and it is worth being precise +about which cluster the results describe: a tenant Kubernetes cluster, whose control plane +runs as Kamaji Deployments on the management cluster. The management cluster Cozystack itself +runs on is a separate Kubernetes and was not the subject of these runs — for that one, see the +[CIS Benchmark](/compliance/cis-benchmark/) page, which covers the management cluster only. +The two pages measure different clusters on purpose. + +Certification is awarded to a named product and version, not to an upstream project, so the +listings carry the names of the entities that submitted them. The program has three +categories — Distribution, Hosted Platform and Installer — and the Cozystack-based +submissions are filed as `hosted`, meaning the certified artifact is an operated offering +rather than software you download and install yourself. If your own procurement requires a +certified product, check the listing for that exact product and version: running Cozystack +yourself does not transfer someone else's certification to your installation. + +## How to run the Kubernetes conformance suite with Sonobuoy + +Any Cozystack installation can be tested with the same suite. The tooling is +[Sonobuoy](https://github.com/vmware-tanzu/sonobuoy), which runs the suite inside the cluster +and collects the artifacts a submission needs. + +```bash +sonobuoy version # record it — the tool version is part of the evidence +kubectl version # the conformance image must match the cluster's minor version + +sonobuoy run \ + --mode=certified-conformance \ + --plugin e2e \ + --kube-conformance-image registry.k8s.io/conformance:v1.34.3 \ + --wait +outfile=$(sonobuoy retrieve) +sonobuoy results "$outfile" +sonobuoy delete --wait +``` + +Two things are worth knowing before you start. + +**Use `--mode=certified-conformance`, and understand what it switches back on.** The default +mode skips tests tagged `[Disruptive]` and the NoExecuteTaintManager cases; certified mode +runs them, because a run with skipped tests is not a valid certification run. Those tests +taint nodes, evict pods and restart components deliberately, and they run serially — which is +why a certified run takes far longer than a default one. + +**Pass `--plugin e2e` on Talos-based clusters.** Sonobuoy's default plugin set includes +`systemd-logs`, which walks every node collecting journal output. Talos Linux has no systemd, +so the plugin hangs on every node and the aggregator never reports the run complete. The +conformance tests themselves pass, but `--wait` never returns and the retrieved tarball stays +incomplete. Restricting the run to the `e2e` plugin avoids this and costs nothing for a +submission: both required artifacts, `e2e.log` and `junit_01.xml`, come from the `e2e` plugin, +and the CNCF submission asks for no `systemd-logs` output at all. + +One quirk to know before you start staring at the terminal: `sonobuoy status` may sit at +`Passed: 0` with the full test count remaining for the whole run, even while tests are +finishing normally. The aggregator's progress channel is not always wired up. Follow the e2e +pod's log instead: + +```bash +kubectl -n sonobuoy logs -l sonobuoy-plugin=e2e -c e2e -f +``` + +Expect one and a half to three hours, several hundred short-lived pods and namespaces, and at +least two schedulable worker nodes — a number of conformance tests need more than one. +Sonobuoy runs from its own namespace under a cluster-admin service account, so this is an +administrative operation on the cluster being tested, not something a tenant performs. Run it +on a cluster you can afford to disrupt, never on one carrying production traffic, and remove +the namespace afterwards with `sonobuoy delete --wait`. + +For tenant Kubernetes clusters, point your kubeconfig at the tenant cluster rather than at +the management cluster: conformance describes the cluster your workloads land in. + +## How to submit conformance results to the CNCF + +The submission is a pull request to `cncf/k8s-conformance` containing four files: `e2e.log` +and `junit_01.xml` from the run, a `README.md` describing how to reproduce it, and a +`PRODUCT.yaml` naming the product. + +One requirement in that process is organizational rather than technical: the vendor named in +`PRODUCT.yaml` must be a legal entity with a signed participation form on file with the CNCF. +The test run can be done by anyone; the listing belongs to whoever signs. + +## Frequently asked questions + +### Is Cozystack certified Kubernetes? + +Clusters created by Cozystack have passed the CNCF conformance suite for Kubernetes v1.33, +v1.34 and v1.35, and the results are published in `cncf/k8s-conformance`. The Certified +Kubernetes mark itself is granted to a named product and version, so the listings appear +under the names of the entities that submitted them rather than under the project name. + +### What does conformance guarantee? + +That standard Kubernetes APIs behave as specified, so manifests, Helm charts and operators +written for Kubernetes work without modification. It is a portability guarantee, not a +security or performance one. + +### Does conformance cover virtual machines and managed services? + +No. KubeVirt virtual machines, managed databases and the rest of the catalog are extensions +built on custom resources, and the conformance suite does not test them. It tests the +Kubernetes underneath. + +### Can we run the conformance suite on our own cluster? + +Yes, and during an evaluation it is a reasonable thing to do. The commands above are the whole +procedure, the tooling is open source, and nothing in the run depends on a vendor +relationship. Publishing the result as a certification is the separate, organizational step +described above, and it is open to any legal entity with a participation form on file with +the CNCF — not to one company. + +## Notes + +Conformance results referenced here were published to `cncf/k8s-conformance` for Kubernetes +v1.33, v1.34 and v1.35 under the product name Hikube. A listing describes one product at one +version: Kubernetes releases newer than v1.35 are not covered by those submissions, the +program expects re-certification as releases move on, and the repository — not this page — is +the current record. The Sonobuoy guidance was checked against Cozystack v1.6 on Talos Linux in +August 2026; your installation may differ. + +"Certified Kubernetes" and the Certified Kubernetes logo are marks of The Linux Foundation, +licensed to the vendor of a conformant product for the product and version it certified. +Nothing on this page is a certification, a grant of that mark, or a claim that the Cozystack +project holds one. diff --git a/content/en/compliance/pci-dss.md b/content/en/compliance/pci-dss.md index d03fba96..ecf81a11 100644 --- a/content/en/compliance/pci-dss.md +++ b/content/en/compliance/pci-dss.md @@ -243,9 +243,12 @@ the platform for workloads — but shipping the API audit log into them is not w default, and Requirement 10.3.3 expects audit logs to reach a separate, centrally managed server promptly. -Two more things to check rather than assume. The contents of the audit policy: a -`Metadata`-level policy will not produce the per-event detail Requirement 10.2.1 expects, so -sensitive resources need `RequestResponse`. And protection of the trail itself: 10.3.2 +Two more things to check rather than assume. The contents of the audit policy. A `Metadata`-level +policy will not produce the per-event detail Requirement 10.2.1 expects — but raising +everything to `RequestResponse` is the wrong correction, because request bodies carry Secret +values and personal data, and the audit log then becomes another store of the data you are +protecting. Split it by resource: `RequestResponse` for role bindings and admission +configuration, `Metadata` for Secrets. And protection of the trail itself: 10.3.2 through 10.3.4 require the log to be unmodifiable and watched by a change-detection mechanism, neither of which the platform provides. diff --git a/hugo.yaml b/hugo.yaml index bb9d7108..ea0964e0 100644 --- a/hugo.yaml +++ b/hugo.yaml @@ -329,6 +329,14 @@ menus: url: /compliance/pci-dss/ parent: compliance weight: 1 + - name: CIS Benchmark + url: /compliance/cis-benchmark/ + parent: compliance + weight: 2 + - name: Kubernetes Conformance + url: /compliance/kubernetes-conformance/ + parent: compliance + weight: 3 - name: Community url: /community/ weight: 30 From ac81300f722122482d8473433aa4cec075a97042 Mon Sep 17 00:00:00 2001 From: Timur Tukaev Date: Tue, 18 Aug 2026 17:24:56 +0600 Subject: [PATCH 2/3] docs(compliance): add GDPR and DORA pages, hold conformance for a dedicated run MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit GDPR and DORA complete the set of frameworks that were asked for. Both keep the frame the PCI DSS page set: a platform supplies measures, an organization holds the obligation, and the page says which is which. GDPR covers the Article 32 measures one at a time — where data physically sits, the three encryption layers and which of them are on by default, access control, tenant separation, restore. It spends most of its length on erasure, because that is where infrastructure and law actually collide: deleting a row is easy, deleting it from backups is not, and documented retention is the workable answer. It also warns that raising the audit policy to capture request bodies writes personal data into the audit log. DORA leads with ICT third-party risk, since that is the chapter where the choice of platform changes the answer rather than adding a checkbox: open source, own hardware, and an exit that can be rehearsed. Resilience features are listed with their limits, including the absence of automated VM failover after node loss. The Kubernetes conformance page is withdrawn for now. The certified-conformance run against the shared cluster hung after repeated failures of a single [sig-network] Services test, so there are no results worth publishing yet. It needs a dedicated cluster, and the page can follow the run. Signed-off-by: Timur Tukaev --- content/en/compliance/_index.md | 9 +- content/en/compliance/dora.md | 154 ++++++++++++++ content/en/compliance/gdpr.md | 154 ++++++++++++++ .../en/compliance/kubernetes-conformance.md | 190 ------------------ hugo.yaml | 12 +- 5 files changed, 322 insertions(+), 197 deletions(-) create mode 100644 content/en/compliance/dora.md create mode 100644 content/en/compliance/gdpr.md delete mode 100644 content/en/compliance/kubernetes-conformance.md diff --git a/content/en/compliance/_index.md b/content/en/compliance/_index.md index 2d3b317d..7dd4e23c 100644 --- a/content/en/compliance/_index.md +++ b/content/en/compliance/_index.md @@ -22,9 +22,12 @@ command you can run against your own cluster. - **[PCI DSS](/compliance/pci-dss/)** — a requirement-by-requirement mapping of what Cozystack enforces by default, what is opt-in, and what stays with you, with commands to verify each control on your own cluster. +- **[GDPR](/compliance/gdpr/)** — the Article 32 technical measures the platform supplies, + where personal data physically sits, and the awkward parts of erasure nobody should gloss + over. - **[CIS Benchmark](/compliance/cis-benchmark/)** — a full kube-bench run against Cozystack on Talos Linux, with every failure sorted into real deviations, controls met another way, and checks that do not apply. -- **[Kubernetes Conformance](/compliance/kubernetes-conformance/)** — what CNCF conformance - proves, where Cozystack-based clusters appear in the CNCF results, and how to run the - suite yourself. +- **[DORA](/compliance/dora/)** — resilience, backup and restore, incident evidence, and the + ICT third-party risk chapter where an open platform on your own hardware changes the + answer. diff --git a/content/en/compliance/dora.md b/content/en/compliance/dora.md new file mode 100644 index 00000000..bbb135f6 --- /dev/null +++ b/content/en/compliance/dora.md @@ -0,0 +1,154 @@ +--- +title: "DORA Readiness on Kubernetes with Cozystack" +linkTitle: "DORA" +description: "How Cozystack supports the EU Digital Operational Resilience Act: resilience, backup and restore, incident evidence, ICT third-party risk and exit strategy." +date: 2026-08-18 +type: "page" +weight: 25 +--- + +**DORA is a regulation about how a financial entity manages ICT risk, not a test a platform +can pass.** It asks who owns the risk, how incidents are detected and reported, how resilience +is tested, and — the part that decides most platform conversations — how dependent the entity +is on any single ICT provider. + +That last point is where the choice of platform genuinely matters, and where an open-source +platform running on your own hardware changes the shape of the answer rather than just adding +a checkbox. + +The Digital Operational Resilience Act applies to banks, insurers, payment institutions, +crypto-asset providers and their critical ICT suppliers across the EU, and has applied since +January 2025. + +## The part that actually depends on the platform + +DORA devotes a whole chapter to ICT third-party risk: register of information, contractual +requirements, concentration risk, exit strategies, and the right to audit. Regulators care +about it because a financial entity that cannot leave a provider has no real control over its +own resilience. + +Three properties matter here, and they are structural rather than features. + +**The source is open, under Apache 2.0.** Contractual continuity does not depend on one +vendor's survival, and the code can be audited by you or by a third party without asking +permission. + +**It runs on your own hardware.** No control plane in someone else's account, no vendor with +standing access required for the platform to function, no dependency on an external service +being up. What you host, you control — which is exactly the language a resilience assessment +speaks. + +**Exit is possible in practice, not only on paper.** Workloads are Kubernetes objects and +virtual machines in standard formats; there is no proprietary encapsulation to unwind. An exit +plan you can rehearse is worth more to a regulator than a clause promising cooperation. + +None of this exempts you from having a register of information, an exit strategy document, or +contracts that meet Article 30. It makes those documents easier to write truthfully. + +## Resilience: what the platform provides + +DORA expects ICT systems to withstand and recover from disruption, and to be tested against +that expectation rather than assumed to meet it. + +**Redundant storage by default.** Volumes are replicated across nodes with DRBD through +LINSTOR, so the loss of a node does not mean the loss of a volume. No separate storage array +is required for this. + +**Live migration.** Virtual machines move between nodes without shutdown, which turns planned +maintenance from an outage into an operation. + +**Declared state, continuously reconciled.** Machines and services are described as +manifests, and the platform works to keep reality matching the description. Kill a workload +directly and it comes back, because the description did not change. + +**Stretched clusters across locations.** Multi-datacenter topologies are a normal deployment +shape rather than an exotic one, which matters when your resilience requirements name +geographic separation. + +Be precise about what is *not* provided: there is no automated failover of a virtual machine +after an unplanned node loss equivalent to a dedicated HA product. Node health handling and +restart policy exist and can be composed into one, but this is configuration and rehearsal +work, not a switch. + +## Backup, restore and the evidence that they work + +Velero ships with the platform for scheduled backups, volume snapshots, virtual machine +backups and cluster state, and backup data is encrypted in object storage by default through +the kopia uploader. + +The regulation's emphasis is not on having backups but on being able to restore. Rehearse the +restore, record how long it took, and keep that record — a restore time you measured is +evidence, a restore time you estimated is not. + +## Detection, logging and incident evidence + +DORA requires incidents to be detected, classified and — for major ones — reported to the +competent authority on a short clock. That works only if the underlying record exists. + +The platform ships metrics collection, log aggregation, alerting and dashboards, and the +Kubernetes API server writes an audit log under a policy you supply. Two things to set +deliberately: retention, because defaults are shorter than a financial regulator will expect, +and the audit policy itself, per resource. Do not raise everything to full request and +response capture — that writes secrets and personal data into the log, creating a new problem +under GDPR while solving an old one here. + +Security advisories for the platform are published openly, including assessments of +vulnerabilities that turn out not to affect it. That public record is directly usable in the +threat-intelligence and vulnerability-management parts of an ICT risk framework. + +## Testing + +DORA expects a programme of resilience testing, and for significant entities, threat-led +penetration testing. + +Nothing in the platform obstructs it, and two things help. A tenant gives you an isolated +place to run destructive tests against a realistic copy rather than against production. And +because environments are described as manifests, the environment under test can be recreated +exactly, which is what makes a test result meaningful the second time. + +The [CIS Benchmark](/compliance/cis-benchmark/) page shows one such test executed against a +live cluster, together with the reasoning that turns a raw report into something an assessor +can use. + +## What stays with you + +Governance sits with the management body and cannot be delegated to a supplier: the ICT risk +framework, the register of information, incident classification and reporting within the +regulation's deadlines, the digital operational resilience testing programme, contractual +arrangements with providers, and the exit strategy itself. + +A platform can make each of those cheaper to satisfy. It cannot hold them. + +## Frequently asked questions + +### Is Cozystack DORA compliant? + +The question does not apply to a platform. Financial entities are subject to DORA; platforms +are part of the ICT estate those entities manage. Cozystack contributes replication, live +migration, backup and restore, observability, audit logging and — most usefully for Chapter V +— an architecture with no vendor dependency to unwind. + +### Does running on our own hardware remove ICT third-party risk? + +It removes the platform vendor from the critical path, which is the largest single component +of that risk in most assessments. Hardware suppliers, datacenter operators and any integrator +you contract remain third parties and belong in the register. + +### What about the right to audit? + +The source code is public, and every claim on these compliance pages can be verified against +your own cluster with the commands published alongside it. Where you contract an operator, +audit rights belong in that contract. + +### Can we test failure scenarios safely? + +Yes. Run them in a dedicated tenant, isolated by network policy from everything else, and +recreate the environment from manifests between runs. + +## Notes + +This page describes Cozystack v1.6 as observed on a reference cluster in August 2026 and is +informational. It is not legal advice, not an assessment, and not a statement that any +configuration satisfies a competent authority. Regulation (EU) 2022/2554 applies to defined +categories of financial entity and their critical ICT providers; whether it applies to you, +and in what capacity, is a question for your own counsel. diff --git a/content/en/compliance/gdpr.md b/content/en/compliance/gdpr.md new file mode 100644 index 00000000..728d7b20 --- /dev/null +++ b/content/en/compliance/gdpr.md @@ -0,0 +1,154 @@ +--- +title: "GDPR on Kubernetes: What Cozystack Provides" +linkTitle: "GDPR" +description: "Which GDPR technical measures Cozystack supplies — data residency, encryption, access control, audit and erasure — and which obligations stay with the controller." +date: 2026-08-18 +type: "page" +weight: 15 +--- + +**GDPR compliance is not a property of infrastructure.** It is a property of what an +organization does with personal data: why it holds it, on what legal basis, for how long, and +what happens when someone asks for a copy or asks to be forgotten. No platform can answer +those questions for you. + +What a platform can do is supply the technical and organizational measures that Article 32 +requires, and make them demonstrable. That is what this page covers, one measure at a time. + +The distinction matters commercially. When a customer asks "is Cozystack GDPR compliant", +the useful answer is "here is what the platform gives you towards Article 32, and here is +what remains yours" — not a yes that falls apart under a data protection officer's first +question. + +## Where the data physically lives + +This is usually the first question and the easiest to answer well. + +Cozystack installs on your own hardware, in a facility you choose. There is no control plane +in someone else's cloud, no telemetry pipeline that has to leave the building, and no vendor +who needs standing access in order for the platform to work. For Chapter V — transfers of +personal data to third countries — that removes the hardest part of the analysis before it +starts. + +If you operate in several jurisdictions, tenants and node placement let you keep processing +in one of them rather than spreading it across all of them. + +## Article 32 measures, one by one + +### Encryption of personal data + +Three layers, and they behave differently. + +**Kubernetes secrets** are encrypted in etcd where the API server runs with +`--encryption-provider-config`. That setting comes from the Talos machine configuration +supplied at install time, so confirm it on your own cluster. + +**Volumes** — the disks behind databases and virtual machines — are not encrypted unless you +ask. LINSTOR supports at-rest encryption with LUKS, enabled by creating a StorageClass with +the LUKS layer. See [Creating Encrypted Storage on LINSTOR](/docs/v1.6/storage/disk-encryption/), +and decide it at design time: converting a populated volume later means migrating the data. + +**Backups** are encrypted by default. Velero uses the kopia uploader, so backup data is +written to object storage under a repository key held in the cluster. + +For personal data held by the identity layer specifically, Cozystack v1.6 added an optional +encrypting proxy in front of the Keycloak database, giving column-level encryption backed by +a static key or Vault Transit. It is off until you enable it. + +### Confidentiality and access control + +Authentication can be centralized in Keycloak through OIDC, which puts joiners, leavers, +multi-factor authentication and password policy in one place rather than scattered across +kubeconfig files. It is not the default — a fresh cluster authenticates with a cluster +credential, which is a shared account and unsuitable for anything holding personal data. +Enable OIDC before the environment carries real data. + +Authorization is scoped to the tenant, and more tightly than teams expect: a tenant user can +create databases and virtual machines through the platform API yet cannot read raw Kubernetes +secrets. Read that as least privilege at the API surface rather than as a confidentiality +boundary — a principal who can schedule workloads in a namespace can mount that namespace's +secrets into a pod. + +### Separation of processing + +Tenants are isolated from each other by network policies created together with the tenant, +and the isolation is enforced rather than declared. If you process personal data for several +controllers, or separate production from analytics, that separation is a platform primitive +instead of a convention. + +You can verify it in a minute — start a pod in one tenant and try to reach it from another, +with a same-tenant probe as the positive control. + +### Ability to restore availability after an incident + +Article 32(1)(c) asks for the ability to restore access to personal data in a timely manner. +Velero ships with the platform for scheduled backups, volume snapshots and cluster state, and +restores are worth rehearsing rather than assuming — a backup nobody has restored is a hope, +not a measure. + +### Regular testing of measures + +Article 32(1)(d) asks for a process of testing and evaluating effectiveness. The +[CIS Benchmark](/compliance/cis-benchmark/) page shows one such test run against a live +cluster, with the failures sorted into real deviations and artifacts of the architecture. +Nothing prevents you from running it on your own schedule; the manifest is published there. + +## Erasure, and the parts of it that are awkward + +The right to erasure is where infrastructure and law meet uncomfortably, so it is worth being +concrete rather than reassuring. + +Deleting a database row is straightforward. Deleting it from **backups** is not: backups exist +precisely so that deletions can be undone. The workable position, and the one supervisory +authorities generally accept, is documented retention: state how long backups live, ensure +erased data ages out of them within that window, and do not restore it selectively afterwards. +Cozystack does not solve this for you — but it does let you set backup retention deliberately +and point backups at storage you control. + +**Audit logs** create a second version of the same problem, and it has a trap. Raising the +Kubernetes audit policy to `RequestResponse` to satisfy some other framework will write +request bodies — including personal data — into the audit log. The log then becomes a store +of personal data with its own retention and access rules. Keep sensitive resources at +`Metadata` level and split the policy by resource. + +## What stays with you + +No infrastructure product supplies any of the following, and a vendor implying otherwise is +worth distrusting: the lawful basis for processing, records of processing activities under +Article 30, data protection impact assessments, breach notification within 72 hours, +responses to data subject requests, the appointment of a data protection officer, or the +data processing agreement between you and your own customers. + +The platform is a processor's tool. The controller's obligations remain the controller's. + +## Frequently asked questions + +### Is Cozystack GDPR compliant? + +The question does not apply to infrastructure. An organization is compliant; a platform +supplies measures. Cozystack supplies encryption, access control, tenant separation, audit +logging, backup and restore, and full control over where data physically resides. + +### Does using Cozystack avoid third-country transfer problems? + +It removes the platform itself from the analysis, because Cozystack runs on your hardware and +requires no vendor access to operate. Whether your own architecture transfers data elsewhere +is a separate question about your applications and integrations. + +### Is personal data encrypted at rest by default? + +Kubernetes secrets and backups, yes. Volumes, no — that is an option you enable per +StorageClass, and it belongs in the design rather than in a later change. + +### Who is the processor when we run Cozystack ourselves? + +You are. Running open-source software on your own hardware does not introduce a processor: +there is no service, no account and no data leaving your infrastructure. If you contract an +integrator to operate the platform for you, that relationship needs its own agreement. + +## Notes + +This page describes Cozystack v1.6 as observed on a reference cluster in August 2026, and is +informational. It is not legal advice, not an assessment, and not a warranty that any +configuration satisfies a supervisory authority. Your installation may differ, particularly in +the Talos machine configuration that supplies several of the settings above. diff --git a/content/en/compliance/kubernetes-conformance.md b/content/en/compliance/kubernetes-conformance.md deleted file mode 100644 index 4c2f224c..00000000 --- a/content/en/compliance/kubernetes-conformance.md +++ /dev/null @@ -1,190 +0,0 @@ ---- -title: "CNCF Kubernetes Conformance and Cozystack" -linkTitle: "Kubernetes Conformance" -description: "What CNCF conformance testing proves, where Cozystack clusters appear in the CNCF results, and how to run the Sonobuoy conformance suite yourself." -date: 2026-08-18 -type: "page" -weight: 30 ---- - -**Kubernetes clusters created by Cozystack have passed the CNCF conformance suite on three -consecutive Kubernetes releases, and the runs are in the CNCF's public record — submitted by -a vendor, against its own installation, as the program requires.** Conformance answers a -narrow but important question: is this real Kubernetes, or something Kubernetes-shaped? A -conformant cluster runs standard manifests, Helm charts and operators without a vendor -dialect. It is not a property the project carries by itself: the CNCF certifies a named -product at a named version, and a result describes the cluster that was tested. - -## What conformance actually tests - -The Certified Kubernetes program is run by the CNCF. It has one test set — the end-to-end -tests in the Kubernetes source tree tagged `[Conformance]` — and one rule: a certification -run may skip none of them. - -The suite checks portable behavior, and only where that behavior is generally available. Do -the core APIs behave as specified, does scheduling work, do services route, do namespaces -isolate. Alpha and beta APIs sit outside the profile, and so do most of the extension points -a real workload leans on: ingress controllers, CSI drivers and their storage classes, -LoadBalancer provisioning, NetworkPolicy enforcement, performance and hardening. - -Read the badge accordingly. Conformance says *code written against the stable Kubernetes API -behaves here as the specification says it should*. It is not a promise that an arbitrary -workload runs unchanged — that depends on the extensions above, none of which a conformance -run covers. It says nothing about whether the cluster is secure, fast or well operated — for the security -posture of the platform, see [CIS Benchmark](/compliance/cis-benchmark/) and -[PCI DSS](/compliance/pci-dss/). - -## Where the Cozystack conformance results are published - -Conformance results are submitted as pull requests to -[cncf/k8s-conformance](https://github.com/cncf/k8s-conformance) and stay there permanently: -the test log, the machine-readable results, and a description of how to reproduce the run. - -Cozystack-based clusters appear in that repository for **Kubernetes v1.33, v1.34 and v1.35**, -in the folders [`v1.33/hikube`](https://github.com/cncf/k8s-conformance/tree/master/v1.33/hikube), -[`v1.34/hikube`](https://github.com/cncf/k8s-conformance/tree/master/v1.34/hikube) and -[`v1.35/hikube`](https://github.com/cncf/k8s-conformance/tree/master/v1.35/hikube). The -submitting entity is Hidora and the certified product is Hikube. The Cozystack project is not -a party to those submissions, does not certify products, and has no listing of its own — the -program certifies products, not upstream projects. Each folder holds the full `e2e.log` and -`junit_01.xml` from the run, and the reproduction steps use the platform's own API: - -```yaml -apiVersion: apps.cozystack.io/v1alpha1 -kind: Kubernetes -metadata: - name: my-first-cluster - namespace: tenant-example -spec: - controlPlane: - replicas: 3 - nodeGroups: - general: - minReplicas: 1 - maxReplicas: 5 - instanceType: "u1.xlarge" - storageClass: "replicated" -``` - -That is the same resource a tenant creates from the catalog, and it is worth being precise -about which cluster the results describe: a tenant Kubernetes cluster, whose control plane -runs as Kamaji Deployments on the management cluster. The management cluster Cozystack itself -runs on is a separate Kubernetes and was not the subject of these runs — for that one, see the -[CIS Benchmark](/compliance/cis-benchmark/) page, which covers the management cluster only. -The two pages measure different clusters on purpose. - -Certification is awarded to a named product and version, not to an upstream project, so the -listings carry the names of the entities that submitted them. The program has three -categories — Distribution, Hosted Platform and Installer — and the Cozystack-based -submissions are filed as `hosted`, meaning the certified artifact is an operated offering -rather than software you download and install yourself. If your own procurement requires a -certified product, check the listing for that exact product and version: running Cozystack -yourself does not transfer someone else's certification to your installation. - -## How to run the Kubernetes conformance suite with Sonobuoy - -Any Cozystack installation can be tested with the same suite. The tooling is -[Sonobuoy](https://github.com/vmware-tanzu/sonobuoy), which runs the suite inside the cluster -and collects the artifacts a submission needs. - -```bash -sonobuoy version # record it — the tool version is part of the evidence -kubectl version # the conformance image must match the cluster's minor version - -sonobuoy run \ - --mode=certified-conformance \ - --plugin e2e \ - --kube-conformance-image registry.k8s.io/conformance:v1.34.3 \ - --wait -outfile=$(sonobuoy retrieve) -sonobuoy results "$outfile" -sonobuoy delete --wait -``` - -Two things are worth knowing before you start. - -**Use `--mode=certified-conformance`, and understand what it switches back on.** The default -mode skips tests tagged `[Disruptive]` and the NoExecuteTaintManager cases; certified mode -runs them, because a run with skipped tests is not a valid certification run. Those tests -taint nodes, evict pods and restart components deliberately, and they run serially — which is -why a certified run takes far longer than a default one. - -**Pass `--plugin e2e` on Talos-based clusters.** Sonobuoy's default plugin set includes -`systemd-logs`, which walks every node collecting journal output. Talos Linux has no systemd, -so the plugin hangs on every node and the aggregator never reports the run complete. The -conformance tests themselves pass, but `--wait` never returns and the retrieved tarball stays -incomplete. Restricting the run to the `e2e` plugin avoids this and costs nothing for a -submission: both required artifacts, `e2e.log` and `junit_01.xml`, come from the `e2e` plugin, -and the CNCF submission asks for no `systemd-logs` output at all. - -One quirk to know before you start staring at the terminal: `sonobuoy status` may sit at -`Passed: 0` with the full test count remaining for the whole run, even while tests are -finishing normally. The aggregator's progress channel is not always wired up. Follow the e2e -pod's log instead: - -```bash -kubectl -n sonobuoy logs -l sonobuoy-plugin=e2e -c e2e -f -``` - -Expect one and a half to three hours, several hundred short-lived pods and namespaces, and at -least two schedulable worker nodes — a number of conformance tests need more than one. -Sonobuoy runs from its own namespace under a cluster-admin service account, so this is an -administrative operation on the cluster being tested, not something a tenant performs. Run it -on a cluster you can afford to disrupt, never on one carrying production traffic, and remove -the namespace afterwards with `sonobuoy delete --wait`. - -For tenant Kubernetes clusters, point your kubeconfig at the tenant cluster rather than at -the management cluster: conformance describes the cluster your workloads land in. - -## How to submit conformance results to the CNCF - -The submission is a pull request to `cncf/k8s-conformance` containing four files: `e2e.log` -and `junit_01.xml` from the run, a `README.md` describing how to reproduce it, and a -`PRODUCT.yaml` naming the product. - -One requirement in that process is organizational rather than technical: the vendor named in -`PRODUCT.yaml` must be a legal entity with a signed participation form on file with the CNCF. -The test run can be done by anyone; the listing belongs to whoever signs. - -## Frequently asked questions - -### Is Cozystack certified Kubernetes? - -Clusters created by Cozystack have passed the CNCF conformance suite for Kubernetes v1.33, -v1.34 and v1.35, and the results are published in `cncf/k8s-conformance`. The Certified -Kubernetes mark itself is granted to a named product and version, so the listings appear -under the names of the entities that submitted them rather than under the project name. - -### What does conformance guarantee? - -That standard Kubernetes APIs behave as specified, so manifests, Helm charts and operators -written for Kubernetes work without modification. It is a portability guarantee, not a -security or performance one. - -### Does conformance cover virtual machines and managed services? - -No. KubeVirt virtual machines, managed databases and the rest of the catalog are extensions -built on custom resources, and the conformance suite does not test them. It tests the -Kubernetes underneath. - -### Can we run the conformance suite on our own cluster? - -Yes, and during an evaluation it is a reasonable thing to do. The commands above are the whole -procedure, the tooling is open source, and nothing in the run depends on a vendor -relationship. Publishing the result as a certification is the separate, organizational step -described above, and it is open to any legal entity with a participation form on file with -the CNCF — not to one company. - -## Notes - -Conformance results referenced here were published to `cncf/k8s-conformance` for Kubernetes -v1.33, v1.34 and v1.35 under the product name Hikube. A listing describes one product at one -version: Kubernetes releases newer than v1.35 are not covered by those submissions, the -program expects re-certification as releases move on, and the repository — not this page — is -the current record. The Sonobuoy guidance was checked against Cozystack v1.6 on Talos Linux in -August 2026; your installation may differ. - -"Certified Kubernetes" and the Certified Kubernetes logo are marks of The Linux Foundation, -licensed to the vendor of a conformant product for the product and version it certified. -Nothing on this page is a certification, a grant of that mark, or a claim that the Cozystack -project holds one. diff --git a/hugo.yaml b/hugo.yaml index ea0964e0..6df56600 100644 --- a/hugo.yaml +++ b/hugo.yaml @@ -329,14 +329,18 @@ menus: url: /compliance/pci-dss/ parent: compliance weight: 1 - - name: CIS Benchmark - url: /compliance/cis-benchmark/ + - name: GDPR + url: /compliance/gdpr/ parent: compliance weight: 2 - - name: Kubernetes Conformance - url: /compliance/kubernetes-conformance/ + - name: CIS Benchmark + url: /compliance/cis-benchmark/ parent: compliance weight: 3 + - name: DORA + url: /compliance/dora/ + parent: compliance + weight: 4 - name: Community url: /community/ weight: 30 From 99e05d2de8b77c8b4283a9c1e7dcd7e66552cadb Mon Sep 17 00:00:00 2001 From: Timur Tukaev Date: Tue, 18 Aug 2026 17:39:42 +0600 Subject: [PATCH 3/3] docs(compliance): lead with what the platform provides, and fix the legal detail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Two rounds of review, and both changed the pages substantially. The first was framing. Every page opened by naming a limitation — 'not certified', 'not something a platform can have', 'two dozen failures' — which is a defensive posture that reads as an apology before the reader knows what is being apologised for. The openings now state what the platform provides, and the caveats keep their place a paragraph later, where they inform rather than ambush. The merged PCI DSS page had the same problem and is corrected here. The second was legal accuracy, and it caught real errors: - GDPR mixed up the roles. Self-hosting makes you a controller for data whose purposes and means you determine, not a processor; a processor appears only where you host for someone else. The FAQ said the opposite. - 'Personal data encrypted at rest by default' was answered yes on the strength of secrets and backups, while the volumes that actually hold personal data are not encrypted unless you enable it. - Tenant network isolation was presented as separation of processing. It is not: control plane, etcd, LINSTOR and identity are shared, administrators cross every tenant, and platform backups share one bucket separated by path. - Article 32(1)(b) integrity was missing entirely, including the absence of intrusion detection and file-integrity monitoring. - Remote access from a third country is itself a transfer under the EDPB's reading, so self-hosting narrows Chapter V rather than closing it. - DORA promised redundant storage 'by default'; replication is a property of the StorageClass, and local classes exist. - DORA omitted that platform backups default to a bucket inside the cluster they protect, which meets neither Article 12(2) nor 12(3). - TLPT was tied to 'significant entities', a category DORA does not use, and a tenant copy was implied to substitute for tests Article 26 runs against live production. Also: the audit log is already a store of personal data at Metadata level, since it records usernames, groups and source addresses — it needs its own Article 30 entry regardless of policy level. Signed-off-by: Timur Tukaev --- content/en/compliance/_index.md | 4 +- content/en/compliance/cis-benchmark.md | 22 +-- content/en/compliance/dora.md | 132 +++++++++++------ content/en/compliance/gdpr.md | 187 ++++++++++++++++--------- content/en/compliance/pci-dss.md | 20 +-- 5 files changed, 236 insertions(+), 129 deletions(-) diff --git a/content/en/compliance/_index.md b/content/en/compliance/_index.md index 7dd4e23c..4621c6af 100644 --- a/content/en/compliance/_index.md +++ b/content/en/compliance/_index.md @@ -1,7 +1,7 @@ --- -title: "Compliance on Kubernetes: PCI DSS and Security Benchmarks" +title: "Compliance on Kubernetes: PCI DSS, GDPR, DORA, CIS" linkTitle: "Compliance" -description: "How Cozystack supports PCI DSS and other compliance work: which controls the platform provides by default, which are opt-in, and which stay with you." +description: "How Cozystack supports PCI DSS, GDPR, DORA and the CIS Benchmark: which controls the platform provides by default, which are opt-in, and which stay with you." type: "page" weight: 45 --- diff --git a/content/en/compliance/cis-benchmark.md b/content/en/compliance/cis-benchmark.md index f5e1a2e1..7d75fe87 100644 --- a/content/en/compliance/cis-benchmark.md +++ b/content/en/compliance/cis-benchmark.md @@ -7,14 +7,20 @@ type: "page" weight: 20 --- -**A raw kube-bench report on Cozystack shows two dozen failures, and four of them matter.** The rest are the benchmark looking for files that Talos Linux does not have, or -checking a Kubernetes flag that newer releases replaced. This page shows the whole run, -sorts every failure into one of three buckets, and gives you the manifest to reproduce it on -your own cluster. - -That sorting is the work. Handing an auditor an unannotated kube-bench report is worse than -handing them nothing: they see twenty-four red lines, and you spend the rest of the meeting -explaining architecture instead of security. +**Cozystack starts from a hardened position, and the numbers say so: 54 CIS controls pass on +a cluster nobody tuned for the test.** The node operating system is immutable and has no +shell, privileged workloads are refused by admission, every etcd control passes, and tenants +come with network isolation already applied. + +This page publishes the full run rather than the flattering part of it. A raw kube-bench +report also lists two dozen failures, and the useful work is telling them apart: most are the +benchmark looking for files an immutable node does not keep, or testing a flag that newer +Kubernetes releases replaced. Four are worth your attention, and each is covered below with +the reasoning behind it. + +That sorting is the point. Handing an auditor an unannotated kube-bench report is worse than +handing them nothing: they see red lines, and you spend the meeting explaining architecture +instead of security. ## What the kube-bench run covered diff --git a/content/en/compliance/dora.md b/content/en/compliance/dora.md index bbb135f6..0741a4d0 100644 --- a/content/en/compliance/dora.md +++ b/content/en/compliance/dora.md @@ -1,33 +1,40 @@ --- -title: "DORA Readiness on Kubernetes with Cozystack" +title: "DORA on Kubernetes: ICT Third-Party Risk and Resilience" linkTitle: "DORA" -description: "How Cozystack supports the EU Digital Operational Resilience Act: resilience, backup and restore, incident evidence, ICT third-party risk and exit strategy." +description: "DORA on Kubernetes: how Cozystack supports digital operational resilience — backup and restore, incident evidence, ICT third-party risk and exit strategy." date: 2026-08-18 type: "page" weight: 25 --- -**DORA is a regulation about how a financial entity manages ICT risk, not a test a platform -can pass.** It asks who owns the risk, how incidents are detected and reported, how resilience -is tested, and — the part that decides most platform conversations — how dependent the entity -is on any single ICT provider. +**For the chapter of DORA that decides most platform conversations — dependence on a single +ICT provider — Cozystack is about as good an answer as infrastructure gets.** It is +open-source software under Apache 2.0, it runs on your own hardware, and leaving it means +moving standard Kubernetes objects and virtual machines rather than unwinding a proprietary +format. An exit strategy you can rehearse beats a clause promising cooperation. -That last point is where the choice of platform genuinely matters, and where an open-source -platform running on your own hardware changes the shape of the answer rather than just adding -a checkbox. +The resilience side is solid too: replicated storage across nodes, live migration between +them, declared state that the platform continuously restores, multi-datacenter topologies as +a normal deployment shape, backups encrypted by default. This page goes through all of it, +and marks the handful of places where you need to configure something rather than inherit it. -The Digital Operational Resilience Act applies to banks, insurers, payment institutions, -crypto-asset providers and their critical ICT suppliers across the EU, and has applied since -January 2025. +What the platform cannot do is hold the obligation. The Digital Operational Resilience Act — +Regulation (EU) 2022/2554 — has applied since 17 January 2025 and binds the categories of +financial entity listed in Article 2: banks, insurers, investment firms, payment and e-money +institutions, crypto-asset service providers and others. ICT third-party service providers +are not in scope directly; a small number are designated critical by the European Supervisory +Authorities under Article 31 and placed under an EU Oversight Framework with a Lead Overseer, +which is a different regime from the competent-authority supervision financial entities face. -## The part that actually depends on the platform +## ICT third-party risk: the part that depends on the platform DORA devotes a whole chapter to ICT third-party risk: register of information, contractual requirements, concentration risk, exit strategies, and the right to audit. Regulators care about it because a financial entity that cannot leave a provider has no real control over its own resilience. -Three properties matter here, and they are structural rather than features. +Three properties matter here. None is a feature you enable; each follows from how the +platform is built and licensed. **The source is open, under Apache 2.0.** Contractual continuity does not depend on one vendor's survival, and the code can be audited by you or by a third party without asking @@ -35,24 +42,28 @@ permission. **It runs on your own hardware.** No control plane in someone else's account, no vendor with standing access required for the platform to function, no dependency on an external service -being up. What you host, you control — which is exactly the language a resilience assessment -speaks. +being up. What you host, you control. **Exit is possible in practice, not only on paper.** Workloads are Kubernetes objects and virtual machines in standard formats; there is no proprietary encapsulation to unwind. An exit plan you can rehearse is worth more to a regulator than a clause promising cooperation. -None of this exempts you from having a register of information, an exit strategy document, or -contracts that meet Article 30. It makes those documents easier to write truthfully. +None of this exempts you from maintaining the register of information required by Article +28(3), from holding an exit strategy under Article 28(8), or from contracts carrying the key +provisions of Article 30 of DORA — a different Article 30 from the GDPR one. It makes those +documents easier to write truthfully. ## Resilience: what the platform provides DORA expects ICT systems to withstand and recover from disruption, and to be tested against that expectation rather than assumed to meet it. -**Redundant storage by default.** Volumes are replicated across nodes with DRBD through -LINSTOR, so the loss of a node does not mean the loss of a volume. No separate storage array -is required for this. +**Replicated storage, where the StorageClass asks for it.** LINSTOR places volumes with DRBD +replication across nodes, so a replicated volume survives the loss of a node holding one of +its copies. Replication is a property of the StorageClass rather than of the platform — local, +non-replicated classes exist and are the right choice for some workloads — so check which +class each critical or important function actually uses. No separate storage array is required +either way. **Live migration.** Virtual machines move between nodes without shutdown, which turns planned maintenance from an outage into an operation. @@ -65,10 +76,10 @@ directly and it comes back, because the description did not change. shape rather than an exotic one, which matters when your resilience requirements name geographic separation. -Be precise about what is *not* provided: there is no automated failover of a virtual machine -after an unplanned node loss equivalent to a dedicated HA product. Node health handling and -restart policy exist and can be composed into one, but this is configuration and rehearsal -work, not a switch. +Be precise about what is *not* provided. There is no automated virtual machine failover after +unplanned node loss of the kind a dedicated HA product gives you. Node health handling and +restart policies exist and can be combined into a failover procedure, but that is +configuration and rehearsal work, not a switch. ## Backup, restore and the evidence that they work @@ -76,9 +87,17 @@ Velero ships with the platform for scheduled backups, volume snapshots, virtual backups and cluster state, and backup data is encrypted in object storage by default through the kopia uploader. +Where those backups land needs a decision before an assessment, not after. Platform-managed +backups default to a shared `cozy-backups` bucket in `tenant-root`, separated between tenants +by object path. Article 12(2) expects restoration to run on systems physically and logically +segregated from the source, and Article 12(3) expects backup systems not to be directly +connected to the primary one — a bucket inside the cluster being protected meets neither. +Point the BackupClass at storage outside the cluster, with its own credentials and its own +key, and say so in the backup policy Article 12(1) asks you to write. + The regulation's emphasis is not on having backups but on being able to restore. Rehearse the -restore, record how long it took, and keep that record — a restore time you measured is -evidence, a restore time you estimated is not. +restore against a defined recovery time and recovery point objective, record what you actually +achieved, and keep that record. A restore time you measured is evidence; an estimate is not. ## Detection, logging and incident evidence @@ -86,25 +105,33 @@ DORA requires incidents to be detected, classified and — for major ones — re competent authority on a short clock. That works only if the underlying record exists. The platform ships metrics collection, log aggregation, alerting and dashboards, and the -Kubernetes API server writes an audit log under a policy you supply. Two things to set -deliberately: retention, because defaults are shorter than a financial regulator will expect, -and the audit policy itself, per resource. Do not raise everything to full request and -response capture — that writes secrets and personal data into the log, creating a new problem -under GDPR while solving an old one here. +Kubernetes API server writes an audit log under a policy you supply. Set two things +deliberately. Retention first: the default on the cluster examined here is thirty days, shorter than a +financial supervisor will expect for records touching critical or important functions. Then the audit policy, resource by resource — do not raise everything to full request +and response capture, which writes secrets and personal data into the log and buys a GDPR +problem to settle a DORA one. Security advisories for the platform are published openly, including assessments of vulnerabilities that turn out not to affect it. That public record is directly usable in the threat-intelligence and vulnerability-management parts of an ICT risk framework. -## Testing +## Testing resilience without touching production + +DORA expects a program of digital operational resilience testing under Chapter IV, and +threat-led penetration testing under Article 26 for those entities their competent authority +identifies as in scope for it — a designation based on risk profile and systemic importance, +not a category you can read off your own balance sheet. -DORA expects a programme of resilience testing, and for significant entities, threat-led -penetration testing. +Two properties of the platform help the general program. A tenant gives you an isolated place +to run destructive tests against a realistic copy. And because environments are described as +manifests, the environment under test can be recreated exactly, which is what makes a test +result meaningful the second time. -Nothing in the platform obstructs it, and two things help. A tenant gives you an isolated -place to run destructive tests against a realistic copy rather than against production. And -because environments are described as manifests, the environment under test can be recreated -exactly, which is what makes a test result meaningful the second time. +TLPT is a different exercise, and the distinction matters: Article 26 tests run against live +production systems supporting critical or important functions, so a tenant copy does not +substitute for one. Where the platform is operated for you, or supports a critical or +important function, the ICT third-party service providers involved are drawn into the scope of +that test and have to be arranged with in advance. The [CIS Benchmark](/compliance/cis-benchmark/) page shows one such test executed against a live cluster, together with the reasoning that turns a raw report into something an assessor @@ -114,7 +141,7 @@ can use. Governance sits with the management body and cannot be delegated to a supplier: the ICT risk framework, the register of information, incident classification and reporting within the -regulation's deadlines, the digital operational resilience testing programme, contractual +regulation's deadlines, the digital operational resilience testing program, contractual arrangements with providers, and the exit strategy itself. A platform can make each of those cheaper to satisfy. It cannot hold them. @@ -130,15 +157,28 @@ migration, backup and restore, observability, audit logging and — most usefull ### Does running on our own hardware remove ICT third-party risk? -It removes the platform vendor from the critical path, which is the largest single component -of that risk in most assessments. Hardware suppliers, datacenter operators and any integrator -you contract remain third parties and belong in the register. +Self-hosting removes the platform vendor from the critical path — often the largest single +component of that risk. Hardware suppliers, datacenter operators and any integrator you +contract remain third parties and belong in the register of information. + +### Does Cozystack go into our register of information? + +The register under Article 28(3) records *contractual arrangements* for the use of ICT +services. Downloading and self-hosting Apache 2.0 software creates no contractual arrangement, +so there is no counterparty to name and nothing about the project itself to register. The +moment you buy support, hosting or integration around it, that supplier is an ICT third-party +service provider under Article 3(19) and belongs in the register, with the function it +supports and whether that function is critical or important. Confirm the treatment with your +own competent authority — supervisory practice on open-source components is not uniform. ### What about the right to audit? -The source code is public, and every claim on these compliance pages can be verified against -your own cluster with the commands published alongside it. Where you contract an operator, -audit rights belong in that contract. +Article 30(3)(e) is a contractual right of access, inspection and audit for you and for your +competent authority, exercised against a provider. With no provider in the path there is no +contract to carry it, and inspecting the platform means reading public source and running +checks against your own cluster. Where you contract an operator, those access and audit rights +— and the Article 30(3)(f) exit and transition provisions — belong in that contract rather +than in a claim about the software. ### Can we test failure scenarios safely? diff --git a/content/en/compliance/gdpr.md b/content/en/compliance/gdpr.md index 728d7b20..5e3020c7 100644 --- a/content/en/compliance/gdpr.md +++ b/content/en/compliance/gdpr.md @@ -1,39 +1,47 @@ --- -title: "GDPR on Kubernetes: What Cozystack Provides" +title: "GDPR Compliance on Kubernetes with Cozystack" linkTitle: "GDPR" -description: "Which GDPR technical measures Cozystack supplies — data residency, encryption, access control, audit and erasure — and which obligations stay with the controller." +description: "GDPR on self-hosted Kubernetes: which Article 32 measures Cozystack supplies — data residency, encryption, access control, erasure — and which stay yours." date: 2026-08-18 type: "page" weight: 15 --- -**GDPR compliance is not a property of infrastructure.** It is a property of what an -organization does with personal data: why it holds it, on what legal basis, for how long, and -what happens when someone asks for a copy or asks to be forgotten. No platform can answer -those questions for you. +**Personal data on Cozystack stays where you put it.** The platform is open-source software +built on Kubernetes, KubeVirt and Talos Linux that runs on your own hardware: no control plane +in someone else's cloud, no vendor account, no service to sign up for. On top of that it +brings the measures Article 32 asks about — encryption in transit and for backups, centralized +identity, tenant isolation enforced by network policy, audit logging, backup and restore. -What a platform can do is supply the technical and organizational measures that Article 32 -requires, and make them demonstrable. That is what this page covers, one measure at a time. +That is a strong starting position, and this page walks through it measure by measure. It also +marks the places where a control is available but off until you enable it, and the two or +three questions a data protection officer will raise that no infrastructure can answer for +you. Better to meet those here than in a meeting. -The distinction matters commercially. When a customer asks "is Cozystack GDPR compliant", -the useful answer is "here is what the platform gives you towards Article 32, and here is -what remains yours" — not a yes that falls apart under a data protection officer's first -question. +One framing worth keeping. Compliance belongs to the organization holding the data — why it +holds it, on what legal basis, for how long. A platform supplies measures and makes them +demonstrable; the useful answer to "is Cozystack GDPR compliant" is what follows below, not a +yes that falls apart under the first question. -## Where the data physically lives +## Data residency: where the data physically lives -This is usually the first question and the easiest to answer well. +Residency is usually the first question, and the easiest one to answer well. Cozystack installs on your own hardware, in a facility you choose. There is no control plane -in someone else's cloud, no telemetry pipeline that has to leave the building, and no vendor -who needs standing access in order for the platform to work. For Chapter V — transfers of -personal data to third countries — that removes the hardest part of the analysis before it -starts. +in someone else's cloud, no vendor who needs standing access in order for the platform to +work, and the platform requires no telemetry channel to a vendor in order to run. For Chapter +V — transfers of personal data to third countries — that removes the largest single element +from the analysis. -If you operate in several jurisdictions, tenants and node placement let you keep processing -in one of them rather than spreading it across all of them. +It does not close it. Under the EDPB's reading, remote access from a third country is itself a +transfer, so support engineers, an integrator's staff, out-of-hours administrators and +anything you connect for observability all still count. The outbound paths the cluster does +use — container registries, certificate authorities, time sources and update channels — are +worth listing once, because they say where the environment reaches even when the personal data +does not. If you operate in several jurisdictions, tenants and node placement let you keep +processing in one of them rather than spreading it across all of them. -## Article 32 measures, one by one +## Which Article 32 measures Cozystack covers ### Encryption of personal data @@ -43,10 +51,17 @@ Three layers, and they behave differently. `--encryption-provider-config`. That setting comes from the Talos machine configuration supplied at install time, so confirm it on your own cluster. -**Volumes** — the disks behind databases and virtual machines — are not encrypted unless you -ask. LINSTOR supports at-rest encryption with LUKS, enabled by creating a StorageClass with -the LUKS layer. See [Creating Encrypted Storage on LINSTOR](/docs/v1.6/storage/disk-encryption/), -and decide it at design time: converting a populated volume later means migrating the data. +**Volumes** — the disks behind databases and virtual machines, which is where personal data +actually sits — are not encrypted unless you ask. LINSTOR supports at-rest encryption with +LUKS, enabled by setting a passphrase and creating a StorageClass that includes the LUKS +layer. See [Creating Encrypted Storage on LINSTOR](/docs/v1.6/storage/disk-encryption/), and +decide it at design time: converting a populated volume later means migrating the data. + +Two consequences belong in the same decision, because they cut against Article 32(1)(b) and +(c) rather than for them. The passphrase is a single shared secret with no rotation procedure, +split knowledge or dual control, so key management is a process you build around it. And it +must be entered by hand after every restart of the LINSTOR controller — encrypted volumes do +not come back on their own, which turns an unattended restart into an availability event. **Backups** are encrypted by default. Velero uses the kopia uploader, so backup data is written to object storage under a repository key held in the cluster. @@ -58,26 +73,51 @@ a static key or Vault Transit. It is off until you enable it. ### Confidentiality and access control Authentication can be centralized in Keycloak through OIDC, which puts joiners, leavers, -multi-factor authentication and password policy in one place rather than scattered across -kubeconfig files. It is not the default — a fresh cluster authenticates with a cluster +multi-factor authentication and password policy in one place instead of scattering them +across kubeconfig files. It is not the default — a fresh cluster authenticates with a cluster credential, which is a shared account and unsuitable for anything holding personal data. Enable OIDC before the environment carries real data. Authorization is scoped to the tenant, and more tightly than teams expect: a tenant user can create databases and virtual machines through the platform API yet cannot read raw Kubernetes -secrets. Read that as least privilege at the API surface rather than as a confidentiality -boundary — a principal who can schedule workloads in a namespace can mount that namespace's -secrets into a pod. +secrets. Check it rather than take it on trust — as the tenant user, against the tenant +namespace: -### Separation of processing +```bash +kubectl auth can-i --list -n tenant-a +kubectl auth can-i get secrets -n tenant-a +``` -Tenants are isolated from each other by network policies created together with the tenant, -and the isolation is enforced rather than declared. If you process personal data for several -controllers, or separate production from analytics, that separation is a platform primitive -instead of a convention. +The second returns `no`. Read that as least privilege at the API surface rather than as a +confidentiality boundary — a principal who can schedule workloads in a namespace can mount +that namespace's secrets into a pod, so the boundary holds only as far as you also restrict +workload creation. + +### Separation of processing -You can verify it in a minute — start a pod in one tenant and try to reach it from another, -with a same-tenant probe as the positive control. +Tenants are isolated from each other at the network layer by Cilium policies created together +with the tenant, and that isolation is enforced rather than declared. You can verify it in a +minute — start a pod in one tenant and try to reach it from another, with a same-tenant probe +as the positive control: the cross-tenant probe returns `000`, the same-tenant one `200`. + +Read it for what it is. Network separation is not separation of processing in the sense a data +protection officer means. The control plane, etcd, LINSTOR and the identity layer are shared +services, platform administrators see across every tenant, and platform-managed backups land +in a single `cozy-backups` bucket in `tenant-root` separated between tenants by object path +rather than by credentials or by key. Tenant egress to the internet is not restricted by +default either, so an exfiltration path stays open until you add a `SecurityGroup` or an +egress allow-list. If you process personal data for several controllers, treat the tenant as a +strong first boundary and document the shared components and the administrators who cross +it — that is the part a data protection officer will ask about. + +### Integrity of processing systems + +Article 32(1)(b) names integrity alongside confidentiality, availability and resilience, and +this is the measure with the largest gap. Immutable node images and digest-pinned platform +components make undetected drift harder, and the audit log records who changed what through +the API. But no intrusion detection, no file-integrity monitoring and no change-detection +mechanism ship with the platform. Nothing prevents you running one, and if your risk +assessment calls for it, that is an addition you make rather than a control you inherit. ### Ability to restore availability after an incident @@ -93,33 +133,45 @@ Article 32(1)(d) asks for a process of testing and evaluating effectiveness. The cluster, with the failures sorted into real deviations and artifacts of the architecture. Nothing prevents you from running it on your own schedule; the manifest is published there. -## Erasure, and the parts of it that are awkward +## The right to erasure, and where it gets awkward The right to erasure is where infrastructure and law meet uncomfortably, so it is worth being concrete rather than reassuring. Deleting a database row is straightforward. Deleting it from **backups** is not: backups exist -precisely so that deletions can be undone. The workable position, and the one supervisory -authorities generally accept, is documented retention: state how long backups live, ensure -erased data ages out of them within that window, and do not restore it selectively afterwards. +precisely so that deletions can be undone. The commonly used position — one several supervisory +authorities have described as workable, without it being settled across the EEA — is +documented retention: state how long backups live, put the data beyond use in the meantime, +ensure erased data ages out within that window, and do not reintroduce it selectively on +restore. Record the reasoning, tell the data subject when the erasure will complete, and check +the position against your own authority's guidance rather than against this page. Cozystack does not solve this for you — but it does let you set backup retention deliberately and point backups at storage you control. -**Audit logs** create a second version of the same problem, and it has a trap. Raising the -Kubernetes audit policy to `RequestResponse` to satisfy some other framework will write -request bodies — including personal data — into the audit log. The log then becomes a store -of personal data with its own retention and access rules. Keep sensitive resources at -`Metadata` level and split the policy by resource. +**Audit logs** create a second version of the same problem. Start from the fact that the audit +log is already a store of personal data: at the default `level: Metadata` it records +usernames, groups and source IP addresses, which are personal data about your administrators +regardless of what the requests contained. It needs an entry in your Article 30 records, a +retention period and an access rule of its own — the default retention on the cluster examined +here is thirty days. + +The trap sits one level up. Raising the policy to `RequestResponse` to satisfy some other +framework writes request bodies — secret values, and whatever personal data your users put in +annotations — into the same file. Split the policy by resource instead: `RequestResponse` +where knowing what changed is the point, `Metadata` for secrets and for anything carrying +personal data. ## What stays with you -No infrastructure product supplies any of the following, and a vendor implying otherwise is -worth distrusting: the lawful basis for processing, records of processing activities under -Article 30, data protection impact assessments, breach notification within 72 hours, -responses to data subject requests, the appointment of a data protection officer, or the -data processing agreement between you and your own customers. +No infrastructure product supplies any of the following: the lawful basis for processing, +records of processing activities under Article 30, data protection impact assessments where +Article 35 requires them, notification of a personal data breach to the supervisory authority +within 72 hours under Article 33, responses to data subject requests, the appointment of a +data protection officer where Article 37 requires one, and the Article 28 agreement with +anyone who processes personal data on your behalf. -The platform is a processor's tool. The controller's obligations remain the controller's. +The platform is a tool. The obligations sit with whoever determines the purposes and means of +the processing. ## Frequently asked questions @@ -129,22 +181,29 @@ The question does not apply to infrastructure. An organization is compliant; a p supplies measures. Cozystack supplies encryption, access control, tenant separation, audit logging, backup and restore, and full control over where data physically resides. -### Does using Cozystack avoid third-country transfer problems? +### Does self-hosting Cozystack avoid third-country transfer problems? -It removes the platform itself from the analysis, because Cozystack runs on your hardware and -requires no vendor access to operate. Whether your own architecture transfers data elsewhere -is a separate question about your applications and integrations. +Self-hosting removes the platform itself from the Chapter V analysis: Cozystack runs on your +hardware and needs no vendor access to operate. Whether your own architecture moves data +elsewhere is a separate question, about your applications and integrations. ### Is personal data encrypted at rest by default? -Kubernetes secrets and backups, yes. Volumes, no — that is an option you enable per -StorageClass, and it belongs in the design rather than in a later change. - -### Who is the processor when we run Cozystack ourselves? - -You are. Running open-source software on your own hardware does not introduce a processor: -there is no service, no account and no data leaving your infrastructure. If you contract an -integrator to operate the platform for you, that relationship needs its own agreement. +For the storage that actually holds personal data — the volumes behind databases and virtual +machines — no. Volume encryption is opt-in per StorageClass and belongs in the design rather +than in a later change. Backups are encrypted by default. Kubernetes secrets are encrypted in +etcd when the API server runs with `--encryption-provider-config`, which comes from the Talos +machine configuration rather than from Cozystack, so verify it on your own cluster — and +secrets hold credentials, not usually the personal data your records of processing describe. + +### Does running Cozystack ourselves introduce a processor? + +No. Running open-source software on your own hardware adds no third party to the processing: +there is no service, no account and no data leaving your infrastructure, so there is nobody to +appoint under Article 28. Your own role is unchanged — you are the controller for personal +data whose purposes and means you determine, and a processor only where you host on behalf of +another controller. If you contract an integrator to operate the platform, that is a processor +or sub-processor relationship and needs an Article 28 agreement. ## Notes diff --git a/content/en/compliance/pci-dss.md b/content/en/compliance/pci-dss.md index ecf81a11..19052953 100644 --- a/content/en/compliance/pci-dss.md +++ b/content/en/compliance/pci-dss.md @@ -7,15 +7,17 @@ type: "page" weight: 10 --- -**Cozystack is not "PCI DSS certified" — no infrastructure platform can be — but it provides -most of the technical controls a PCI DSS 4.0.1 assessment depends on, and several of them are -active on a fresh install.** Cozystack is an open-source cloud platform built on Kubernetes, -KubeVirt and Talos Linux that runs on your own bare metal. Tenant network isolation, -privilege restrictions on workloads, automatic TLS for published services and encrypted -backups need no configuration. Single sign-on, volume encryption, restricted egress, encrypted -east-west traffic and longer audit retention are shipped but not switched on, because most -clusters do not need them: each is a configuration option, not a development project. This -page says which is which, requirement by requirement. +**Cozystack provides most of the technical controls a PCI DSS 4.0.1 assessment depends on, +and several of them are active on a fresh install.** It is an open-source cloud platform built +on Kubernetes, KubeVirt and Talos Linux that runs on your own bare metal. Tenant network +isolation, privilege restrictions on workloads, automatic TLS for published services and +encrypted backups need no configuration at all. + +Others are shipped but not switched on, because most clusters do not need them: single +sign-on, volume encryption, restricted egress, encrypted east-west traffic, longer audit +retention. Each is a configuration option rather than a development project, and this page +says which is which, requirement by requirement — along with the parts an assessment leaves +to you, so none of them surprise you late. *Will this pass our audit?* The question comes up in the first meeting, every time a cardholder data environment (CDE) moves to a new platform. No platform passes an audit.