quiltx

Quilt extension toolkit for working with Quilt catalogs.

Quick start

# See available tools
uvx quiltx

# Sign in to a catalog: mints a qk_... API key from your username/password,
# stores it in your system keyring, and sets it as the default catalog.
uvx quiltx catalog login --catalog open.quiltdata.com --username you@example.com
uvx quiltx catalog default open.quiltdata.com

# Get help for any tool
uvx quiltx <tool> --help

quiltx catalog login accepts either --username with a password supplied by an interactive prompt, --password-stdin, QUILTX_PASSWORD, or the legacy --password flag (admin catalogs), or --api-key qk_... (paste an existing key, or the only path for SSO-only catalogs — see below). Both DNS names (open.quiltdata.com) and full URLs (https://open.quiltdata.com/) are accepted as --catalog arguments and normalized to the bare DNS.

For CI, use --no-store to avoid keyring and plaintext-file persistence. The command prints only the minted key to stdout, so it can be captured for reuse:

export QUILTX_API_KEY="$(
  printf '%s\n' "$CATALOG_PASSWORD" |
    uvx quiltx catalog login --catalog open.quiltdata.com \
      --username you@example.com --password-stdin --no-store
)"

Alternatively, set QUILTX_PASSWORD and omit --password-stdin. Status messages go to stderr; the API key is the only stdout output in no-store mode.

Tools

• bucket — Register cross-account S3 buckets with Quilt (policy, SNS, notifications)
• catalog — Manage Quilt catalogs:
  • catalog login — Mint and store a qk_... API key from username/password (or paste one with --api-key)
  • catalog default — Read, set, or clear the default catalog (auto-runs login when the DNS has no stored key)
  • catalog list — List catalogs with stored credentials
  • catalog forget — Delete the keyring entry for a catalog
  • catalog acl — Declarative access-control-list (ACL) reconciliation from YAML
  • catalog stack — Discover the Quilt CloudFormation stack and cache metadata
• ecs — ECS task tools:
  • ecs logs — Display/tail catalog CloudWatch logs and update ECS log level
  • ecs shell — Interactive shell access to running ECS tasks via Session Manager
  • ecs status — Show or wait for ECS service rollout status
  • ecs run-migration — Re-run the registry migration task for a stack

Python API

See README_DEV.md for programmatic usage of ECS, ACL, config, and stack APIs.

Bucket registration

quiltx bucket add BUCKET defaults to bucket-owner mode: it uses your local AWS profile to probe the bucket, update the bucket policy, configure SNS, and wire S3 notifications before registering the bucket with the catalog.

When the bucket owner and catalog operator are different people, split setup into two credential-isolated steps. The bucket owner needs AWS credentials only (no catalog configuration or API key):

uvx quiltx bucket prepare my-bucket \
  --control-account-id 123456789012 \
  --json --yes > bucket-handoff.json

Grants accumulate. Preparing a bucket adds the principals you name and keeps the ones already in the policy, so a bucket registered in two catalogs does not lose one stack's access when it is prepared for the other. --dry-run and the confirmation prompt list the principals already granted, added, and removed, so nothing changes silently. Withdraw access deliberately:

uvx quiltx bucket revoke my-bucket --control-account-id 123456789012 --dry-run

revoke rewrites only the two cross-account Quilt statements; bucket notifications and the SNS topic stay in place because other stacks may still consume them. Removing the last Quilt principal drops the Quilt statement and keeps the rest of the bucket policy; only when that statement was the sole one in the document is the policy deleted, since S3 rejects an empty statement list. --dry-run says so explicitly when it applies.

Use repeatable --principal arn:aws:iam::123456789012:role/... options to name specific Quilt roles rather than the control-account root. Account root and IAM user ARNs are accepted too, so a shared bucket can name each consuming stack's control account.

Because grants accumulate, naming a narrower set does not withdraw a wider one. Preparing with --principal <role> on a bucket that already grants arn:aws:iam::123456789012:root leaves that root grant in place; it is listed under Kept in the output rather than dropped. Narrowing is two deliberate steps:

uvx quiltx bucket prepare my-bucket --principal arn:aws:iam::123456789012:role/SomeRole
uvx quiltx bucket revoke my-bucket --control-account-id 123456789012

If you don't know the control account ID, pass --catalog example.quiltdata.com instead: any logged-in catalog user (no admin role needed) can derive it from cached stack metadata or from credentials the catalog's own registry mints. If the catalog will not mint credentials, the command fails and asks for an explicit --control-account-id or --principal rather than guessing from your local AWS profile. --dry-run prints the exact final S3 policy, SNS policy, and notification configuration without any writes. Preparation preserves unrelated policies and compatible notifications, and stops with actionable details when an object-event notification overlaps. The JSON handoff contains only the bucket, region, owning account, effective principals, and SNS topic ARN; it contains no credentials.

