Skip to content
My account

Who is allowed to do what,
and who holds the key

Access control, key and secret management are not add-on products, but the foundation on which everything else rests. This page describes how finely rights can be tailored, where a key is physically located and what we can still do technically if you revoke it from us.
Configure systemRoles and policies

This page describes the services. The evidence for this — ISO 27001, BSI C5 Type 2, EN 50600, reporting deadlines and data processing agreement — can be found under Security and compliance. Where both belong together, the sections refer to each other.

Services at a glance
Access control (IAM)
included in the account
Key, software-protected
€0.90$1.04 / month
Key on HSM
€2.40$2.78 / month
Secret in Secret Manager
€0.40$0.46 / month
Cloud HSM, own partition
€439.00$509.24 / month
Dedicated HSM
in preparation
Key and secret prices apply per unit and month, billed pro rata by the hour. Amounts are net.
Actions in the catalogue
412
individually addressable in policies
Audit trail
90 days
cannot be disabled, cannot be shortened
Rotation
90 days
Default for new keys
HSM locations
fra1 · muc1
partitions synchronously mirrored

Three questions that are not the same

“Security and identity” is a collective term in common parlance for three questions that are answered separately. This page keeps them apart: first who someone is, then what they are allowed to do, then what is used for encryption.

  1. 01

    Who are you?

    Authentication

    The question of identity. It is answered during login — by a password with a second factor, by a service account for machines, or via federation: logging into your own directory, the result of which we accept.

    If you cannot identify yourself, you do not get a session. If no mapping rule applies in the federation, no session is created either — there is no fallback role.

    Federation, sessions, service accounts

  2. 02

    What are you allowed to do?

    Authorisation

    The question of permissions — independent of the first. A valid login in itself allows nothing at all.

    IAM, the account's access control, is responsible: Identity and Access Management, i.e. roles, policies, and conditions. It addresses 412 actions individually. The rule behind it is least privilege — as few permissions as possible, and none in reserve.

    Roles, policies, audit trail

  3. 03

    What is used for encryption?

    Key management

    The third question concerns neither people nor permissions, but material. KMS — Key Management Service — generates keys, stores them, and uses them, but does not hand them out.

    A secret, on the other hand, is access data that an application must read itself: a database password, a certificate. Both are rotated, i.e. replaced on schedule; the default is 90 days. An HSM — Hardware Security Module — is the device in which a key is created and which it never leaves.

    KeysSecretsHardware modules

The three questions interlock, but remain separate: the Secret Manager gets its permissions from the same access control as everything else, and a key is only used if the requesting identity is authorised to do so. There is no second permission management in ENTRONYX CLOUD that has to be maintained separately.

Permissions you can justify individually

Roles, policies and service accounts belong to every account and cost nothing. There is no security tier you have to add on — there is only the question of how fine-grained you want to be.

Predefined roles with their limits. Every role explicitly states what it is not allowed to do.
RoleCanCannot
Account ownerEverything, including billing, account closure and role assignmentBe revoked — the role can only be transferred, not deleted
AdministratorCreate, modify, delete resources of all projects; assign roles below their ownView billing data, close the account, modify the audit trail
OperatorOperate instances, volumes, clusters and networks in the assigned projectAssign roles, generate keys, create projects
ReaderView the state and configuration of all assigned resourcesAny write action, including starting a stopped instance
Security officerRead and export the audit trail, manage keys and secrets, terminate sessionsAccess the data protected by the keys
BillingView and modify invoices, consumption and payment methodsView or modify technical resources
Custom roleFreely chosen list of actions, limited to resources and conditionsContain more than the assigning role itself possesses

Four levels of granularity

A policy consists of effect, action, resource and optional condition. The further down this list you start, the less you have to explain at the next incident.

  1. 01Servicestorage:*

    Coarsest level. Useful for reader roles, unsuitable for anything with write access.

  2. 02Actionstorage:bucket:read

    A single operation. The catalogue lists 412 actions across all services.

  3. 03Resourceurn:entronyx:storage:fra1:buckets/rechnungen-2026

    Binds the action to a named object. Wildcards at the end are allowed.

  4. 04Conditionsource_network = 203.0.113.0/24 and mfa_age < 900

    Additional check at runtime: source network, age of two-factor authentication, time window, project identifier.

