Shuffle secrets in an external KMS such as Vault: what changes and why teams do it
With this integration, a playbook refers to an API key by a kms/ path reference, and Shuffle resolves that reference at run time through a KMS app that runs under an IAM-scoped identity and calls a Get KMS key action. After that change, Shuffle's own encrypted store no longer holds the authoritative copy of the ticketing, threat intelligence and EDR keys, because the external KMS does. The exact reference syntax and the KMS app and action names must be confirmed in the current Shuffle documentation and app listing before design starts, since a design built on the wrong names will fail on its first run.
Security teams usually make this move for control, not convenience. Each of these keys opens a system of record or a response capability, so the team wants one place to rotate, revoke and audit them, with access logs kept by the KMS rather than inside the automation platform. It also separates duties: the people who own the vendor accounts can manage the secret, while the people who build and operate Shuffle manage only the policy that allows the workflow to read it. Ask the KMS owner which audit events are retained and for how long, because that record becomes the evidence trail for who could read each key.
Moving the source of truth does not remove Shuffle's own encryption. Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret, and the docs warn that losing or changing that value breaks all saved app authentications. Teams with an external KMS still need to back up and protect that modifier, because any credential left in Shuffle's store stays encrypted with it. Inventory what remains in Shuffle after the change, and plan a deliberate move for each item instead of leaving old copies in place.
Several decisions shape the design. Choose the KMS and the authentication method the Shuffle side will use, and confirm that the KMS app supports them. Agree a path naming convention so that rotation in the KMS does not force playbook edits. Map the network route from the runtime, because Orborus polls the backend and starts a worker for each execution, and the worker starts the app containers that make the KMS call. In a hybrid deployment with a local Orborus, that route runs inside your network and must reach the KMS without weakening its access controls. Also confirm how a rotated value reaches running and queued executions.
Before you commit, run a test workflow on a non-production instance that reads one key through the KMS path, rotates that key in the KMS, and confirms the next run uses the new value. Then force a KMS failure, such as an expired token or an unreachable endpoint, and record how the workflow fails and what alert it raises. Ask any implementation partner to show both results in writing as part of the quote, along with the rollback steps if the KMS path must be removed.
What you need in place before configuring a KMS reference in Shuffle
Each item below is a decision or check that the KMS reference depends on. Confirm the Shuffle version and deployment pattern first, because they determine where the network path and trust chain must work. Then settle who owns the encryption modifier before anyone stores a secret.
Shuffle version and release line
Shuffle no longer supports versions older than v2.1.1, so any earlier installation needs an upgrade before this work begins. The current published release is v2.3.0, and the Shuffle docs recommend the latest Docker tag for stable use. Use the nightly tag only in a lab, because experimental changes can alter behavior you need to test against your KMS before anything reaches production.
Deployment architecture and component placement
Shuffle documents four deployment patterns: a single server with Docker Compose, distributed Docker Swarm, a hybrid of Shuffle Cloud with a local Orborus, and Kubernetes with Helm charts. The pattern decides where the backend and Orborus run, and therefore which hosts must reach the KMS endpoint. Record where each component runs before you write any KMS reference, because the network and trust work depends on that map.
Dedicated KMS identity and access scope
Create a dedicated account, role or service identity in the KMS for Shuffle rather than reusing an administrator credential. Shuffle reads secrets through its IAM app and the Get KMS key action, so the identity needs read access only to the keys that playbooks will reference. Confirm with your KMS vendor how this identity authenticates, how its permissions are scoped, and how its reads are logged.
Network path to the KMS endpoint
Both the Orborus runtime and the backend need outbound access to the KMS endpoint, and the path must work from the networks where the worker containers actually run. Check DNS resolution, egress firewall rules, any proxy and any allow lists, then test from inside the container network. In the hybrid pattern the local Orborus needs no inbound firewall ports, but it still needs that outbound route.
TLS trust chain for the KMS endpoint
Every connection to the KMS endpoint must present a certificate that chains to a root the runtime trusts. Install the internal CA bundle into the images or mounts used by the backend and by the containers Orborus starts, then confirm that certificate names match the hostname Shuffle connects to. Plan renewal and rotation of CA and server certificates so a rotated certificate does not silently break playbooks that depend on stored secrets.
Named owner for the encryption modifier
Assign one named owner to SHUFFLE_ENCRYPTION_MODIFIER, the value Shuffle uses to encrypt saved app credentials and API keys in OpenSearch with AES-256. The docs warn that losing or changing this value breaks all saved app authentications, so the owner must agree how it is stored, backed up and rotated. Keep this ownership separate from the people who administer the KMS, and document the handoff before any reference is configured.
How Shuffle resolves a kms/ reference at run time
Shuffle does not need the secret value to store a playbook. The backend holds workflow definitions, and a kms/ reference is text inside a definition that points to a key in your external store. Orborus, the runtime component, polls the backend for jobs. When a workflow runs, Orborus starts a worker for that execution, and the worker starts the app containers that perform each action. The reference therefore moves through the backend and runtime as a pointer, and the value is resolved at the point where a container needs it. Before you design around this, confirm which component performs the KMS call in your version of Shuffle: Orborus, the worker, or the app container. Each has a different network path to Vault and a different identity, so the answer changes your firewall rules and your IAM policy.
The fetch point matters most for what gets written down. Whatever component resolves the value should hold it in memory only as long as the action needs it. The design goal is that the resolved value never lands in a workflow definition, an action result, a workflow variable, or a log line that the backend ingests. Shuffle keeps its documents, including workflow definitions, in OpenSearch, so anything written there becomes persistent and searchable. Test this for each app you use, because an app that echoes its request parameters into its output will write the secret into the execution history. Ask the app authors or review the app's code for that behavior before you approve it for production playbooks.
Shuffle's own protection for saved credentials is separate from the KMS path. The configuration docs state that saved app credentials and API keys are encrypted in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret. If you keep a credential inside Shuffle, that setting is what protects it at rest, and losing or changing that modifier breaks every saved app authentication. Confirm with Shuffle whether a value resolved from your KMS is ever stored through this path in your version, and whether it is encrypted in any form. Do not assume the KMS reference removes the need to protect SHUFFLE_ENCRYPTION_MODIFIER, because it is still required for any credential Shuffle stores.
Plan the runtime around these answers. The high availability guidance recommends more than one Orborus node, so if you run several, every node that might start a worker for a KMS-backed action needs the same access to Vault. Record which identity each node uses, how that identity is rotated, and what happens when Vault is unreachable. Confirm how a failed fetch appears in the execution. It should stop the step with a clear error and never fall back to a stored value or an empty string. Then run a test in a non-production environment: trigger a workflow with a known test secret, search OpenSearch and the worker logs for that string, and keep the results as evidence for your review.
How to configure external KMS references in Shuffle step by step
This sequence moves Shuffle playbook credentials out of its own database and into a key management system your team controls. It starts with a read-only identity and a registered connection, proves one workflow end to end, then migrates the remaining workflows in batches with a check at each stage.
Create a scoped read-only identity in the KMS
The security or platform team creates an identity in the KMS that can read only the paths and keys the chosen playbooks need, with no write, list-all or administrative rights. Record the approved path list in a change ticket so reviewers can compare it against each workflow later. This step is done when the identity can read one test path and is denied on a path outside the list. Confirm both results with the KMS's own access tooling before moving on.
Install or confirm the KMS app in Shuffle
A Shuffle administrator confirms that the IAM app providing the Get KMS key action is installed and at a version the team has tested. If it is missing, install it through the method your Shuffle deployment uses, then check its version in the app list. The step is done when the Get KMS key action appears in the workflow editor with the parameters you expect. Verify this before any live credential is changed.
Register the connection with endpoint and auth method
Create the connection in Shuffle using the KMS endpoint address, the authentication method the KMS supports, and the scoped identity from the first step. Shuffle encrypts saved app credentials with the SHUFFLE_ENCRYPTION_MODIFIER, so confirm that the modifier is backed up separately, because losing or changing it breaks saved app authentications. The step is done when a connection test against a known path succeeds and the result does not include the secret value.
Replace one stored credential with a kms path reference
In one workflow that targets a non-production system, replace a stored credential field with a kms/ path reference that points to the matching secret. Keep the original value in the change record until the test passes, then remove it from the workflow. The step is done when the workflow saves and the field shows the reference in place of the value, and the old value no longer appears in the workflow definition.
Run a test execution and inspect outputs
Run the workflow manually and confirm that its status matches the expected result for a successful run. Then search the run output and the stored execution data for the secret value, and query the workflow's entries in the OpenSearch database with your usual tooling. The step is done when the run completes with the expected status and the secret value appears in neither the output nor the stored records. If it appears, stop and correct the action output before continuing.
Test failure handling before wider rollout
Force the failure cases your runbook depends on: a wrong path, a denied identity and an unreachable KMS endpoint. For each case, confirm that the run stops or follows your error branch, that the error message identifies the failed lookup without echoing the secret, and that any alert or notification fires as designed. The step is done when each failure produces the documented status and log entry, recorded in the test record for the change.
Migrate remaining workflows in batches
Move the remaining workflows in small batches grouped by owner or by the KMS paths they read, repeating the replacement, test and inspection steps for each batch. Limit the scoped identity to the paths in the batch currently in progress, and remove old stored credentials only after that batch passes. The step is done when every workflow references the KMS, migrated items no longer hold stored credentials, and the approved path list matches what each workflow actually reads.
Mapping playbook credentials to KMS paths, identities and owners
This table maps each playbook credential type to an illustrative KMS path, the identity allowed to read it, the workflows that call it, the rotation owner and the app version to confirm. Path names are examples only, so confirm the exact kms/ reference format in the Shuffle docs before you write any policy. The main takeaway is that each credential needs one named reader policy and one named rotation owner before its workflow goes live.
| Credential type | Illustrative KMS path and reader | Workflows and rotation owner | App version to confirm |
|---|---|---|---|
| Ticketing token | Illustrative path: kv/shuffle/prod/ticketing. Read only by the policy bound to the Shuffle backend role. | Ticket create and update workflows. Owner: the service desk team that issues the token. | Confirm the ticketing app version accepts kms/ references for its token field. |
| Threat intelligence API key | Illustrative path: kv/shuffle/prod/threat-intel. Read by a policy limited to enrichment workflows. | Indicator lookup and enrichment workflows. Owner: the threat intelligence platform owner. | Confirm the app version and whether its key field is treated as a credential in the app definition. |
| EDR API credential | Illustrative path: kv/shuffle/prod/edr. Read by a policy limited to containment workflows and their runtime identity. | Host status checks and isolation actions. Owner: the endpoint security team, with approval for rotation. | Confirm which identity fetches the key, the backend or the worker, and the EDR app version that supports it. |
| SIEM service account | Illustrative path: kv/shuffle/prod/siem-svc. Read by a narrow policy for query and case write-back workflows only. | Search and alert write-back workflows. Owner: the SIEM platform team, with rotation tracked in its change process. | Confirm the SIEM app version and whether it authenticates with a token or a username and password. |
| Shuffle encryption modifier | Not a playbook credential. Keep it in KMS under a separate path readable only by platform operators. | No playbook uses it directly. Owner: platform operations. Changing it breaks saved app authentications. | Applies to any Shuffle release that encrypts saved app credentials. Confirm in the configuration docs before changing it. |
Security settings that keep the KMS boundary meaningful
Moving playbook credentials out of Shuffle only protects them if the identity, transport, workflow and logging controls around the KMS hold as well. The six cards cover the access, encryption, editing, redaction, transport and rotation decisions that connect them. Check each one against your own KMS paths and workflow inventory before you go live.
Scope the KMS identity per path
Give the identity Shuffle uses to read secrets a policy that allows read access only to the kms/ paths its workflows reference. Grant no list, write or delete rights unless a documented need exists, and check that the policy matches the paths in each app's configuration. Keep administrative tokens out of workflows, app configuration and Shuffle's own stored settings, so an edited workflow cannot reach the KMS admin surface. Review the policy whenever a playbook adds a new path.
Hold the encryption modifier outside Shuffle
Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret. Any credential that remains inside Shuffle still depends on this value, so it needs protection of its own. Store it in a separate secret store from the KMS credential, back it up, and place every change under change control. The Shuffle docs warn that losing or changing it breaks all saved app authentications, so test a restore before you rely on it.
Control who edits output-forwarding workflows
A workflow that prints or forwards action output can expose a secret resolved at runtime, even though the secret itself lives in the KMS. Limit edit rights on those workflows to a named group, require a second review for changes to output and forwarding steps, and keep a record of who changed them. Check whether any step sends resolved values to chat, ticketing or webhook destinations. Treat a change to an output step as a change to a data-sharing path.
Redact secrets from logs and results
Resolved secret values can reach execution results, container logs and workflow history if an app echoes its input or includes a parameter in an error message. Run a test workflow with a known canary value and search every store it touches to see where the value lands. Confirm how Shuffle's execution history and any log shipping handle the value, and set retention on those stores to match your policy. Ask app authors which redaction they perform.
Encrypt the connection to the KMS
Requests from Shuffle's runtime to the KMS return secret values, so the channel must be encrypted end to end. Use TLS with certificates from your internal certificate authority or the KMS operator, and confirm that the chain and hostname are validated in the app configuration. Do not disable verification to make a test environment work. Confirm which network path the Orborus workers use to reach the KMS, since workers may run on hosts separate from the backend.
Rotate the KMS credential Shuffle uses
The credential Shuffle presents to the KMS is a long-lived secret that needs a rotation schedule and a tested procedure. Plan the change so the new credential is issued and placed in Shuffle's configuration, and the old one is revoked in a set order after running workflows are checked. Ask the KMS team which rotation interval their policy requires, and record the date of each rotation. Confirm that rotation leaves the encryption modifier untouched, since that secret has its own change control.
How to test a KMS-backed playbook before it touches production alerts
Start the test plan with a canary secret. Create a dedicated value in your KMS, grant the identity used by the Shuffle IAM app read access to that one path only, and build a test workflow that calls the Get KMS key action with a kms/ path reference to it. The workflow should not print the value. It should return a fixed marker string and a success flag that a later step can check. This gives you a pass or fail signal that does not depend on anyone reading a secret in the UI. Run the workflow in a non-production environment first, and confirm the exact reference syntax and action output format in the documentation for your Shuffle version before you write checks around them.
The most important check is whether the canary value appears anywhere it should not. After a test run, search the OpenSearch document store for the raw value and for any encoded or partial forms your team would consider a leak. Cover workflow execution records, action results and any saved app data. Then check Orborus and worker logs, and the app container logs, on the node that ran the action. Confirm which execution artifacts store action output in your version, because some records keep full action results and others keep only status. If an artifact stores output, decide whether the playbook must suppress it before the test can pass. Repeat the search after a run where the action fails, since error messages are a common place for values to leak.
Next, test the failure path by forcing a KMS outage. Remove the permission from the IAM identity, or block the network route from the runtime to the KMS, for a short window, then run the canary workflow. Confirm that the run fails with an error your on-call team can recognize, that the failure appears in the execution history, and that any notification or fallback branch behaves as designed. A playbook that continues with an empty value could close alerts incorrectly, so treat that outcome as a failed test. Then run the rotation test: rotate the canary value in the KMS, run the workflow again without editing the playbook, and confirm it uses the new value. Record whether a restart or cache flush was needed.
Finally, repeat the canary workflow on each Orborus node. The Shuffle architecture docs describe Orborus as the component that polls the backend for jobs and starts a worker for each workflow execution, so the node that runs your action determines the network path, identity and runtime that resolve the reference. Include at least one node on a second runtime, for example a Docker Swarm host alongside a Kubernetes deployment, and confirm how to route a test run to a specific node in your version. If a node passes the first run but fails on another, investigate that deployment first. Keep a dated record of each run, including the node, the result and the leak check, and make that record a gate for promoting the playbook to production alerts.
Common KMS reference failures in Shuffle and how to fix them
This table lists the failures most often seen when Shuffle reads playbook credentials from an external key management system, with the likely cause, the check to run and the fix for each. Work through the checks in order, starting with network reachability and the worker host, because several symptoms look alike. Items marked for confirmation depend on the Shuffle version or the KMS product in use and should be verified against the current documentation before you change production settings.
| Failure | Likely cause | Check to run | Fix |
|---|---|---|---|
| Unreachable KMS endpoint from a worker host | Firewall, DNS or routing blocks the worker host from reaching the KMS address, often on only some hosts. | Test TCP reachability and name resolution from the same host and container network that runs the app. | Open the required path from the worker subnet, fix DNS, or move the worker to a network that can reach the KMS. |
| Expired or rotated KMS token | The token lapsed, was revoked, or was rotated in the KMS without updating the Shuffle reference. | Confirm the token's lifetime and last rotation date in the KMS, then test a read with it directly. | Issue a new token for the IAM app identity, update the stored reference, and set a rotation reminder. |
| Policy allows list but not read | The KMS policy grants listing of paths but omits read capability on the secret path. | Compare the policy with what the Get KMS key action needs, then test list and read separately. | Add read permission on the specific secret path only, keeping the grant scoped to that path. |
| Wrong path or mount name in the kms/ reference | The kms/ reference names a mount or path that differs in case, prefix or engine version from the KMS. | List the mounts and paths in the KMS and compare each segment of the reference with it exactly. | Correct the reference to the exact mount and path, then rerun the test with the same input. |
| SHUFFLE_ENCRYPTION_MODIFIER changed | A changed modifier means credentials saved before the change in OpenSearch can no longer be decrypted. | Compare the value in the running backend configuration with the value used when the credentials were saved. | Restore the original value. If it is lost, re-enter saved app credentials after the KMS references are in place. |
| Worker on a runtime with an old certificate chain | The worker runtime lacks the CA chain the KMS endpoint presents, so TLS validation fails. | Test a TLS handshake to the KMS from the worker runtime and compare the result with a current host. | Install the internal CA chain in the worker image or host trust store, then restart the runtime. Confirm details with your platform team. |
| App version mismatch | The KMS app version does not match the backend or worker version, so its actions or fields differ (confirm). | Compare the app version in use with the Shuffle release on the backend and Orborus. Check the release notes (confirm). | Align the app version with a supported Shuffle release, then retest the Get KMS key action. Confirm the version pairing first. |
What each KMS failure does to a running workflow
Each external KMS failure reaches a running workflow differently, so each needs a deliberate design choice before the first playbook goes live. The four states below cover a lookup that cannot start, one that starts but answers slowly, a secret that changes mid-run, and a secret that disappears. The exact behavior of each state must be verified in your Shuffle version, not assumed from the design.
KMS unreachable at trigger time
The KMS endpoint cannot be reached when a workflow starts, so the first kms/ reference fails before any action runs. Confirm which component performs the lookup, because the network path from that component, whether a worker or an Orborus node, must be open to the KMS. Check whether the execution is marked failed or left stuck, and what the execution log records. Set a retry limit for the lookup, and confirm whether retries fetch the credential again or reuse a cached value.
KMS slow but reachable
The KMS answers, but after a delay long enough to stall a step or push a run past its schedule. Slow responses are harder to spot than outages because the workflow keeps running and no error appears. Measure lookup time under the load your Orborus nodes will actually carry, and set a timeout you can justify from those measurements. Alert on lookup latency as well as on failures, and confirm whether a timeout triggers a retry or an immediate failure in your version.
Secret rotated mid-execution
A secret is rotated while a workflow is running, so an early step may use the old value and a later step may fetch the new one. Confirm whether a run keeps the value it read at its start or re-reads the secret on each use. For a playbook that calls a ticketing or firewall API across several steps, check that the credential held by the run stays valid after rotation. Schedule rotation outside long-running executions where possible, and record which secret version each run used if your KMS logs it.
Secret deleted or path changed
A referenced secret is deleted or moved, so the kms/ reference resolves to nothing. Fail closed on destructive actions such as disabling accounts, blocking addresses or isolating hosts, so the step stops instead of continuing with an empty or guessed credential. Non-destructive enrichment steps may be allowed to fail and let the case continue with a warning, if the playbook is built to tolerate that. Alert on every lookup that returns not found, and confirm the exact error your version reports.
Questions teams ask before moving Shuffle secrets into a KMS
How much does it cost to move Shuffle secrets into a KMS?
The cost comes from three places: internal staff time, the key management system itself, and any partner work. Your KMS admins and workflow owners spend time on the design, testing and cutover, and that time is paid from your own budget. KMS licensing or hosting is paid to the KMS vendor or cloud provider, and it depends on the product and deployment model you choose. DeployOpen does not publish a price list. Partner work is agreed as a fixed scope in writing before work starts, and the quote follows from that scope. Most of the cost is one-time (design, build, credential migration, testing). KMS fees and Shuffle licensing recur. Ask any quote to split the work by credential type, by workflow and by one-time versus recurring cost.
How long does a Shuffle KMS migration take?
The duration depends mostly on how many workflows read credentials and how many credential types are involved. API keys, OAuth tokens, basic authentication and cloud access keys each need their own path, policy and test. Other drivers include whether a KMS already exists and is administered, how many environments need the change, and how many change windows your team can offer. No single duration applies to every environment, so ask for a timeline tied to a written inventory of workflows and credentials. A good quote states the assumptions behind the timeline, names the workflows in scope, and lists which items depend on your KMS team or your change calendar.
What does the client need to provide for this work?
Three groups of people need to be available. KMS administrators provide the secret paths, access policies, the authentication method for Shuffle and the IAM identity that the Shuffle app will use. Workflow owners confirm which playbooks call which apps, which credentials each action uses and which steps must keep running during cutover. Platform owners provide a test window on a non-production Shuffle instance and approve production changes. You also need controlled custody of the Shuffle encryption modifier, because it is required for any saved credentials that remain. Agree on who signs off each change before the work starts so that test results and approvals are recorded in one place.
Can our own team move Shuffle secrets into a KMS without a partner?
Yes, if your team already runs both Shuffle and the KMS. The work is mostly configuration: writing kms/ path references in workflows, setting up the IAM identity and the app that performs the Get KMS key action, and defining how each workflow handles a failed lookup. Your team can do this, but the risks sit in the places teams often skip: the encryption modifier, existing saved credentials, and failure tests that simulate a KMS outage. A partner works under a written, fixed scope with defined deliverables and documentation, which helps when the team is small or when the change must be audited later. Confirm which Shuffle version and app capabilities your environment runs before you plan the steps.
What happens to credentials already saved in Shuffle?
Saved credentials stay in Shuffle's database until you remove them. Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret. Moving a workflow to a KMS path does not, by itself, delete the older saved entry. Decide credential by credential whether to create the secret in the KMS, switch the workflow, run both paths during a short cutover, and then retire the saved entry. Do not change or lose the encryption modifier during this work, because losing or changing it breaks every saved app authentication. Take a backup of the OpenSearch data and the modifier before any change, and confirm with Shuffle how its interface removes saved credentials.
What breaks when the KMS is unavailable during a workflow run?
The workflow step that needs the secret fails, and the rest of the playbook depends on how you designed the failure path. Common causes are a wrong secret path, an IAM policy that denies the read, an expired token, or a network route that blocks the worker container from reaching the KMS. Decide for each workflow whether it should stop, retry, or send an alert to a human, and record that choice. Test each path on purpose by denying access in the test environment and checking the output. Engineers should also confirm that error messages do not print secret values into execution logs, and that the runtime containers can reach the KMS endpoint from every Orborus node that runs these workflows.
Does moving secrets to a KMS change the Shuffle license cost?
It can, because Shuffle licensing is measured by app runs. Shuffle counts actions that execute in a workflow as app runs, and it does not count triggers or skipped actions. A KMS lookup that runs as an action may therefore add to your app run count, especially in playbooks that run often or that fetch several secrets per execution. Users, apps and workflows are unlimited under Shuffle's pricing model, so the main lever is how often lookups run. Before you finalize the design, check Shuffle's pricing article and confirm with Shuffle how it counts this action. Include the expected lookup frequency in your planning so that licensing and KMS usage costs are estimated from the same assumptions.
How DeployOpen scopes and delivers Shuffle KMS integrations
DeployOpen treats Shuffle secrets in an external KMS such as Vault as an integration project with its own scope, build and handover. We start from the playbooks and apps that need credentials, then agree in writing how each secret is referenced, retrieved and failed over. The work runs inside your infrastructure, with your security team in the loop at each stage.
How we scope
- Inventory every playbook, app and workflow that currently holds a credential in Shuffle.
- Agree in writing which secrets move to the external KMS, with an owner for each path.
- Confirm with your KMS team the path layout, access policy and the IAM identity Shuffle will use.
How we build
- Create the Shuffle app and key action in a test instance before any production playbook changes.
- Convert playbook credential fields to kms/ path references, one tested workflow at a time.
- Define failure handling for unreachable KMS, denied reads and missing paths, and test each case.
How we hand over
- Document each secret path, its owner, the IAM permissions granted and the rotation process.
- Provide a runbook covering KMS outages, Shuffle restarts and how to verify playbook authentication.
- Walk your operations team through the failure tests so they can repeat them after changes.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Re-test KMS references after each Shuffle upgrade, before the change reaches production workflows.
- Confirm the support scope, response expectations and fees in the written quote before work starts.
