Orkes BYOK: how does key management work and what are the requirements?

Bring Your Own Key (BYOK) with Orkes lets you keep cryptographic control of your data while still using Orkes as a managed orchestration layer. Orkes never generates or persistently stores your master key; instead, it relies on your cloud KMS and envelope encryption so you can align workflow orchestration with your existing security and compliance posture.

Quick Answer: In Orkes BYOK, your cloud KMS holds the master key and Orkes uses it via KMS APIs to encrypt and decrypt data with envelope encryption. You need a supported KMS (e.g., AWS KMS, Azure Key Vault, or GCP KMS), a customer-managed key, proper IAM/permissions, and network access so Orkes can call your KMS securely.

---

Quick Answer: In Orkes BYOK, your KMS manages the root encryption key and Orkes uses it for envelope encryption of workflow data; Orkes never stores your master key and only sees ciphertext + short-lived data keys.

Frequently Asked Questions

How does Orkes BYOK key management actually work?

Short Answer: Orkes BYOK uses your cloud KMS as the source of truth for encryption keys and relies on envelope encryption: the KMS protects a customer-managed key (CMK), which Orkes uses to generate and decrypt data keys that encrypt your workflow and platform data at rest.

Expanded Explanation:
With BYOK, Orkes treats your KMS as the authoritative key manager. You create and own the CMK in your cloud account; Orkes is granted tightly scoped permission to use that key for cryptographic operations (encrypt, decrypt, generate data key), but not to manage or rotate it. When Orkes needs to store sensitive data (workflow input/output, task payloads, secrets), it uses KMS APIs to derive a data encryption key, uses that data key locally to encrypt the payload, then stores only the ciphertext and a wrapped version of the data key.

This pattern means the long-lived CMK never leaves your KMS. If you disable or revoke Orkes’s ability to use the CMK, future decrypts will fail—instantly enforcing cryptographic access control. It also aligns Orkes with your existing practices for key rotation, usage logging, and incident response in AWS, Azure, or GCP.

Key Takeaways:

• Your KMS holds and protects the master key; Orkes uses it but does not own it.
• Orkes uses envelope encryption: data is encrypted with short-lived data keys that are themselves encrypted with your CMK.

---

What is the process to set up Orkes BYOK in my environment?

Short Answer: You create or select a customer-managed key in your cloud KMS, configure IAM permissions and network access so Orkes can use it, then register the key and KMS details in the Orkes console or via API.

Expanded Explanation:
Enabling BYOK is essentially wiring Orkes into your existing KMS. You pick (or create) a CMK dedicated to Orkes, apply key policies or IAM roles to allow only specific cryptographic operations from Orkes, and ensure outbound connectivity from your Orkes deployment to your cloud KMS endpoint. In the Orkes control plane, you then supply the KMS resource identifiers and any required credentials or role assumptions.

From that point on, Orkes uses the KMS to derive and protect data keys. The setup is usually a one-time operation at the tenant or environment level, and you can validate it by triggering a test workflow execution and confirming successful encryption/decryption operations in your KMS logs.

Steps:

1. Create or choose a CMK in your cloud KMS (AWS KMS, Azure Key Vault, GCP KMS) specifically for Orkes usage.
2. Configure permissions and network so Orkes’s runtime can call KMS cryptographic APIs (encrypt/decrypt/generate data key) but not manage keys.
3. Register the key in Orkes via the Orkes UI or API, providing KMS identifiers and validating encryption/decryption with a test execution.

---

How is BYOK different from Orkes’s default encryption?

Short Answer: With default encryption, Orkes manages the keys for you; with BYOK, your KMS owns the master key and Orkes becomes a client of your key management policies and controls.

Expanded Explanation:
In the default model, Orkes uses platform-managed keys stored and rotated within its infrastructure, still enforcing end-to-end encryption but keeping key lifecycle under Orkes’s control. This is suitable for most teams that want secure encryption without owning the KMS layer.

BYOK shifts control to you. Keys live in your KMS, key rotation and disabling are under your control, and all key usage is logged and auditable through your cloud provider. From a developer perspective the behavior of the platform is the same: workflows, tasks, and secrets remain encrypted at rest and in transit. The difference is in who holds the cryptographic “kill switch” and where audit and governance live.

Comparison Snapshot:

• Default Orkes encryption: Orkes manages keys and rotation; you get encryption by default with minimal setup.
• BYOK: Your KMS holds the CMK; Orkes uses it for envelope encryption, giving you direct control, rotation, and auditability.
• Best for: Regulated or security-sensitive environments that need strict control over keys (e.g., financial services, healthcare, high-compliance SaaS).

---

What are the technical requirements to use Orkes BYOK?

Short Answer: You need a supported cloud KMS with a customer-managed key, IAM policies allowing Orkes to use that key for cryptographic operations, and network connectivity from Orkes to your KMS endpoint.

Expanded Explanation:
Practically, BYOK assumes your organization already runs in a major cloud with KMS available. You provision a CMK in your account, configure key policies or IAM roles to let the Orkes runtime or service principal call Encrypt, Decrypt, and GenerateDataKey (or equivalents), and ensure TLS-protected connectivity between Orkes and your KMS endpoint. If you’re using Orkes-hosted, that usually means enabling secure access to your KMS over the public endpoint with least-privilege IAM; if you’re using customer-hosted, it’s often intra-VPC traffic.

Beyond that, your security team should own policies for key rotation, disabling, and incident response, because Orkes will respect whatever the KMS decides. If the key is disabled or permissions are tightened, Orkes will start failing decrypt operations—acting as a control plane that reflects your crypto posture rather than bypassing it.

What You Need:

• A supported KMS and CMK: AWS KMS, Azure Key Vault, or GCP KMS with a customer-managed key dedicated (ideally) to Orkes.
• Least-privilege access and connectivity: IAM/role or service principal with encrypt/decrypt permissions plus secure network access from Orkes to your KMS endpoint.

---

How does BYOK support compliance and security strategy at scale?

Short Answer: BYOK lets you align Orkes with your existing KMS policies, audits, and rotation practices, so orchestration doesn’t become a compliance exception and you can prove cryptographic control over workflow data.

Expanded Explanation:
In most regulated environments, centralizing key management is non-negotiable. If every platform rolled its own crypto, audit and incident response would be a nightmare. BYOK makes Orkes plug into that central KMS strategy: all key usage is visible in your KMS logs, your security team controls when keys rotate or are disabled, and cryptographic policy is enforced uniformly across services—including your orchestration layer.

This matters most when orchestrating sensitive flows: KYC, payments, healthcare workflows, or AI/LLM tasks that touch PII. Orkes already provides RBAC, secrets management, audit logs, and up to a 99.99% SLA in production-grade deployments. BYOK adds cryptographic governance on top, so you can confidently run mission-critical workflows or agentic systems while still passing security review and external audits.

Why It Matters:

• Centralized governance: Key lifecycle, access, and usage logs stay in your KMS, not spread across individual tools.
• Compliance-friendly orchestration: You can demonstrate that sensitive workflow data is protected under your own keys and policies, reducing friction with security and compliance teams.

---

Quick Recap

Orkes BYOK connects the orchestration layer to your existing cloud KMS so you retain ownership of encryption keys while Orkes focuses on durable, observable workflow and agent execution. Your KMS holds the CMK, Orkes uses envelope encryption for workflow data and secrets, and you control key policies, rotation, and disabling through your cloud provider. To enable it, you need a supported KMS, a customer-managed key, least-privilege IAM access, and network connectivity from Orkes to your KMS endpoint.

Next Step

Get Started