Hetzner Cloud Security: Securing Projects, Firewalls, API Tokens and Backups

In Hetzner Cloud, one Read & Write API token or one S3 key pair can rebuild, delete or read every server, backup and bucket in a project, and those credentials usually sit in Terraform variables, CI secrets and laptop config files. Hetzner keeps its access model simple: four project roles, two token permissions and object storage keys that reach every bucket by default, so the customer sets the boundaries. This guide covers project identity and access, the Owner and Admin roles, API tokens and S3 credentials as non-human identities, logging, and a hardening baseline for servers, Cloud Firewalls, networks and backups. It is written for engineers and security leads who run production on Hetzner Cloud, often without a dedicated cloud security team.

This is an independent guide from NHI Mgmt Group, based on Hetzner's public documentation as of November 2026. It is not sponsored or reviewed by Hetzner. Product features change, so confirm settings against Hetzner's current documentation.

Key takeaways

• The project is the security boundary. Roles, API tokens and S3 credentials are all scoped to a project, so separate production, staging and shared services into different projects.
• Read & Write tokens are all-powerful within their project. There are only two token permissions, Read and Read & Write, so the token's project is your only way to narrow its reach.
• S3 keys reach every bucket by default. Hetzner states that every key has read and write permissions for every existing and new bucket in the same project; use bucket policies or separate projects to restrict them.
• Pair Cloud Firewalls with a host firewall. Cloud Firewalls are stateful and free and cover public traffic; private networks, the metadata server and Load Balancers are outside their scope, so keep a host firewall as well.
• Backups live in the same blast radius. Daily backups keep seven slots and snapshots stay until deleted, but anyone with a Read & Write token or the Member role can delete them; keep an independent copy outside the project.

How identity and access work in Hetzner Cloud

Hetzner Cloud groups servers, Volumes, Networks, Firewalls, Load Balancers, Primary IPs, images and Object Storage buckets into projects. People reach a project through a Hetzner account and the Hetzner Console; automation reaches it through the Cloud API at api.hetzner.cloud with a bearer token, or through the S3 endpoint with an access key and secret key. Access is set without a separate policy language: what a person can do is set by their project role, and what a token can do is set by its project and its permission.

• Turn on two-factor authentication for every account: in Hetzner Accounts, go to Settings, Two-factor authentication, Enable 2-FA. Hetzner allows several methods to be active at once and names YubiKey OTP as one option. Both light and full accounts can enable it.
• Store the recovery key like a break-glass secret: it is shown once during setup. If it is lost, Hetzner replaces it only after a manual review, and the replacement arrives by regular mail, which can leave an owner locked out for days.
• Use separate projects as blast-radius walls: because tokens and S3 keys cannot be narrowed below a project, a common pattern is one project per environment and per sensitive workload, with backups or archive buckets in a further project that day-to-day automation cannot reach.

Hetzner Cloud does not offer federation from your own identity provider in the documentation reviewed, so joiner, mover and leaver control is manual: invitations and removals happen in each project's Security, Members page. For the wider model, see the Cloud Security Guide.

Admin roles and privileged access

Each project has four roles. The differences matter more than the names suggest, because the Admin role controls credentials and the Member role can destroy data.

• Keep Admin small: an Admin can create a Read & Write token that survives their own removal from the project. When an Admin leaves, review and rotate every token and S3 key created in that project, not only the person's membership.
• Protect the Owner account: only the owner of a source project can move resources out of it. Use a shared company owner account held in a password manager or vault with 2FA, and record who can reach it.
• Treat the Console root password and rescue mode as privileged: enabling rescue displays a root password in the Console when no SSH key is selected, and rescue stays active until the next restart. Select an SSH key whenever you enable rescue, and treat any rescue activation you did not plan as an incident signal.
• Review membership quarterly: invitees can be external people. Export the member list for each project and confirm each person, role and 2FA status.

For a general approach to privileged roles in small teams, see the Privileged Access Management Guide.

Integrations, API tokens and service accounts

Hetzner has no service account object. Automation identity means API tokens and S3 credentials, both of which are long-lived secrets that work from anywhere on the internet once leaked.

Cloud API tokens

• Know the two permissions: Read allows only GET requests; Read & Write allows GET, DELETE, PUT and POST. A monitoring or inventory tool needs only Read. Terraform, the hcloud CLI used for deployments, the Kubernetes cloud controller manager and CSI driver normally need Read & Write.
• Create one token per integration: the token description is the only metadata you get, so put the integration, owner and creation date in it (for example terraform-prod | owner: platform | 2026-11). One token per integration means one token to revoke on a leak.
• Capture it once, into a vault: the token is shown only once. Put it directly into your secrets manager or CI secret store; never into a repository, a Terraform .tfvars file that is committed, or cloud-init user data.
• Rotate on a schedule: the token documentation does not describe an expiry setting, so rotation is your process. Create the new token, update the consumer, confirm it works, then delete the old one. Ninety days is a reasonable starting interval for Read & Write tokens.
• Watch local CLI configuration: the hcloud CLI saves contexts in ~/.config/hcloud/cli.toml by default, and hcloud context create --token-from-env reads the token from HCLOUD_TOKEN. Treat that file and any shell history or environment dumps as secrets on developer laptops and CI runners.

S3 credentials for Object Storage

