Bring Your Own Key (BYOK)
Place every project master key under a Google Cloud KMS or OVHcloud KMS key you control, with live revocation and fail-closed access.
Bring your own key (BYOK) places a key you control in Google Cloud KMS or OVHcloud KMS above the project master keys in your SikkerKey vault. SikkerKey can unwrap those project keys only while your KMS authorizes it, giving you a cloud-console control that can pause live access across the vault.
BYOK changes key custody, not the encryption algorithm and not SikkerKey’s ability to process an authorized read. While your key is available, SikkerKey decrypts requested secret values in memory long enough to return them. BYOK is not zero-knowledge or end-to-end encryption.
#How BYOK fits into SikkerKey encryption
SikkerKey uses envelope encryption so the key in your KMS never encrypts secret values directly.
Layer | What it protects |
|---|---|
Secret data key | Encrypts one secret value with AES-256-GCM. |
Project master key | Wraps the data keys belonging to one project. |
Your KMS key | Wraps every project master key in the vault when BYOK is active. |
Connecting your key re-wraps the small project master keys. SikkerKey does not bulk-decrypt and re-encrypt every stored secret value. Existing secret ciphertext and data keys stay in place, protected transitively through their project master key.
An authorized client requests a project-encrypted secret.
SikkerKey asks your KMS to unwrap that project’s master key.
The project key unwraps the secret’s data key.
The data key decrypts the requested value in memory.
SikkerKey returns the value and clears request-scoped key material.
Project master keys are obtained when needed and are not kept in a server-side read cache between requests. Your KMS therefore remains on the live path for server-verified access.
#What BYOK protects—and what it does not
Covered by your KMS key | Not changed by BYOK |
|---|---|
Project master keys that already exist when you connect | The encryption algorithm used for secret values and data keys |
Master keys for projects and application environments created while BYOK is active | Names, IDs, project metadata, organization data, and audit records |
Project-encrypted secret values, credentials, and connection material through the project-key hierarchy | Dashboard authentication, membership, permissions, and machine identity |
The wrapped project keys and ciphertext carried in database backups | Plaintext processing during an authorized server read |
Server operations that must open or create a project master key | Encrypted fallback copies already stored on authorized client machines |
A backup contains the same KMS-wrapped project keys and encrypted values. Restoring a backup does not bypass your customer key. If the required KMS key or key version has been permanently destroyed, SikkerKey cannot recover the protected data from a backup.
For the broader encryption and responsibility model, see the Security Overview.
#Supported KMS providers
Provider | Key and authorization model |
|---|---|
Google Cloud KMS | A symmetric CryptoKey used for encrypt and decrypt. SikkerKey provisions a dedicated service account for the vault, and you grant that identity the Cloud KMS CryptoKey Encrypter/Decrypter role on the selected key. |
OVHcloud KMS (OKMS) | An AES service key with encrypt and decrypt operations. SikkerKey generates a private mTLS identity and certificate signing request; you authorize it by issuing an access certificate from your OKMS. |
The provider is chosen when setup begins and remains fixed while the connection exists. To move to another provider or another key resource, disconnect the current key safely and then start a new connection.
#Requirements
Paid plan. BYOK is available when the vault’s subscription includes customer-managed encryption.
Vault owner access. Only the active vault’s owner can view or change the BYOK configuration.
A supported KMS key. Create and retain the key in a cloud account your organization controls.
Provider permissions. You must be able to grant access on the exact key or issue an OVHcloud access certificate.
An availability and recovery plan. KMS outages, disabled keys, revoked access, expired certificates, quotas, and destroyed key versions affect SikkerKey operations.
Do not delete the connected key or a required key version. Permanent loss is permanent by design: SikkerKey has no fallback copy of your KMS key and cannot decrypt project master keys that only that key can unwrap.
#Connect a Google Cloud KMS key
Prepare a symmetric Google Cloud KMS CryptoKey with encrypt and decrypt enabled. Keep its full resource name in the form projects/…/locations/…/keyRings/…/cryptoKeys/…. Select the CryptoKey resource, not an individual key-version resource.
Open Settings in the SikkerKey dashboard and find Bring your own key.
Select Connect your key, choose Google Cloud KMS, and continue.
Copy the dedicated service-account email SikkerKey creates for this vault.
In Google Cloud, grant that service account roles/cloudkms.cryptoKeyEncrypterDecrypter on the selected CryptoKey.
Return to SikkerKey and confirm that access has been granted.
Paste the CryptoKey resource name.
Review the provider, key, and location, then select Connect and encrypt.
Wait for the dashboard card to show Active.
Grant the role on the individual CryptoKey when possible. A project-wide grant is broader than SikkerKey needs.
SikkerKey first verifies a random encrypt-and-decrypt round trip. Only after that succeeds does it activate the connection and re-wrap the vault’s project master keys. You do not provide a Google Cloud user credential or administrative service-account key.
#Connect an OVHcloud KMS key
Prepare an OVHcloud KMS domain and an AES service key that permits encrypt and decrypt operations. SikkerKey uses a client certificate for mutual TLS when it calls your OKMS.
Open Settings in SikkerKey, select Connect your key, choose OVHcloud KMS, and continue.
Copy the certificate signing request generated for this vault.
In the OVHcloud console, open the OKMS Access certificates area and create an access certificate by providing your own CSR.
Paste the SikkerKey CSR, issue the certificate, and download the resulting certificate.
Return to SikkerKey and paste the issued certificate.
Enter the OKMS endpoint and domain ID shown under General information.
Enter the AES service-key ID shown under Service Keys.
Review the endpoint, domain, and key, then select Connect and encrypt.
Wait for the dashboard card to show Active.
The private key behind the CSR is generated and retained by SikkerKey; only the public signing request goes to OVHcloud. Activation verifies that the issued certificate can reach the selected AES key before any project master key is moved.
Signing the CSR authorizes SikkerKey’s vault-specific mTLS identity. It does not export your AES key or give SikkerKey general access to the OVHcloud account.
#Understand connection states
Status | Meaning |
|---|---|
Not connected | The vault uses SikkerKey-managed protection for project master keys. |
Setup in progress | A provider identity has been created, but no project master key has moved to the customer key yet. |
Active | Existing project master keys have been moved to the customer key, and new project keys are wrapped there from creation. |
Disconnecting | SikkerKey is moving customer-key-wrapped project keys back to SikkerKey-managed protection. |
You can cancel Setup in progress without changing stored data. For Google Cloud, SikkerKey removes the half-provisioned service account. For OVHcloud, it discards the incomplete local identity. The vault remains on SikkerKey-managed encryption.
#Operate an active BYOK vault
The active card shows the provider, connected key, connection date, and the owner who connected it. Google Cloud connections also show the dedicated service account and key location. OVHcloud connections show the endpoint, key ID, certificate expiry, and any renewal reminder.
Event | Effect |
|---|---|
SikkerKey remains authorized and the key is enabled | Server-verified project secret operations continue normally. |
You revoke the grant or access certificate | New KMS unwraps fail and affected operations pause. |
You disable the key or a required key version | Project master keys protected by it cannot be opened. |
The provider is unavailable or a quota is exhausted | Affected operations fail closed; SikkerKey does not fall back to its managed root. |
You restore authorization and key availability | The next server request can succeed without re-encrypting stored secrets. |
You permanently destroy the required key material | Protected project data becomes unrecoverable. |
Revoking BYOK pauses live server access; it does not reach backward into an authorized machine’s local storage. If encrypted fallback is enabled, a client may still return a previously cached value without contacting SikkerKey or your KMS. Review and clear client caches when your response requires cached copies to stop working too.
#Manage Google Cloud key versions
A Google Cloud CryptoKey can have several versions. Encrypt operations use its current primary version, while decrypt operations for existing ciphertext still depend on the version that originally encrypted it.
Keep every key version that has wrapped a SikkerKey project master key enabled and recoverable.
Changing the primary version affects future wraps, including newly created projects, but does not automatically re-wrap older project master keys.
Do not schedule destruction of an older version merely because a newer version is primary.
To retire the entire CryptoKey, disconnect it in SikkerKey while every required version remains usable, then complete your provider-side retirement.
SikkerKey connects to the CryptoKey resource rather than one version. A successful provider rotation does not prove older ciphertext can be decrypted after you disable or destroy its original version.
#Renew an OVHcloud access certificate
The OVHcloud access certificate is the identity SikkerKey presents to reach your AES key. It can expire independently of the key. The dashboard warns when expiry is within 30 days and pauses reads when the certificate has expired.
Open the active Bring your own key card and select Renew certificate.
Copy the new certificate signing request.
On the same OKMS, issue a new access certificate from that CSR.
Paste the issued certificate into SikkerKey and select Renew.
Confirm that the active card shows the new expiry date.
The existing certificate remains in use while you complete the renewal. SikkerKey verifies the replacement against the same AES key before swapping it in, so a rejected certificate does not replace the working identity. No project master key is re-wrapped during certificate renewal.
Use Set renewal reminder to choose a future date for one email reminder. Pick a date before the displayed certificate expiry.
#Revoke and restore access
Use provider-side revocation when you intentionally want a reversible stop.
Provider | Pause access | Restore access |
|---|---|---|
Google Cloud KMS | Remove the dedicated service account’s role, deny its key access, or disable the required key version. | Restore the role or authorization and re-enable every required version. |
OVHcloud KMS | Revoke or expire the issued access certificate, or disable the AES service key. | Issue and submit a valid replacement certificate, or restore the key’s availability. |
After access is restored, retry the affected request. There is no vault migration to reverse because the project master keys remain wrapped under the same customer key.
#Disconnect your key safely
Disconnecting is not the same as revoking access. It deliberately moves every customer-key-wrapped project master key back under SikkerKey-managed protection.
Confirm that the connected key, every required key version, and SikkerKey’s provider identity are still usable.
Open Settings and select Disconnect key.
Keep the grant, key, and—on OVHcloud—the current access certificate active while SikkerKey re-wraps the project keys.
Wait for the dashboard to return to Not connected.
Verify normal secret access.
Only then remove the old provider authorization or retire the key.
Disconnecting needs one final decrypt through your KMS for every project key. If access was revoked first, the disconnect cannot finish. Restore access and retry. If the key was permanently destroyed, SikkerKey cannot move or recover the project keys.
Reads can pause briefly while a disconnect is moving project keys. Run the change during a controlled window. If a migration is interrupted, SikkerKey keeps the completed work and lets you retry after access is restored.
After a successful Google Cloud disconnect, SikkerKey removes the dedicated service account it provisioned. OVHcloud access certificates belong to your OKMS, so revoke or remove the old certificate there after SikkerKey confirms the disconnect.
#Permissions and audit activity
Only the vault owner can view, connect, renew, or disconnect a customer-managed key. BYOK also requires the Enterprise entitlement; access roles and project scope do not grant access to the vault encryption control.
Audit event | Severity |
|---|---|
BYOK enrollment started | High |
BYOK enrollment cancelled | Medium |
Customer key connected | Critical |
Customer key disconnected | Critical |
OVH access certificate renewed | High |
Each event records the acting owner, time, source IP, provider, and relevant action details. Review these changes in the Audit Log and configure Alerts for the security events your team needs to receive.
#Security and responsibility boundaries
SikkerKey handles | You control |
|---|---|
A dedicated, vault-specific provider identity | The KMS account, key resource, region, key policy, and lifecycle |
Encryption of its provider credential at rest | Granting and revoking the identity’s access |
Verification before activation and renewal | Availability, quotas, key versions, retention, and provider billing |
Per-request KMS calls without a cached project master key | Incident procedures for revocation and client-side cached secrets |
Fail-closed behavior when KMS access fails | Safe disconnect before permanent key destruction |
SikkerKey never imports or exports your customer KMS key material. Google Cloud uses a SikkerKey-created service account dedicated to the vault. OVHcloud uses a SikkerKey-generated private mTLS key whose public CSR you authorize. These identities allow only the KMS operations your provider grant permits.
#Troubleshoot BYOK
Symptom | What to check |
|---|---|
The BYOK card is not available | Confirm you are the active vault’s owner. Organization members cannot view the encryption control. |
The card says Not on your plan | Confirm the vault is on an Enterprise plan that includes bring your own key. |
Google Cloud setup cannot connect | Check the CryptoKey resource name, that the key and required versions are enabled, and that the displayed service account has Cloud KMS CryptoKey Encrypter/Decrypter on that key. |
OVHcloud setup cannot connect | Confirm the certificate was issued from the displayed CSR, the endpoint and domain ID match the OKMS, the AES key ID is correct, and the key permits encrypt and decrypt. |
The vault remains at Setup in progress | Select Finish connecting to resume, or cancel setup to remain on SikkerKey-managed encryption. |
Secret operations began failing after a cloud change | Restore SikkerKey’s key authorization, re-enable required versions, check provider availability and quotas, and review OVH certificate expiry when applicable. |
An OVH certificate expired | Start Renew certificate, sign the new CSR on the same OKMS, and submit the issued certificate. |
Disconnect fails | Restore SikkerKey’s access to the customer key and every required version, then retry without revoking provider access until the dashboard shows Not connected. |
A rotated Google Cloud key cannot decrypt older projects | Re-enable the original key versions that encrypted those project master keys. A new primary version does not re-wrap existing ciphertext. |
Access is revoked but a client still returns a value | Check whether encrypted fallback or another application-level cache is serving an earlier authorized copy. |