Skip to content

Component copying enables you to replicate Access Policy: Access Policies define, enforce, and audit access between Client and Server Workloads by cryptographically verifying workload identity and contextual factors rather than relying on static secrets.Learn more components from one Resource Set: Resource Sets are organizational containers that group Access Policy components together, enabling you to manage configurations across different environments, regions, or use cases.Learn more to another. This feature addresses a critical workflow gap for enterprise tenants managing complex deployment topologies across multiple environments.

When you copy a component, the system creates an independent duplicate in your target Resource Set. The original component remains unchanged in the source Resource Set, and the new copy receives its own unique identifier. This approach lets you replicate proven configurations without risking your live deployments.

You can copy the following Access Policy components between Resource Sets:

ComponentWhat gets copied
Client Workload: Client Workloads represent software applications, scripts, or automated processes that initiate access requests to Server Workloads, operating autonomously without direct user interaction.Learn moreConfiguration and Standalone Certificate Authority (CA) associations
Server Workload: Server Workloads represent target services, APIs, databases, or applications that receive and respond to access requests from Client Workloads.Learn moreAll application protocol configurations
Trust Provider: Trust Providers validate Client Workload identities through workload attestation, verifying identity claims from the workload's runtime environment rather than relying on pre-shared secrets.Learn moreAll types and match rule configurations
Credential Provider: Credential Providers obtain the specific access credentials—such as API keys, OAuth tokens, or temporary cloud credentials—that Client Workloads need to authenticate to Server Workloads.Learn moreAll types and configurations (3LO providers require reauthorization)
Access Condition: Access Conditions add dynamic, context-aware constraints to authorization by evaluating circumstances like time, location, or security posture to determine whether to grant access.Learn moreConfiguration and integration associations
Access PolicyThe policy and all related components in this table

When you copy an Access Policy, the system copies all related components together, creating a complete, self-contained policy in the target Resource Set.

Understanding what copying components does and doesn’t do helps set correct expectations.

  • Preservation - Original components in the source Resource Set remain unchanged and fully functional.
  • New identity - Each copied component receives a new unique identifier in the target Resource Set.
  • Access control - You can only copy to Resource Sets you have permission to access.
  • Source exclusion - The system excludes the source Resource Set from the target selection list to encourage reusing existing configurations within the same Resource Set.
  • Doesn’t move components - Copying creates a duplicate; the original stays in place.
  • Doesn’t manage Edge deployment - After copying, you manage where and how to deploy new components to Aembit Edge: Aembit Edge represents components deployed within your operational environments that enforce Access Policies by intercepting traffic, verifying identities, and injecting credentials just-in-time.Learn more.
  • Doesn’t auto-bind to Edge components - You must configure Edge bindings in the target Resource Set.
  • Doesn’t allow same-Resource-Set copies - You can’t copy a component to the same Resource Set it already exists in.

Component copying supports the following enterprise workflows:

Promoting configurations between environments

Section titled “Promoting configurations between environments”

Copy configurations from a staging Resource Set to a production Resource Set. This lets you test and validate configurations in a safe environment before deploying them to production.

Deploy identical Access Policy configurations to new AWS regions or cloud environments. Each region can have its own Resource Set with copies of your proven configurations.

Copy a configuration into a sandbox Resource Set to test significant changes without affecting live workloads. If the experiment fails, the original configuration remains untouched.

The following special considerations apply when copying components.

Credential Providers that use OAuth 2.0 Authorization Code flow (3LO: 3-legged OAuth (3LO) is the OAuth 2.0 Authorization Code flow where a user explicitly authorizes an application to access their data on a third-party service, requiring user interaction to complete the authorization.Learn more) have associations with third-party systems. After copying a 3LO Credential Provider, you must reauthorize it with the third-party system before you can use it.

Client Workloads must have unique client identification values within a Resource Set. If the target Resource Set already has a Client Workload with the same client identification type and value, that Client Workload won’t copy.

After copying components to a target Resource Set, you are responsible for:

  • Modifying target-specific attributes as needed
  • Authorizing any 3LO Credential Providers
  • Binding components to Aembit Edge deployments
  • Managing the new deployment lifecycle