StackScopes
Problem
Cloud infrastructure intelligence requires visibility into accounts, Regions, resources, policies, and relationships. The easiest implementation would request broad access and retain entire API responses. That approach creates unnecessary risk.
Read-only access reduces risk, but the label alone does not make a collection system secure. Metadata can reveal network design, role trust, endpoint names, ownership tags, and encryption configuration. A broad trust policy can allow the wrong principal to assume a role. Temporary credentials can leak through logs. One tenant’s graph can be exposed through an authorization or cache error.
Teams also need a clear boundary between understanding production and changing it. Discovery should not silently become standing remediation authority.
The challenge is to collect enough evidence for topology, simulation, and investigation while keeping trust, permissions, credentials, data, and revocation proportionate to that purpose.
What We Built
StackScopes uses a security-first read-only collection model for cloud discovery. Customers create a dedicated cross-account IAM role that trusts a specific StackScopes-controlled principal under reviewed conditions. StackScopes assumes that role to obtain short-lived STS credentials for bounded discovery jobs.
Each connection binds:
- StackScopes tenant
- Expected AWS account
- Role ARN
- Unique external ID
- Approved Regions
- Supported collection scope
- Policy version
- Connection state
After assumption, StackScopes verifies the resulting account identity before collection. Jobs call approved list, describe, and carefully reviewed get APIs needed for normalized resource and relationship evidence.
The model deliberately excludes secret values and workload payloads. A secret ARN, KMS key reference, rotation state, and policy can establish a dependency without retrieving the credential.
Discovery and remediation remain separate. Connecting an account for topology does not grant StackScopes unrestricted authority to modify resources.
How It Works
Establish customer-controlled trust
An authorized customer administrator reviews and creates the role. The trust policy identifies the intended provider principal and requires a unique external ID to reduce confused-deputy risk. An external ID complements precise trust and application authorization; it is not treated as a password or sole control.
Role templates are versioned. When supported scope changes, customers can inspect which permissions changed and why.
Assume and verify
A discovery job receives an internal connection reference, not arbitrary role details from an end user. The worker obtains short-lived credentials just in time, calls GetCallerIdentity, and verifies the expected account.
Credentials are kept out of logs, analytics, persistent queues, and support exports. Session duration is limited to operational need. Provider-side role assumption is restricted to approved workloads.
Collect least-privilege evidence
Permissions are derived from documented resource fields and workflows. Each supported service adapter identifies required actions, Regions, pagination, returned sensitivity, and relationship evidence.
Many list actions do not support resource-level ARN scoping. Where that limitation exists, StackScopes reduces access through the action set, account boundary, Region selection, and collection configuration rather than claiming impossible precision.
Optional sources, such as selected change history or runtime evidence, require separate understanding and authorization.
Normalize and minimize
The collector transforms approved fields into stable resource identity, configuration state, and relationship evidence. Unused raw content is discarded according to the data-handling design.
Tags are handled carefully because customers may place personal or sensitive content in them. Inclusion and masking policies can reduce exposure.
Isolate and audit
Tenant context travels through connection, job, credential retrieval, storage, graph query, cache, export, and audit. Server-side authorization, not interface filtering, enforces boundaries.
Audit events record connection changes, role assumption, scope, policy version, collection results, coverage gaps, sensitive evidence access, exports, and separately authorized remediation.
Revoke and remove
Customers can disconnect an account and remove the role trust. New jobs stop, active connection references are disabled, caches and stored topology follow the documented retention workflow, and audit history is handled under policy. Already issued STS sessions can remain valid until expiration, which is why short duration matters.
Output and Evidence
The collection model produces normalized topology plus a coverage record. Users can inspect:
- Connected account and Region scope
- Last successful collection
- Supported resource categories
- Denied or incomplete services
- Policy version
- Evidence source
- Resource and relationship freshness
- External or unresolved references
- Connection health
A denied API does not make resources appear absent. The previous known state can remain visible as stale, while the affected scope is marked incomplete.
Relationship evidence includes configuration field, source identifier, observation time, and confidence. IAM and network paths distinguish possible access from observed use.
The platform can explain that an application references a secret and that the secret uses a particular key without showing its value. It can show a cross-account policy path without importing unauthorized data from another tenant.
Partial collection and safe reconciliation
Cloud discovery is distributed and can fail in pieces. A service can throttle, a Region can be disabled, or an organization policy can deny one API while allowing others. StackScopes records completion by account, Region, and service category. A partial scan does not replace a previously complete baseline as though every unseen resource were deleted.
Successful scopes can advance while failed scopes retain their last known state and a stale marker. Deletion is inferred only from an authoritative complete listing or reliable lifecycle evidence. This behavior is important for both correctness and security: missing permission must not become a confident topology conclusion.
Collectors use bounded concurrency, pagination, retry backoff, and error classification. Access-denied, throttling, transient failure, and resource churn produce different statuses. The user can see which product findings rely on incomplete coverage.
Tenant-safe external references
A policy in one customer account may mention an ARN belonging to an unconnected account. StackScopes can represent that string as an unresolved external reference, but it must not use the identifier to retrieve or reveal another tenant’s graph. Cross-account resolution occurs only inside explicitly authorized tenant scope.
Why It Matters
Cloud teams need enough context to understand dependencies, but trust should be earned through bounded architecture. Customer-controlled role creation, temporary credentials, least-privilege evidence, data minimization, isolation, auditing, and revocation work together.
The separation from remediation is equally important. Teams can adopt StackScopes for discovery and analysis without enabling production actions. If controlled remediation is introduced, it can use a different role, narrower policy, explicit approval, target validation, and post-action verification.
Read-only design does not eliminate security responsibility. It creates a clearer, reviewable access boundary aligned with the product’s purpose.
Operational Guardrails
- A precise principal and external ID protect role trust.
- The assumed account is verified before collection.
- Credentials are temporary and handled in memory where practical.
- Secret values and workload payloads are not collected for topology.
- Permissions are versioned and tied to documented evidence.
- Partial coverage is visible.
- Tenant authorization applies at every data path.
- Support access is controlled and audited.
- Disconnect and role removal revoke future collection.
- Remediation uses a separate human-approved boundary.
FAQ
Does StackScopes require long-lived AWS access keys?
The recommended model uses a customer-created cross-account IAM role and temporary STS credentials, avoiding long-lived IAM user keys.
Does read-only mean the data is not sensitive?
No. Resource names, policies, routes, tags, and endpoint metadata can be sensitive. StackScopes applies minimization, encryption, authorization, retention, and auditing.
Why use an external ID?
It helps bind role assumption to the intended third-party connection and reduce confused-deputy risk. Precise principal trust and provider-side authorization remain necessary.
Can the discovery role remediate production?
No. Controlled remediation requires a separate, narrowly scoped execution role and explicit human approval.
Related StackScopes links
StackScopes keeps operational evidence, timestamps, assumptions, and confidence visible. Production-impacting recovery remains subject to policy and human approval.