Meet compliance requirements

Compliance on Syself Autopilot is split across layers: the infrastructure Hetzner operates, the security controls Syself builds into the platform, and the workload environment you own. Syself ships most security controls by default and produces the audit evidence they generate. A smaller set of controls is yours to configure and operate. This page lays out the shared-responsibility model, the control-family mapping to the frameworks auditors ask about, and the checklist you own.

Who certifies what#

		Infrastructure: Hetzner (certified)
  ISO/IEC 27001:2022 · BSI C5 Type 2 · PCI DSS 4.0 · KRITIS / §8a BSIG
 
Platform: Syself (enablement)
  technical controls + audit evidence
  automation with scoped access, no customer data
 
Your environment (you certify this)
  your workloads + your cluster, built on the two layers above
	

Hetzner certifies the infrastructure. The physical data centers and cloud are independently certified: ISO/IEC 27001:2022, BSI C5 Type 2, and German KRITIS / §8a BSIG critical-infrastructure operation. These certifications cover the layer beneath your servers.

Syself provides the technical controls. Syself builds, provisions, and reconciles the infrastructure. Its automation has scoped access to the cluster for provisioning and management; it does not touch or process customer data. The people on the Syself team have no standing access to the cluster. Syself supplies the controls and audit evidence described on this page. Syself is pursuing ISO/IEC 27001 certification; it does not hold it today.

You certify your own environment. Your servers run in your own Hetzner account. Syself sits outside your data-processing scope, which keeps your certification surface clean. In many cases, combining Hetzner's certified infrastructure with Syself's technical controls is enough for you to certify your own environment.

What makes compliance easier#

Most of a compliance audit is about proving what is running, who can change it, and how you know. Syself's architecture produces those answers as a side effect of how it works:

• Provable state. Nodes are immutable and dm-verity-verified (dm-verity is a Linux kernel feature that checks every disk block against a hash tree on every read). A node modified in place fails the kernel's block check on the next read of the changed block, and a re-sealed layer no longer matches the root hash recorded for the node. You can prove exactly what is running, and that it was reviewed. See Verify node integrity .
• Provable change control. Your cluster is declared like a workload. Every change is a reviewed Git commit and a Kubernetes audit record. Change management comes from the model, not from extra process.
• Provable provenance. Every component in the OS image is pinned to a content hash at its source, and the build fetches each source fail-closed on that hash, so a swapped source stops the build instead of reaching a node. The same content-hash pinning is the authenticity basis of the keyless OS seal. Every release is reproducible and ships an SBOM (software bill of materials: the list of every component and version in the image) plus OpenVEX advisories (machine-readable statements of which vulnerabilities affect your exact image version). The full pin schema, the SBOM, the advisory, and the CVE feed are in Security evidence a release produces ; how the image is built so a tampered source cannot reach a node is in Supply-chain security .

The shared-responsibility model#

The concept behind this split is What you own, what Syself manages . This page works it through for compliance: what ships on by default, what is yours to configure, and how each side maps to the frameworks.

Syself ships and operates, on by default:

• Immutable dm-verity OS with reproducible builds
• Node auditd (the Linux audit daemon) and Kubernetes API audit policy
• Mutual TLS (mTLS) on etcd, kubelet, and the node tunnel. With mTLS, both sides verify each other's identity.
• TLS 1.2 as the minimum version, using forward-secret ciphers. Forward secrecy means a stolen key cannot decrypt past traffic.
• CIS-hardened control-plane flags and RBAC with NodeRestriction
• Default-deny host firewall and webhook-guard guardrails
• Automatic self-healing, tamper-evidence monitoring, and automatic certificate rotation

You configure and operate:

• Etcd encryption at rest (opt-in): see Encrypt etcd .
• OIDC and least-privilege RBAC: see Manage access and tenancy .
• SSH lockdown and break-glass key custody: see Restrict SSH access .
• Log shipping to a SIEM and a WORM (write-once-read-many) store, storage that cannot be altered or deleted once written: see Retrieve audit logs .
• PodDisruptionBudgets and NetworkPolicies for your workloads.

