Resource Access Management

Amorphic CICD can manage resource-level access (sharing) in the same deployment flow as create and update. You declare who can access a resource—by user or by tag—under owner, editor, and read-only buckets, optionally with additional metadata for grant requests.

This page describes how to model sharing in JSON, how centralized access-management files combine with per-resource definitions, and when CICD grants or revokes access during deployment.

Related topics

• Repository layout including access-management: Repository organization
• !DependsOn, !Environ, and other substitutions inside Share: Intrinsic functions

Configuration entry points

You can configure sharing in two ways:

1. Share on the resource — Add a Share object next to Type and Properties in the resource JSON (see Resource definition). This is the most explicit option and is versioned with the resource.

2. Centralized access-management files — Put one or more JSON files in a dedicated directory and pass that path to ResourceManager as access_management_dir. Each file maps logical resource IDs (the same keys used in your resource definitions) to a share configuration object.

The effective rules are simple:

• If a resource definition already includes Share, that definition is used. Matching entries in access-management files are ignored for that resource.
• If a resource has no Share in its definition, CICD can inject sharing from the merged access-management files.

An empty Share object ("Share": {}) blocks inheritance from access-management and signals that you want no sharing from centralized files for that resource.

Centralized access-management layout

Pass the directory that contains your sharing JSON files as the second argument to ResourceManager:

rm = ResourceManager(
    "./resources",
    access_management_dir="./access-management/dev",
    amorphic_auth_token=AMORPHIC_AUTH_TOKEN,
    amorphic_base_url=AMORPHIC_BASE_URL,
    amorphic_role_id=AMORPHIC_ROLE_ID,
)

Typical repository layout (alongside cicd.py and resources):

.
├── cicd.py
├── access-management
│   └── dev
│       ├── team-a-shares.json
│       └── team-b-shares.json
└── resources
    └── ...

Loading behavior:

• Every *.json file directly inside access_management_dir is loaded and validated against the access-management schema.
• Objects are merged in filesystem listing order. If the same logical resource ID appears in more than one file, the last loaded definition wins—avoid duplicate keys across files unless you rely on a single ordering strategy.
• The directory must exist and contain at least one JSON file; otherwise validation fails at load time.
• Entries whose keys do not match a resource in the current deployment fail the run (fix the name or remove the entry).

Share configuration shape

The share object uses access buckets that match how Amorphic models grants:

Bucket	Purpose
owner	Owner-level access
editor	Editor-level access
read-only	Read-only access

Each bucket may include:

• Users — Array of user IDs. User grants are represented with the appropriate access level.
• Tags — Tags as either TagKey#TagValue strings or objects with TagKey and TagValue. Use Users for user-based sharing; do not encode users as user#... tags.

Optional AdditionalMetadata can be passed while granting the share requests. Supported boolean flags:

Flag	What does it do
TagAwsResources	When true, treat the grant as tied to backend/AWS tag associations and stricter dataset file–level checks where applicable; when false, file-level enforcement may be relaxed for that path.
IsDomainAccessRequested	For dataset shares: require the grantor (not the grantee tag) to have owner/editor on the dataset’s domain (and tenant if applicable) instead of requiring the grantee tag to already have domain access.
IsTenantAccessRequested	For domain (and tenant-scoped) shares: require the grantor to have owner/editor on the tenant when validating tenant-scoped domain grants.
IsDatasetLevelAccessProvided	For domain shares: mark the grant as dataset-level access (DLA) semantics in ACL metadata so duplicate or conflicting grants are detected consistently.
BypassKBSourceACL	For knowledge base sharing flows: skip normal Knowledge Base source ACL checks when applying the grant.
IsGuardrailRequired	For knowledge base shares: when true, also grant access to each guard rail linked on the KB; when false, skip automatic guard rail propagation.

Example — inline Share on a resource:

{
  "rMyDataset": {
    "Type": "Dataset",
    "Properties": { "...": "..." },
    "Share": {
      "editor": {
        "Users": ["analyst-user-id"],
        "Tags": ["team#analytics"]
      },
      "read-only": {
        "Tags": [
          {
            "TagKey": { "!DependsOn": "rGovernanceTag.TagKey" },
            "TagValue": { "!DependsOn": "rGovernanceTag.TagValue" }
          }
        ]
      },
      "AdditionalMetadata": {
        "IsDomainAccessRequested": true
      }
    }
  }
}

Example — centralized file access-management/dev/datasets.json:

{
  "rSharedDataset": {
    "owner": {
      "Users": ["owner-user-id"]
    },
    "read-only": {
      "Tags": ["audience#readers"]
    }
  }
}

Keys must be logical resource IDs (^[a-zA-Z0-9_]+$) matching your deployment definitions.

Substitution and dependencies

Share supports the same intrinsic functions as Properties (for example !DependsOn, !Environ, !Sub). That lets sharing reference metadata from other resources or environment-specific values. Dependencies are resolved when properties are parsed, so ensure dependent resources are ordered correctly in the deployment graph.

See Intrinsic functions for syntax and constraints (one intrinsic per property, environment variables must be set, and so on).

How sharing runs in the deployment lifecycle

1. Create — The resource is created first; sharing is applied after it exists in Amorphic (so IDs are known). If the sharing step fails, the deployment fails; you can fix the config and run again.

2. Update — After the resource is updated as usual, CICD grants and revokes access so Amorphic matches your Share (and any AdditionalMetadata you set).

3. Share-only changes — Sharing is separate from the resource property hash, so you can change only Share or access-management and CICD will still apply those access changes even when other properties did not change.

4. Delete — When a resource is deleted, access cleanup is handled by Amorphic; CICD does not run a separate revoke step before delete.

State and deployment runs

CICD keeps share state in the deployment state file so it knows what access was applied last time. On the next run it grants new access and revokes access that is no longer in your definition, so the platform stays aligned with your JSON. If nothing changed, no extra sharing work is done. If you remove Share from a resource on an update, CICD revokes the access it had previously applied for that resource.

Supported resource types

Sharing is enabled only for resource types that expose the share API in Amorphic. Supported types include, among others: Dataset, Domain, Job, Dashboard, KnowledgeBase, Guardrail, Agent, Project, Datalab, Datasource, and Tag. If sharing is configured for a type that does not support it, the deployment fails rather than silently skipping sharing.

Limitations

• Several JSON files in one folder: Each key is a logical resource ID and maps to one whole Share object. If the same ID appears in more than one file, the last-loaded file wins for that resource—CICD does not merge owner from one file with editor from another.
• Inline Share vs access-management: If the resource JSON already has Share, access-management is not applied for that resource. There is no mixing of the two sources for the same resource.

Operational notes

• Declarative and version-controlled — Access rules live in JSON alongside infrastructure definitions.
• Centralized defaults — Use access-management files for org-wide patterns; override per resource with an explicit Share when needed.
• Unknown resource IDs in access-management files fail the run—every key must match a resource in that deployment.

For release-level notes on sharing capabilities, see Release notes.