Login via your directory

  1. Step 1Create trust relationshipYou provide the metadata of your provider — for OIDC (OpenID Connect) via the discovery address, for SAML 2.0 via the metadata XML; both are the common standards for logging in via an external directory. One trust relationship per provider, multiple providers per account are permitted.
  2. Step 2Map attributes to rolesA mapping rule translates groups or claims from the token into ENTRONYX roles. If no rule matches, no session is created — there is no fallback role.
  3. Step 3LoginThe user logs in to your provider. We verify the signature, issuer, audience, and age of the token; expired or reused assertions are rejected.
  4. Step 4Session with expiryThe assertion creates a session with an 8-hour term, reducible to 15 minutes. Extension is only possible by logging in to the provider again, not by continued use.
  5. Step 5Provisioning via SCIMSCIM is the protocol with which a directory reports accounts to an external service. Whoever is created or deactivated on your end will also appear or disappear on ours — without anyone having to remember. Without SCIM, a departed account remains until you delete it.
  6. Step 6Entry in the audit trailEvery session is logged with the provider, mapping rule, assigned roles, and source address. The case “no rule matched” is also recorded there, along with the transmitted attributes.

What applies without configuration

  • Everything denied: A new account has exactly one authorised person — the account owner. Every additional person and every service account starts with no permissions. There is no role that is automatically included upon creation.
  • Denial beats permission: If multiple policies apply to the same request, the denial wins — regardless of the order and specificity of the rule.
  • No inheritance across project boundaries: Permissions in one project say nothing about another. Anyone who needs to work across projects needs a role per project or a role at the account level.
  • Two factors for write roles: Administrator, operator and security officer can only be assigned to people who have set up a second factor. TOTP (one-time codes from an authenticator app) and WebAuthn (security keys or device biometrics) are permitted; recovery codes are provided once during setup.
  • Service accounts without an expiry date do not exist: An access token lives for one hour, a key pair for a maximum of 90 days. From day 60, a warning appears in the account and in the API response as a header.
  • The audit trail cannot be disabled: Even the account owner cannot turn it off, shorten it, or delete entries. This is intentional and the condition for it to serve as evidence.

Default values of a new account

Service accounts

A service account belongs to a project, not a person. It can hold roles, but cannot assign roles, and it has no access to the web interface.

For systems within the platform, the better way is federation via the projected token of the cluster — a short-lived credential that Kubernetes issues to the pod itself. Then there is no permanent access data lying around for anyone to copy.

Token 1 hour · key pair maximum 90 days

Audit trail

Recorded decisions
Allowed and denied, both completely
Fields per entry
Time, identity, action, resource, result, source address, rule identifier
Retention in the account
90 days, cannot be shortened
Continuous export
To Object Storage or a syslog receiver
Immutability
Hourly checksum, linked in the chain with the previous hour
Delay until visibility
Under 30 seconds in normal operations

Beyond 90 days, you keep the entries yourself — in Object Storage with WORM lock, i.e. write once and read only thereafter, or via the tools under operations.

Cannot be disabled, not even by the account owner

A closed steel door with a card reader and printed ENTRONYX CLOUD wordmark, next to it a door leaf without a handle.
Symbol, not a diagram: a locked door explains access rights more precisely than any diagram. Whoever has the key gets in — and the entry is created anyway. Every decision is in the audit trail, the allowed as well as the denied, for 90 days and without the possibility to delete it.
Two closed steel doors with ENTRONYX CLOUD signs, warm light moving up and down above them.

A right is not a state, but a decision per request. ENTRONYX CLOUD logs every single one — including rejected ones, and those an administrator makes for themselves.

Every request individually

A steel key rack, the hooks individually labelled, two spaces empty.

Roles and rights are two separate things at ENTRONYX CLOUD: a role dictates what someone is responsible for, a policy dictates which of the 412 actions it includes. If multiple policies apply, the denial always wins — regardless of the order and precision of the rule.

Access control · audit trail 90 days, cannot be disabled

A key you can revoke

The service generates, stores and uses keys — it does not release them. The difference to a file containing a key is not the encryption, but the question of who monitors its use and who can terminate it.

Key types

