What You Own, What Syself Manages

On most managed Kubernetes platforms it is unclear who is responsible for what. You cannot tell which controls the provider runs, which ones fall to you, or what evidence you get when an auditor asks. Syself Autopilot splits the work across three layers. Hetzner runs the hardware. Syself runs the platform and ships the compliance evidence. You own your workloads and your audit.

The middle layer is where people get confused. Syself gives you technical controls plus the machine-readable evidence those controls produce, per release and per running cluster. It holds no certificate of its own today. The evidence is not an attestation you can hand to an auditor in place of your own audit. You still run that audit, and the platform gives you most of what you need for it.

Renting a certified commercial kitchen works the same way. The building has its own inspection certificate. The operator maintains the equipment and hands you the maintenance records. The health inspector still inspects your restaurant, not the building. The records speed up your inspection, but you still have to pass it.

flowchart TD
  H["Hetzner runs the infrastructure<br/>data centers and cloud, independently certified:<br/>ISO/IEC 27001:2022, BSI C5 Type 2, PCI DSS 4.0"]
  S["Syself runs the platform, on by default<br/>immutable OS, encrypted internal traffic,<br/>default-deny firewall, CIS hardening, RBAC,<br/>audit logging, cert rotation<br/>+ per-release SBOM, security report, CVE feed"]
  Y["You own and configure<br/>your workloads and data, ingress and exposure,<br/>etcd encryption, OIDC and RBAC, SSH lockdown,<br/>log shipping, NetworkPolicies, PodDisruptionBudgets"]
  A["Your audit"]
  H -->|"certified foundation"| S
  S -->|"the platform you build on"| Y
  H -.->|"attestations you can cite"| A
  S -.->|"controls + evidence, not a certificate"| A
  Y -.->|"you operate these and run your own audit"| A

Hetzner, Syself, and you#

Each layer answers a different question from your auditor, and backs it with a different kind of proof:

The middle layer sets your audit scope. Syself is not the operator of record for your servers. They run in your own Hetzner account, and your application data stays in your cluster, so Syself is outside your data-processing scope.

The platform controls line up with the control families in these common frameworks:

Each framework name is a control mapping. Syself holds no BSI C5, SOC 2, or ISO/IEC 27001 certificate today. It is working toward ISO/IEC 27001. If you read those names as certificates, you will think you have more proof than you do, and you will not prepare your own audit. The only audited certificates in the stack are Hetzner's, one layer down. The full mapping, framework by framework and control by control, is in Meet compliance requirements .

Controls on by default#

These controls ship with every cluster, and you configure nothing. Most of them cannot drift, because they are part of the immutable OS image or the control-plane flags. A node that needs to change gets replaced, not patched.

Controls you configure#

Every item here depends on a decision only you can make: your identity provider, who holds your keys, how long you keep logs. Syself cannot ship any of it as a default without making those decisions for you, so it ships none of them.

Prepare your audit against this short list. Together, Hetzner's certified infrastructure and the platform controls are often enough to certify your own environment.

What the automation can and cannot reach#

The automation creates and replaces nodes, and it keeps the running machines matched to the cluster configuration you declared. It does nothing else. It runs in the Syself-operated management cluster, with a small installer that runs on a machine while it is being set up. To reinstall a bare-metal server it logs in with its own dedicated key, not a shared platform password.

When the automation needs to reach your API server, it uses short-lived tickets. KubeGate, the gateway Syself puts in front of your API server, checks each ticket. A ticket lasts only a couple of hours, then expires.

In normal operation it does not run code inside your workloads, read or process your data, or read your application Secrets. Your application traffic and storage never pass through the management plane. Syself staff have no standing access to your cluster.

Syself's access is limited, but it is not zero, and you need to know why before you put this claim in an audit. The management cluster sets up your control plane, so it holds what that job needs: startup data, machine credentials, and, if you turn on etcd encryption, the Secret with your encryption settings. Someone with access to the management cluster could reach those credentials. The parts you can verify yourself are in What Syself can and cannot do in your cluster .

The evidence you get#

Every release ships machine-readable evidence: an SBOM, a stack security report, and a CVE feed. All come from the same component pins and CVE decisions that build the image. Nothing is written by hand, so the evidence and the image cannot drift apart.

The SBOM (software bill of materials) lists every component and version in the image, in the standard SPDX format. Each entry names the component, where it was downloaded, its checksum, and its license, plus the identifiers vulnerability databases use to look it up.