Control-family mapping#

What Syself ships by default, organized by the control families auditors ask about.

Framework alignment#

These are control mappings, not Syself certifications. Use them to point your auditor at concrete technical controls when you certify your own environment.

CIS Kubernetes Benchmark. This is your strongest single piece of hardening evidence. Control-plane and kubelet flags are hardened to CIS and annotated with specific CIS control IDs, so your auditor can trace each flag directly.

BSI C5:2020. The node auditd ruleset covers C5's Logging and Monitoring controls. The integrity, firewall, and access layers align with C5's other domains. The underlying Hetzner cloud is BSI C5 Type 2-certified. See Auditd rules .

NIST, PCI-DSS, and SOC 2. The Kubernetes audit policy is graded by sensitivity, which is the control the table above maps to NIST AU-2/AU-3, PCI-DSS 10, and SOC 2 CC6.3. PCI-DSS 10.5.1 asks for 12 months of history, more than local retention holds, so that one depends on shipping the logs to WORM storage.

ISO 27001. The controls above map onto ISO 27001 Annex A families: access control, cryptography, logging, change management, and vulnerability management. Hetzner's infrastructure is ISO/IEC 27001:2022-certified. Syself is pursuing its own ISO 27001 certification.

Data residency and GDPR#

You own the servers, in your own Hetzner account. Your workload clusters run there, not inside a Syself multi-tenant service. Syself manages the lifecycle; it is not the operator of record for your servers. Your application data stays in your cluster, in your account.

Hetzner is a German provider. Clusters can run entirely within the EU. This is relevant to GDPR (General Data Protection Regulation) and data-residency requirements: you are the data controller of your own infrastructure.

Cluster isolation#

Syself does not run a shared, multi-tenant control plane. Every workload cluster gets its own dedicated API server, etcd, and certificate authorities. One cluster's secrets are not visible to another. A problem in one cluster stays in that cluster, which keeps your audit scope clean.

Inside a cluster, you can raise workload isolation from a shared kernel up to a per-pod VM with the secure RuntimeClass (Kata Containers on bare-metal nodes with hardware virtualization). The runtime ladder, what each level covers, and why confidential computing is not available on Hetzner are in Workload runtimes and isolation .

Your compliance checklist#

Work through these. Each is a control an auditor will expect you to own.

1. Turn on encryption at rest#

Kubernetes stores Secrets unencrypted in etcd by default. Enable etcd encryption, then re-encrypt existing secrets.

You author the key material. You write the EncryptionConfiguration (the API server config listing the encryption providers and keys), generate the key yourself, and supply the config as a Kubernetes Secret in the management cluster. The platform writes it to each control plane node and mounts it read-only into the API server. It is opt-in and off by default. One caveat for your auditor: that Secret lives in the Syself-operated management cluster, so the key is not held by you alone. There is no external KMS integration today.

Rotation uses a multi-key list: the first key encrypts new writes, and every listed key can still decrypt. The API server reloads its encryption config automatically when the file on disk changes (--encryption-provider-config-automatic-reload=true), but nodes write that file from the Secret only at boot, so editing the Secret changes nothing until the control plane rolls. So the rotation sequence is: add the new key, roll the control plane, re-encrypt all Secrets, drop the old key, roll again.

Know what this control covers. Encryption at rest protects the raw etcd data: a copied disk, a leaked backup, a direct database read. It does not protect the API path. The API server decrypts on read, so any request RBAC authorizes returns plaintext. Pair it with least-privilege RBAC (step 2).

• Do it: Encrypt etcd .
• Note: enabling encryption triggers a control-plane rollout. Existing secrets remain unencrypted until re-written: kubectl get secrets -A -o json | kubectl replace -f -.
• Evidence: the EncryptionConfiguration in place, and the re-encryption step recorded.