Available key types with algorithms and typical use.
Key typeMethodUsageLength
SymmetricAES-256-GCMWrapping data keys, encrypting small payloads up to 8 KB256 bit
RSA signatureRSASSA-PSS, RSASSA-PKCS1-v1_5Code signing, issuing certificates, signing receipts3072 / 4096 bit
ECDSA signatureECDSA over P-256 and P-384Token and receipt signature when short signatures matter256 / 384 bit
EdDSA signatureEd25519Signature in package chains and artefact registries256 bit
Asymmetric decryptionRSA-OAEP with SHA-256Receiving data from systems without a shared secret3072 / 4096 bit
Message authenticationHMAC-SHA-256Signing webhooks and session tokens256 bit

What happens when writing an object

Your KMS key does not encrypt your data, but the key that encrypts your data. This is why a revocation takes effect immediately: without the opened envelope, the ciphertext — the encrypted data — is just noise.

  1. 1Request data keyThe storage service requests a fresh data key from the KMS and receives it twice: once in plaintext for memory, once wrapped with your KMS key.
  2. 2Encrypt dataThe payload is encrypted with the plaintext key. It is then removed from memory; it never reaches a storage medium.
  3. 3Write envelopeAlongside the ciphertext lies the wrapped data key and the identifier of the KMS key version used. Without these three parts, nothing can be unpacked.
  4. 4Return on readThe envelope goes to the KMS, which opens it — provided the requesting identity is authorised to do so. Every opening appears in the audit trail, with resource and result.

Prices

Billed by volume: per active key version and per operation.
ItemUnitPrice
Software-protectedPer active key version and month€0.90$1.04
KMS on HSMPer active key version and month€2.40$2.78
Cryptographic operationsPer 10,000 operations · first 20,000 per month free€0.0300$0.0348
Key import (BYOK)Per import of a self-generated key, regardless of key typefree
RotationAutomatic or manual, as often as requiredfree

All amounts net, plus 19% VAT. · Pro-rata hourly billing

Rotation

Rotation schedule
30, 90, 180 or 365 days — or manual
Default for new keys
90 days, identical to the platform's data keys
What rotates
A new version is created; the old one remains readable
Effect on existing data
None. Only newly written data is re-encrypted
Backlog visible
Proportion of objects on old version shown in the account
Disable old version
Explicit command, with 30-day grace period and revocation
Billing
Each active version counts individually

Default 90 days, as with the platform's data keys

Region binding

  • A key belongs to a region: It is generated there, used there and does not leave it. A volume in muc1 cannot use a key from hel1 — the request is rejected, not silently routed across the border.
  • Multi-region only as a named pair: For applications across two locations, there are key pairs fra1/muc1 with synchronous mirroring. Both halves are the same key; deleting one deletes both.
  • No silent fallback: If a key's region is unreachable, the dependent operations fail. We do not keep a secondary copy outside the booked region, not even as a temporary bridge.
  • Usage by storage services: Object Storage binds the key per bucket, Block Storage per volume, the managed databases per instance. The assignment can be changed afterwards; existing data remains on the old key until it is rewritten.

One key, one region — or a named pair

Credentials that do not end up in the repository

Database passwords, API keys and certificates are versioned in the service, encrypted with a KMS key from your account. The rights to them come from the same access control as everything else — there is no second rights management that you could forget.

Process of an automatic rotation

The tricky point of any rotation is the moment between the old and new value. We solve it by making the new value valid at the target system first and then switching it over — never the other way around.

  1. t + 0Generate new secretThe rotation schedule starts a function that generates new access data — for managed databases a second login account, otherwise a value according to your specification.
  2. t + 1Store in the target systemThe new access data is set before anything is switched over. If this step fails, the rotation aborts and the old value remains current.
  3. t + 2Reassign labelOnly now is “current” set to the new version. Applications that read between the steps receive a valid value — there is no window in which both values are wrong.
  4. t + 24 hDecommission old valueAfter a 24-hour grace period, the old access data is invalidated. The period covers instances that read the secret at startup and have not reloaded it since.

Connection to Kubernetes

A Kubernetes secret is base64-encoded, not encrypted. The driver bypasses this route entirely: the secret reaches the pod as a file and is never stored in etcd, the cluster's database.

  • Mount as file: The CSI driver — the interface through which Kubernetes mounts storage into a Pod — places the secret as a file in a volume of the Pod. No Kubernetes Secret is created, and thus no base64 value in etcd that anyone with read access to the namespace can see.
  • Identity instead of credentials: The Pod authenticates itself with the Projected Service Account Token issued by the cluster. There is no access key in the cluster that someone outside could use.
  • Updates at runtime: The driver checks for a new version every 120 seconds and rewrites the file. Whether the application rereads it is up to the application — we do not restart Pods.
  • Limit: Anyone with execution rights in the Pod can read the file. The driver protects against broad read access in the cluster, not against a compromised container.