The catalog operator then needs catalog-admin credentials only, not access to the bucket owner's AWS account:

uvx quiltx bucket add my-bucket --catalog example.quiltdata.com --no-preflight

Use --no-preflight when the catalog stack can already access the bucket but your local AWS identity cannot or should not modify it, such as public AWS Open Data buckets or buckets already plumbed by Quilt infrastructure:

uvx quiltx bucket add igvf-public --catalog example.quiltdata.com --no-preflight
uvx quiltx catalog acl acl.yml --catalog example.quiltdata.com --no-preflight --yes

--no-preflight submits the GraphQL registration directly, lets the stack probe with its IAM, and skips local S3/SNS setup. It still verifies afterwards — the cross-account path is the one most likely to be misconfigured — so pass --no-test to opt out. Set QUILTX_NO_PREFLIGHT=1 to use the same mode for scripted runs.

Verifying access

quiltx bucket test BUCKET reports three independent checks:

1. Registration — the bucket has a catalog row.
2. Live access — the catalog re-validates the bucket server-side with the stack's own service identity, so an empty bucket passes and revoked access fails even when stale search-index entries remain. Failures name the failed capability, the Quilt control account, and the stack principal. The probe resubmits the bucket's existing catalog configuration unchanged to trigger that re-validation; set QUILTX_NO_LIVE_PROBE=1 to skip it where no bucket mutation is acceptable.
3. Index wiring — the search index has entries, which proves SNS to SQS delivery is live. Once live access is verified, an empty index is a warning rather than a failure, since indexing lags registration and empty buckets never index. Pass --require-index to make it fatal.

Before a bucket is registered, check a cross-account grant straight from the handoff with control-account credentials:

uvx quiltx bucket test my-bucket --catalog example.quiltdata.com \
  --pre-registration --profile control-account

That mode treats "not registered" as expected and checks what is checkable: the bucket is reachable, GetBucketNotification is readable, and the SNS topic policy grants Subscribe/GetTopicAttributes. Topic policies are read conservatively — an explicit Deny counts, and a condition-bearing Allow is reported as conditional rather than assumed to apply. It reports the principal that ran the checks and fails loudly when that principal is not in the catalog's control account — which is how a grant issued to the wrong account surfaces at handoff time instead of as an opaque AccessDenied later.

Persistent install (optional)

uv tool install -U quiltx
# Now use without the uvx prefix:
quiltx --list

Catalog ACL

quiltx catalog acl declaratively manages a Quilt stack's access control lists (ACLs) from one YAML file with top-level policies:, roles:, and optional users: blocks. Policy audiences synthesize cumulative managed roles; reusable policies can opt out with config.synthesize: false; and static roles compose named policies, optional inline bucket grants, and optional SSO selectors. Instead of clicking through the catalog admin UI, you define the desired state in version-controlled YAML and let the tool reconcile it against the server.

YAML example

# Access control lists for a Quilt stack
policies:
  public:
    sso.groups: [Everyone]
    buckets.read: [quilt-example]
    config.default_role: true
  internal:
    sso.groups: [Employees]
    buckets.read_write: [quilt-bake, quilt-dev]
    buckets.read: [quilt-leadership]
    config.is_admin: true

roles:
  exec:
    sso.groups: [Executives]
    config.policies: [public, internal]
    buckets.read_write: [quilt-leadership]
    config.is_admin: true

Policy order matters. In this example public synthesizes the public role, and internal synthesizes internal_public, which cumulatively includes both public and internal. Reordering the policies changes those synthesized role names and who receives which cumulative grants.

Policy config.is_admin also composes cumulatively for synthesized roles. Unset is neutral, true grants admin, and an explicit false vetoes any prior true in that generated role and is reported as a warning.

config.default_role: true reconciles the settings-level role assigned to new password signups. A selector-less static role may be the default; when the file also generates SSO configuration, the same role is used as its fallback default. Files with any sso.<claim> selectors must declare exactly one default role.

Built-in unmanaged roles

Every catalog ships with unmanaged roles (IAM-role-backed, created by the stack rather than the registry). config.unmanaged: true references one by name:

roles:
  ReadQuiltBucket:
    config.unmanaged: true
  ReadWriteQuiltBucket:
    config.unmanaged: true
    sso.groups: [Employees]