• Default reach is the whole project: Hetzner's FAQ states that every key has read and write permissions for every existing and new bucket within the same project. A backup tool's key can therefore read the application's customer uploads.
• Restrict with bucket policies: Hetzner documents two patterns. In one project, a Deny statement with NotPrincipal blocks every key except those listed. Across projects, an Allow statement with Principal grants named keys from another project, identified as p<project_id>:<access_key>. Replace s3:* with the specific actions needed.
• Know the policy quirks: the NotAction element is not supported even though policies that contain it are accepted without error, so test every policy with a denied request. A NotPrincipal deny can also stop the Console from listing the bucket.
• Separate backup buckets: keep backup or archive buckets in a project whose keys only the backup system holds.

Leaked hosting tokens are typically abused for cryptomining (ATT&CK T1496.001 Compute Hijacking) or for destroying servers and backups (T1485 Data Destruction, T1490 Inhibit System Recovery). Scan repositories and CI logs for tokens with a secret scanner; see the API Key Management Guide, the Git Secret Scanning Guide and the Terraform and IaC Pipeline Credential Security Guide.

Logging and detection

Hetzner Cloud's logging is thin compared with hyperscaler audit trails. The documentation reviewed does not describe a Console audit log with user attribution or an export to a SIEM. What exists is the Cloud API's Actions resource: every asynchronous operation (server create, rebuild, delete, power, attach firewall and so on) is recorded as an Action with a command and the resources it touched. Combine that with host and network telemetry you collect yourself.

• Build a lightweight audit trail: run a small job with a Read token per project that lists Actions and resources on a schedule and writes them to your log platform. Alert on destructive commands outside change windows.
• Ship host logs off the server: a compromised server can wipe its own logs, and a deleted server takes them with it.

Metrics that show it is working

• Token hygiene: Read & Write tokens per project, and tokens older than 90 days.
• Admin footprint: Owner and Admin role holders per project, and the share with 2FA enabled (target: 100 percent).
• Firewall coverage: servers with a public IP that have no Cloud Firewall attached (target: zero).
• Protection coverage: production servers with delete and rebuild protection enabled.
• Recovery evidence: days since the last successful restore test from an off-project copy.

Hardening baseline

Phased rollout

1. Inventory: list projects, members and roles, API tokens, S3 credentials, servers with public IPs and servers without a firewall.
2. Accounts first: enforce 2FA, move the Owner role to a company account and cut Admin down to named platform owners.
3. Credentials: replace shared tokens with one token per integration, move every token and S3 secret into a vault, delete unknown tokens, and add bucket policies.
4. Network: attach a Cloud Firewall by label to all servers, then verify the target list, because label-based application can silently miss servers without a public IP or beyond limits. Remove public IPs from internal servers.
5. Resilience: enable backups and protection on production, then build the off-project copy and run a restore test.
6. Detection: deploy the Actions polling job and host log shipping.

Testing and rollback: firewall rule changes apply only to new connections, so an existing SSH session can stay open while you test a new rule set. Keep that session and the Console's web console as a fallback before tightening SSH rules. When you rotate tokens, keep the old token until the consumer is confirmed working, then delete it. Test bucket policies with a key that should be denied before relying on them.

Small versus large teams: a two-person team can work with one production project, a separate backup project and per-integration tokens. Larger organisations should add per-team projects, manage everything through Terraform from a pipeline that holds the only Read & Write token, and keep human Member roles for break-fix only.

Common misconfigurations

• One Read & Write token shared by everything: Terraform, CI, the Kubernetes controller and a developer laptop all use the same token, so a leak from any of them means rotating all of them, and nobody knows which consumer leaked it.
• Tokens committed with infrastructure code: tokens in .tfvars files, Helm values or cloud-init scripts are found by automated scanners within hours of a public push. See the Developer Secret Scanning Triage.
• Assuming the Cloud Firewall protects the private Network: a compromised web server can reach database ports on the private Network because that traffic is not filtered by Cloud Firewalls.
• Firewall by label with no verification: a new server created without the expected label, or a server beyond the limits, starts with open inbound ports such as SSH exposed to brute force.
• Backups and production in one project: an attacker with a Read & Write token deletes servers, snapshots and backup images in the same session, a pattern also seen in cloud ransomware. See the Backup Security and Immutable Backup Guide.
• S3 keys never restricted: a key given to a log shipper can read and delete every bucket in the project.

Framework mapping

Practitioner checklist

• Enable 2FA on every Hetzner account and store owner recovery keys in a vault.
• Split production, staging and backups into separate projects.
• Limit Admin to two or three named owners and review members and roles quarterly.
• Issue one described token per integration, Read wherever possible, stored only in a secrets manager.
• Rotate Read & Write tokens and S3 keys on a schedule and after any Admin leaves.
• Restrict S3 keys with bucket policies and test them with a denied request.
• Attach a Cloud Firewall to every public server, verify label coverage, and keep a host firewall for private traffic.
• Create internal servers without public IPs and use SSH keys only.
• Enable delete and rebuild protection and daily backups on production, plus an off-project copy with restore tests.
• Poll API Actions into your log platform and alert on destructive operations.

Standards and references

• Hetzner Docs: Generating an API token
• Hetzner Docs: Hetzner Cloud FAQ (projects, members and roles)
• Hetzner Docs: Cloud Firewalls FAQ
• Hetzner Docs: Backups and Snapshots
• Hetzner Docs: Object Storage S3 credentials FAQ
• Hetzner Docs: Two-factor authentication
• Hetzner: hcloud CLI documentation
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Cloud Security Guide · API Key Management Guide · SSH Key Management Guide · Terraform and IaC Pipeline Credential Security Guide · Backup Security and Immutable Backup Guide