The driver is activated with a switch when creating a cluster under Managed Kubernetes and requires no maintenance afterwards.

Features

Size per secret
Up to 64 KB, arbitrary binary data
Versions
Unlimited, with the labels “current” and “previous”
Fallback
Reassign label, without restarting the application
Encryption
With a KMS key of your account, optionally on HSM
Permissions
Via IAM per secret, no secondary permission management
Erasure
30 days grace period, during which the deletion command remains revocable
Retrieval in the audit trail
Who, when, which version, from which address

One secret, any number of versions

What the service does not do

It protects the value at rest and in transit, and it logs every retrieval. It does not protect against an authorised application passing the value on, writing it to a log or outputting it in an error message.

If you need to rule this out, encrypt within the application itself and only use the service for the key to it.

Limit, openly stated

Prices

Billing is per active secret and per retrieval.
ItemUnitPrice
Active secretPer secret and month, all versions count as one€0.40$0.46
RetrievalsPer 10,000 retrievals · first 10,000 per month free€0.0250$0.0290
Automatic rotationAs often as you like, including the rotation functionfree
CSI driver for KubernetesPer cluster, regardless of the number of podsfree

All amounts net, plus 19% VAT. · Pro-rata hourly billing

Three tiers, two available to order

An HSM is a device that generates and uses keys but does not release them — not even to its own operator. The difference between the tiers is not the protection level of the individual key, but the question of who manages the partition and who shares the device.

KMS on HSM

€2.40$2.78per key version and month

The entry point to hardware. You do not book device space, but a key that is generated in hardware and stays there. Operation is the same as with the software-protected key — same API, same permissions, same audit trail.

Usage
Shared partition, multiple accounts
Certification
FIPS 140-3 Level 3
Locations
fra1 and muc1, synchronously mirrored
Management
ENTRONYX manages the partition
View KMS prices

Cloud HSM

Own partition

€439.00$509.24per partition pair and month

A dedicated partition with its own login procedure. We do not know your partition login and cannot reset it. Access via PKCS#11, JCE and KMIP — even from systems outside our platform.

Usage
Own partition, exclusively your account
Certification
FIPS 140-3 Level 3
Locations
fra1 and muc1, synchronously mirrored
Management
You manage the partition, we manage the device
Request partition

Dedicated HSM

In preparation

No pricePrice will be published with availability

A device that no one but you occupies — including the decision on which firmware version runs on it. The service is in preparation. We do not give a date, do not accept pre-orders and do not include it as a commitment in quotes.

Usage
Entire device, physically used alone
Certification
FIPS 140-3 Level 3, approval pending
Locations
Location choice planned, not guaranteed
Management
You also approve the firmware

All amounts net, plus 19% VAT. · Cloud HSM with a minimum term of 3 months

What key sovereignty means in practice

“Only you have access” is a phrase that is worthless without details. The following table answers the seven questions where the two bookable tiers actually differ.

Seven questions on key sovereignty, answered for both bookable tiers.
QuestionKMS on HSMCloud HSM
Can ENTRONYX read the key?No — it does not leave the moduleNo — it does not leave the module
Can ENTRONYX use it?Only upon request by an authorised identityNo — not without your partition login
Who manages the partition?ENTRONYXYou, with a quorum of 3 out of 5 cards
Can ENTRONYX delete it?Yes, as part of operationsYes, by resetting the device — no one can read it in the process
What happens if the login is lost?Not possible, we hold themThe keys are lost, even to us
Access from outside the platform?Via the KMS APIVia the standard interfaces PKCS#11, JCE and KMIP
BackupAutomatically, mirrored to the second deviceEncrypted clone to a second partition, triggered by you
A hardware security module in the slot, front panel with seal and card slot, next to it a sealed cassette.
Safekeeping is in the device, not in a file: a key is created in the module and does not leave it. A management process on a Cloud HSM partition requires a quorum, i.e. a minimum number of present cards: 3 of the 5 issued. The module answers a signature within the same region in under 4 ms — the detour via the hardware costs waiting time, but not a noticeable one.
Certification
FIPS 140-3 L3
Customer partitions, new device generation
Quorum
3 of 5
Cards for management processes on the partition
Response time
under 4 ms
measured within the same region
Cloud HSM from
€439.00$509.24
per partition pair and month