The SBOM also includes VEX verdicts. A VEX verdict says, in machine-readable form, whether a known vulnerability affects this image. A scanner that reads them follows that decision instead of re-flagging vulnerabilities already cleared. The advisory with the verdicts ships in the OpenVEX format, separate from the SBOM: you publish the bill of materials once and update the advisory with each scan. That split is what the EU Cyber Resilience Act asks for.

The SBOM is reproducible too. The same source produces the same document, so you can compare two copies and confirm they match.

The build behind it fails closed. Before the build, every source is locked to a specific content hash, plus its version, download location, license, and end-of-life date. If the content does not match its recorded hash, the build stops instead of fetching something else. That same hash locking is what makes the OS image provably authentic.

The stack security report extends the scan beyond the OS image. The cluster components deploy their own container images: the CNI, the cloud controller, the metrics stack. Those images have their own CVEs. The report combines the node-image scan and the chart-image scan into one document per release: each CVE with its component, its installed and fixed versions, its VEX verdict where one was decided, and its SLA status.

The CVE feed refreshes on a schedule, because vulnerability data goes stale within days. A scan runs on that schedule and updates the feed.

The feed holds the current report, the change since the last scan, and a dated copy of every scan.

The current report lists every open vulnerability, tagged to the node image or a cluster component image. For each one it records:

• its severity score
• an estimate of how likely it is to be exploited
• whether it is known to be exploited in the wild
• its VEX verdict
• its status against its patch deadline

The change record shows what was added, fixed, or escalated since the last scan, so a reviewer sees what changed instead of comparing full reports. The dated copies let you show an auditor what was known on a given date and how long each finding stayed open. The feed also records how it was built: when the scan ran, which vulnerability sources it queried, and which deadline policy it applied.

Every open CVE has a patch deadline measured from its publication date, tightened for anything network-facing or actively exploited and relaxed for build-time-only components; the feed marks each one on track, due soon, or overdue. Because nodes are immutable, meeting a deadline means Syself ships a patched release, and your part is adopting it, so how often you upgrade is the evidence. Security evidence per release has the full patch-SLA ladder and how each deadline is set; supply-chain security covers the hash-locked build behind the evidence.

Everything above is per-release evidence. A running cluster produces the second kind, its own logs: node security events, the Kubernetes API audit log, and KubeGate's access decisions, each kept locally under hard caps and overwritten past them unless you ship the stream off-node. Retrieve audit logs has the caps and the shipping path, and the observability model covers what every cluster ships.

Limits of the platform side#

No hardware root of trust. The node integrity check runs in software (dm-verity with a root hash you can recompute from the released image), not in a hardware chip: no verified boot in firmware, no remote attestation, and the trust boundary is the small writable boot partition that tells the machine how to start. Syself Linux covers the model and its limits.

No bundled log shipping or WORM store (write-once-read-many: storage nothing can alter or delete once written). All audit evidence stays on the node under the caps above. Only what already left the node survives a root-level attacker, so shipping the logs off-node is your job.

etcd encryption is opt-in. A few limits come with it:

• You author the key. The config Secret sits in the Syself-operated management cluster, with no external KMS in the path.
• It protects a copied disk or a leaked backup. It does not protect the live API path: the API server decrypts on read, so any request RBAC authorizes returns plaintext.
• Rotating the key needs a control-plane roll. Nodes read the config from the Secret only at boot, so editing the Secret alone changes nothing.
• It is not retroactive. Secrets written before you turned it on stay plaintext until you re-write them.

Emergency SSH is open to the internet by default. It is key-only, and every session is recorded, but anyone can reach it until you restrict it. It stays open because it is support's only fallback route when the normal path is down. Block it and support loses that route, so restricting it and holding the keys is your call.

The two control tables, Controls on by default and Controls you configure, are exhaustive. They are built into images and flags, so the boundary is exact enough to scope an audit, and a control not listed there is not part of the platform.

Your compliance work starts with the controls that are yours to configure: your identity provider, key custody, log retention, and workload exposure. Meet compliance requirements turns the framework mapping into a step-by-step checklist for the parts you configure, and What Syself can and cannot do in your cluster is what you cite for the access boundary. For the same posture written for a buyer rather than an auditor, Compliance on Syself sums up what the platform brings to your certification.