2. Wire authentication and least-privilege access#

• Connect your identity provider (OIDC) so users log in with short-lived tokens. See Configure OIDC .
• Bind RBAC to groups, not individuals. Grant the least privilege that works.
• Never grant tenants system:masters or kubeadm:cluster-admins. Those groups bypass the webhook-guard guardrails.
• Evidence: your OIDC config, your ClusterRoleBindings, and a documented access review.

3. Lock down break-glass access#

Emergency SSH runs on port 100. It is key-only, but open to the internet by default.

• Restrict it to a bastion host. See Restrict SSH access .
• Hold break-glass SSH keys in a secrets manager or HSM (hardware security module, hardware that stores keys in tamper-resistant memory). Restrict who can use them and rotate them if custody is ever in doubt.
• Evidence: the SSH lockdown policy and your key-custody procedure. Every break-glass session is already audit-recorded on the node.

4. Confirm the API server is locked down#

The API server lockdown is on by default. The restrictWorldIngress toggle controls it, and it renders a CiliumClusterwideNetworkPolicy named control-plane-apiserver-lockdown.

• Verify per cluster that the control-plane-apiserver-lockdown policy is present and denying port 6443 from 0.0.0.0/0 except your load balancer.
• Evidence: the rendered lockdown policy on each cluster.

5. Ship logs off-node and retain them#

The node keeps auditd and Kubernetes API audit logs locally with a size cap. There is no bundled log shipper.

• Ship node auditd and the kube-apiserver audit log to your SIEM.
• Retain logs in a WORM store for the period your compliance framework requires.
• Evidence: the shipping pipeline and the retention policy. See Retrieve audit logs .

6. Design your workloads for the controls you claim#

• Add PodDisruptionBudgets to every important workload so availability controls hold during a rollout.
• Add NetworkPolicies for tenant workloads. The platform secures the host; you segment the workloads.
• Run multiple replicas with topology spread for resilience claims.

7. Keep current: your vulnerability-management timeline#

Because nodes are immutable, patching a CVE means rolling to a newer tested release, not editing a node. Syself measures each patch SLA from the CVE's publication date and meets the deadline by shipping a patched release; your part is adopting it, so your upgrade cadence is the evidence. The SLA ladder and the CVE feed that tracks each fix against its deadline are in Security evidence a release produces .

• Do it: upgrade your cluster. See Upgrade within a version .
• Evidence: your upgrade cadence and the version each cluster runs.

8. Collect your integrity evidence#

• Verify each node's verity root hash against the published image hash. See Verify node integrity .
• Keep the SBOM for the release you run and the advisories that clear or flag its CVEs.
• Evidence: an attestation record per node, plus the release's SBOM and VEX.

Limits#

This is what is not in place:

• Self-declared alignment, not certification. The BSI C5, CIS, NIST, PCI-DSS, SOC 2, and ISO 27001 references are control mappings and hardening citations, not audited attestations by those bodies.
• No hardware root of trust. The node seal is software-rooted: keyless dm-verity with a root hash anyone can recompute from the released image. There is no TPM-backed measured boot, no remote attestation, and no Secure Boot, and none of these is planned.
• No bundled log shipping or WORM store. auditd and API audit logs are retained locally. Shipping them to a SIEM or WORM store is your responsibility.
• Etcd encryption is opt-in. You author the key, but the config Secret lives in the Syself-operated management cluster, and there is no external KMS integration. Key rotation needs a control-plane roll. Encryption does not retroactively cover secrets written before it was enabled, and it is not access control: an RBAC-authorized API read returns plaintext.
• Tamper-evidence is detection, not prevention. /var is tamper-evident: the daemon raises a condition when a file changes. A root-level attacker with the daemon stopped can still alter local files. Evidence that has already left the node is what survives.
• SSH is on by default (you can opt out). It stays on because it is the only out-of-band access path for support. Locking it down and holding the keys are your responsibility, and blocking SSH limits out-of-band support.