Who sees the key, and who doesn't

Everything is encrypted with us, without you having to turn anything on. The interesting question is a different one: which mode are you working in, where is the key located, and what remains technically possible for us. The answer is in a table, not in a promise.

Five modes for data at rest — SSE stands for server-side encryption. The rows are ordered by decreasing access from our side.
ModeWhere the key is locatedWho can technically see the plaintext
SSE-S3 (default)Platform key, managed by usThe storage service — in memory, for the duration of the request
SSE-KMSYour KMS key, software-protected or on HSMThe same service, but only as long as your policy allows; revocation takes effect immediately
SSE-KMS with your own keyGenerated and imported by you (BYOK)As above. After revocation, the ciphertext is worthless even to us
SSE-CWith you — the key travels with each requestThe service for the duration of the request; it is never stored
Client-sideExclusively with youNo one but you. We only see ciphertext and object size

Why “end-to-end” needs a restriction here

Strictly speaking, end-to-end means: the plaintext is created on your device and never leaves it. Only client-side encryption achieves this — the last row of the table above.

In all other modes, one of our services encrypts. It inevitably needs the plaintext in memory for the duration of the request. This is not a backdoor, but it is also not the same as end-to-end, and we therefore do not call it that.

What you still gain in the server-side modes: revocation takes effect immediately and completely, every use is in the audit trail, and the key is never on the same storage medium as the data.

In transit

Public endpoints
TLS 1.3; TLS 1.2 only with AEAD suites that encrypt and simultaneously check integrity
Between our services
Mutual TLS authentication (mTLS) — both sides present a certificate, not just the server
Between the locations
Additionally MACsec, an encryption at the line level
To the HSM
PKCS#11 over TLS with mutual certificate
Within your vRack
Not encrypted — you are responsible for this

The last row is the most important: a private Layer 2 network is private, but not encrypted. If you transmit confidential data in the vRack — the private network between your servers — you encrypt it yourself; the separation by vRack does not replace transport encryption.

Bring your own keys

BYOK means “bring your own key”: you generate the key on your end, wrap it with a transport key that we issue for your account, and upload it. We only see the wrapped material.

An imported key can be revoked at any time, with or without a grace period. After revocation, the data protected with it is irretrievably lost — even for us. This is the purpose of the feature and not a malfunction.

BYOK · Import free of charge

And what about Bare Metal

On a dedicated server, you have full access to the storage media — and thus also the responsibility for their encryption. We provide TPM 2.0, the server's security chip, and recommend LUKS2, the Linux disk encryption — with a key that is not located on the same system.

This is exactly what the KMS key on this page is good for: unlocking at startup fetches the key via the API instead of storing it in the boot image (initrd).

There, the responsibility lies with you

Included, not an add-on

Basic protection runs permanently in every product and does not need to be turned on. The full description — mitigation process, filter levels, limits — is available on the network page.

Filter capacity
1.2 Tbit/s across three scrubbing centres
Basic protection
Included in every plan at no extra cost
Detection time
3 s median over the last 12 months
Covered
Volumetric attacks on layer 3 and 4
Not covered
Request floods on layer 7 that behave like users
Advanced protection
€49.00$56.84 per month, net

To put the 1.2 Tbit/s into perspective: the largest connection a single system can get with us is 25 Gbit/s. The filter capacity is therefore around forty-eight times that. The traffic is cleaned in the scrubbing centres — dedicated locations where attack traffic is filtered out — and not at the attacked system.

What the protection is not: a replacement for access control. It keeps away traffic that would overload your system — not requests that legitimately get through but still shouldn't have been allowed. That is what roles and policies are for.

The six-stage mitigation process, the pricing table for all three filter levels and the details on additional latency can be found in the network section.

DDoS protection on the network page

First the permissions, then the keys

Access control and audit trail belong to every account and can be set up before the first booking. Keys and secrets are added as soon as there is something to protect. If you need your own HSM partition, clarify the location pair and quorum in advance with sales — the setup includes a key ceremony with a protocol.

Configure systemEvidence and compliance
Access control
included
Key from
€0.90$1.04
Secret from
€0.40$0.46
Cloud HSM from
€439.00$509.24