A data source is a read-only lookup that pulls existing information from a platform into Terraform without creating a new resource. It is used to reference known objects by name, ID, or filter criteria, which simplifies automation but still depends on accurate provider schema and query behavior.
Expanded Definition
In Terraform, a data source is a read-only lookup that resolves existing infrastructure state at plan or apply time. It does not create, update, or destroy anything, which makes it useful for referencing objects that are already managed elsewhere. In practice, it sits between declarative intent and observed reality: the configuration asks, “what already exists?” and the provider returns a matching object by name, ID, tags, or other filter criteria.
That distinction matters because a data source depends on provider schema, API permissions, and query semantics. If any of those shift, the lookup can return a different object than intended or fail entirely. Definitions vary across vendors, but the core pattern is consistent: a data source is a read operation, not a managed resource. For identity and access workflows, it is often used to discover accounts, groups, secrets metadata, or network objects before attaching policy. For a broader control perspective, this aligns with the observation that visibility and accurate reference data are prerequisites for reliable automation, as reflected in the NIST Cybersecurity Framework 2.0 and NHIMG’s guidance on visibility in the Ultimate Guide to NHIs.
The most common misapplication is treating a data source as a stable source of truth when the underlying object can change, disappear, or be duplicated between plan and apply.
Examples and Use Cases
Implementing data sources rigorously often introduces dependency risk, because each lookup becomes a live assumption about provider state, requiring organisations to weigh automation simplicity against query fragility.
- Looking up an existing cloud security group by tag so a new workload can attach to the correct network controls without recreating the group.
- Referencing a pre-existing IAM role or service account to grant a Terraform-managed application access without changing the identity object itself.
- Pulling an existing certificate or secret reference into a deployment pipeline so policy can be attached to the correct endpoint metadata rather than hard-coded values.
- Querying an existing DNS zone or load balancer to avoid duplicate infrastructure and to keep ownership boundaries clear between teams.
- Resolving a known identity object before federation logic runs, which is common in NHI workflows where the system must bind to an existing machine principal rather than create a new one.
For identity-heavy estates, this pattern becomes especially important when Terraform must integrate with externally managed service accounts or secrets platforms. NHIMG has shown that only 5.7% of organisations have full visibility into their service accounts, which makes accurate lookups even more valuable and more brittle when records are incomplete. That is why practitioners often compare provider reads against the authoritative object inventory described in the Ultimate Guide to NHIs, while using discovery guidance from SPIFFE and general identity assurance concepts in the NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
Data sources are a security concern because they can silently amplify trust in stale or misnamed objects. In NHI environments, a lookup that resolves the wrong service account, token issuer, or secret-bearing resource can grant access to the wrong workload or break a rotation workflow. That risk is especially acute when teams assume a data source is authoritative, even though it only reflects what the provider returns at that moment.
This is one reason NHIMG emphasises visibility and lifecycle discipline. The Ultimate Guide to NHIs reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which underscores how quickly a small lookup error can become an exposure issue. When data sources are used to support secret rotation, offboarding, or policy assignment, they should be validated against logging, drift detection, and explicit ownership boundaries. The same caution applies to platform queries that underpin automation, a principle echoed in CISA Zero Trust Maturity Model guidance on verifying identity and access assumptions before granting action.
Organisations typically encounter the consequence only after a pipeline binds to the wrong existing object, at which point data source behavior becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Read-only lookups can hide stale or misbound NHI references. |
| NIST CSF 2.0 | ID.AM-1 | Data sources depend on accurate asset and identity inventories. |
| NIST Zero Trust (SP 800-207) | AC-4 | Lookup-based automation must not bypass least-privilege and policy enforcement. |
| NIST SP 800-63 | IAL2 | Referenced identities need sufficient assurance before automation consumes them. |
| CSA MAESTRO | Agentic and automated workflows rely on dependable discovery of approved resources. |
Validate every referenced NHI object and fail closed when lookups return ambiguous or unexpected results.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
