Skip to main content
Customer-Managed Encryption Keys (CMEK) is available on Enterprise plans. Contact support@askparable.com to enable it for your organization.
By default, Parable encrypts your data at rest using Google-managed keys. With CMEK, you control the encryption keys that protect your data. The keys live in your Google Cloud KMS keyring inside Parable’s GCP project.

Rotate keys

Generate new key versions on your schedule. New data uses the latest version; existing data stays readable under previous versions.

Disable access

Disable your key to immediately revoke Parable’s ability to decrypt your data — even in an emergency.

Audit every operation

Google Cloud Audit Logs record every encrypt and decrypt with identity context.

Schedule destruction

Schedule key versions for destruction after a 24-hour waiting period (GCP-enforced).

What Parable controls vs. what you control

Disabling your key immediately stops Parable from accessing your data. Ingestion jobs fail and dashboards return errors until you re-enable the key. See Incident response below.

Your keyring

When Parable provisions your Workspace, we create a dedicated KMS keyring in Parable’s GCP project. You receive IAM access to that keyring only.
  • Keyring name: tenant-{your-slug}-kms{your-slug} is your Workspace slug.
  • Location: Same region as your data (for example us-east1).
  • Keys:
    • main — Symmetric key for data at rest. Auto-rotates every 90 days (7776000s).
    • credential-encryption — Asymmetric key for Provider credentials in transit.
    • content-encryption — Asymmetric key for desktop-agent content. Provisioned on every Workspace keyring.
Sign in to GCP Console with corporate SSO (recommended) or a Google account. During onboarding, Parable configures the method and sends direct links to your keyring and audit logs.
Your IT admin creates an SSO application so your team can reach GCP Console to manage keys and view audit logs.
Parable provides the values marked as from Parable during onboarding. If you do not have them yet, contact support@askparable.com.
Most identity providers support OIDC and SAML. Use OIDC unless your organization requires SAML.
Create a custom OIDC application:
1

Create the OIDC application

In your IdP admin console, create a custom OIDC application. Enter the Redirect URI and Login URL from Parable.
2

Assign users or groups

Assign the people who should manage keys. You can add or remove them later without contacting Parable.
3

Send credentials to Parable

Share Client ID, Client Secret, and Issuer URL (for example https://your-org.okta.com/ or https://oauth.id.jumpcloud.com/) through a secure channel.
4

Parable completes configuration

Parable sends a GCP Console sign-in link, a keyring link, and an audit-log link. Your team can also open GCP from the app in your IdP portal.
  1. Applications → Create App Integration → OIDC - OpenID Connect → Web Application
  2. Set the Sign-in redirect URI to the Redirect URI from Parable
  3. Assign users or groups
  4. Copy Client ID and Client Secret from the General tab
  5. Issuer URL is https://your-org.okta.com/
  1. App registrations → New registration
  2. Set the Redirect URI (Web) to the Redirect URI from Parable
  3. Certificates & secrets → create a client secret
  4. Copy Application (client) ID and the secret value
  5. Issuer URL is https://login.microsoftonline.com/{tenant-id}/v2.0
  1. SSO Applications → Add New Application → Custom OIDC App
  2. Set Redirect URI and Login URL from Parable
  3. Client Authentication Type: Client Secret Basic
  4. Check Email and Profile under Standard Scopes
  5. Assign your test user or group
  6. Copy Client ID and Client Secret
  7. Issuer URL is https://oauth.id.jumpcloud.com/
After federation: you control access in your IdP, no Google account is required, and federated users do not accept a separate Google Terms of Service. To change IdP or rotate credentials, contact support@askparable.com.