Referenced this way, a role stays addressable from users:, sso.<claim> selectors, and config.default_role while quiltx never creates, updates, or deletes it. Because their bucket grants live in IAM rather than the registry, unmanaged roles cannot carry config.policies or buckets.* grants. The two QuiltStack built-ins are the exception for registration references: ReadQuiltBucket.buckets.read and ReadWriteQuiltBucket.buckets.read_write may list buckets that the ACL should register, but those fields never modify the roles' IAM permissions. Other bucket fields and bucket fields on custom unmanaged roles remain invalid.

--yaml always emits entries for the unmanaged roles it finds, even when no user or selector currently references them. Registered buckets not already represented by managed permissions are listed on both built-in roles, so a capture can register them when replayed without duplicating explicit grants.

Downgrade warnings

Both export and reconciliation compare each existing user's effective access (role, extra roles, admin, and composed bucket permissions) before and after.

--dry-run prints a per-user block for anything that would reduce access, including reductions caused indirectly by a narrowed policy, a deleted role, a replaced SSO mapping, or a changed default role:

!! DOWNGRADE: user alice would lose access
    primary role: Analysts -> Default
    extra roles: Leads -> (none)
    admin: true -> false
    lost permissions: READ_WRITE:quilt-bake
    cause: role 'Analysts' would be deleted
    cause: falls back to the default role 'Default'

--yaml re-parses its own output and diffs it against the state it captured. If replaying the file would not preserve someone's access, the affected users are listed in the generated # not captured: notes and repeated on stderr, so the warning is still visible when stdout is redirected to a file.

Limitations: role renames and reassignments that preserve permissions are not flagged, and neither are increases. Permissions granted by an unmanaged role are invisible to the registry, so losing one is reported as undetermined rather than quantified. SSO mapping and default-role effects are evaluated for SSO-only users, whose roles are recomputed at each login; a password user keeps their stored assignment until something explicitly changes it. The registry does not expose a user's IdP claims, so when a role survives under a different selector the outcome is reported as undetermined rather than resolved.

Usage

With no config file, the command reports the complete server ACL state, including users and their active and extra role assignments. Pass --json for a complete machine-readable reporting export, or --yaml for a replayable ACL config that can be saved and passed back to catalog acl --dry-run. Read the stderr output of --yaml before replaying: that is where downgrade risks are reported.

# Show current server ACL state
uvx quiltx catalog acl

# Export reporting data as JSON
uvx quiltx catalog acl --json

# Capture replayable ACL YAML
uvx quiltx catalog acl --yaml > default-acl.yaml
uvx quiltx catalog acl default-acl.yaml --dry-run

# Preview changes from a hand-authored config
uvx quiltx catalog acl config.yml --dry-run

# Preview with full detail
uvx quiltx catalog acl config.yml --dry-run --verbose

# Apply changes (with confirmation prompt)
uvx quiltx catalog acl config.yml

# Apply without prompting
uvx quiltx catalog acl config.yml --yes

SSO-only catalogs

quiltx catalog login --username --password only works on catalogs that accept username/password at /api/login. SSO-only catalogs reject U/P with the catalog's own error (e.g. "SSO is required"). In that case:

1. Open the catalog UI in your browser and mint an API key from the account/keys page.
2. Paste it with --api-key:

uvx quiltx catalog login --catalog quilt.example.com --api-key qk_...

Corporate TLS proxies

If catalog requests fail with CERTIFICATE_VERIFY_FAILED (common on networks with TLS-inspection proxies or self-signed catalog certs), point Python at your organization's CA bundle by exporting one of the standard environment variables before running quiltx:

export SSL_CERT_FILE=/path/to/corp-root.pem
# or: export REQUESTS_CA_BUNDLE=/path/to/corp-root.pem

uvx quiltx catalog login --catalog quilt.example.com --username you@example.com

Local catalog testing (--insecure)

When developing against a local catalog build, pass --insecure to allow plain http://localhost:

uvx quiltx catalog login --catalog localhost --insecure --username admin
uvx quiltx catalog acl --catalog localhost --insecure config.yml

--insecure is only accepted when the catalog DNS resolves to localhost; any other target is rejected. The flag is never persisted — it must be passed on every command that hits the catalog.

ECS

# Open an interactive shell inside the registry service task
uvx quiltx ecs shell

# Display and tail CloudWatch logs
uvx quiltx ecs logs

# Dry-run setting the registry container log level
uvx quiltx ecs logs --set-level DEBUG

# Apply a log-level change and wait for service stability
uvx quiltx ecs logs --set-level DEBUG --yes

# Show ECS service rollout status
uvx quiltx ecs status

# Wait for ECS service rollout stability
uvx quiltx ecs status --wait

# Dry-run the registry migration relaunch using cached stack metadata
uvx quiltx ecs run-migration --dry-run

# Start the migration task and wait for completion
uvx quiltx ecs run-migration

License

MIT