☁️ Azure Data Factory Linked Service — Azure Blob Storage Terraform Module

A Data Factory's stored definition of how to reach a Blob Storage account, targeting hashicorp/azurerm ~> 4.0.

• 🗄️ Creates one azurerm_data_factory_linked_service_azure_blob_storage — the definition datasets and copy activities use to reach a storage account.
• 🔢 Four mutually exclusive connection forms, and they are not equivalent. Exactly one of connection_string, connection_string_insecure, sas_uri and service_endpoint is required — none is as invalid as two.
• 🔴 connection_string_insecure is worse than its name suggests, in two compounding ways. Azure stores it unencrypted, so it is readable in the Azure portal; and it is the only one of the four the provider does not mark sensitive, so it prints in clear text in plan output too.
• ✅ One combination carries no secret at all: service_endpoint plus use_managed_identity. The module reports whether you achieved it.
• 🧾 It creates a definition, not a connection. Nothing here verifies the account, the credential, or the endpoint.

💡 Why it matters: on this resource the choice of connection form is a security decision before it is a connectivity one, and three of the four put a credential into Terraform state.

If this module saved you time:

• ⭐ Star the repository — it is the cheapest signal that this work is worth continuing.
• 💼 Connect on LinkedIn: linkedin.com/in/microsoftexpert
• ☕ Buy me a coffee: buymeacoffee.com/microsoftexpert

flowchart TB
  RG["terraform-azurerm-resource-group"]
  ADF["terraform-azurerm-data-factory"]
  ST["terraform-azurerm-storage-account, never verified by Terraform"]
  THIS["terraform-azurerm-data-factory-linked-service-azure-blob-storage"]
  KVLS["terraform-azurerm-data-factory-linked-service-key-vault, referenced BY NAME"]
  GRANT["terraform-azurerm-role-assignments, Storage Blob Data Reader for the factory identity"]
  IR["an integration runtime, needed for a private storage account"]
  DS["a dataset, then a copy activity"]

  RG -->|"name"| ADF
  ADF -->|"id"| THIS
  ST -->|"the blob service endpoint, the ONLY credential free form"| THIS
  KVLS -->|"name, into sas_token or service_principal key references"| THIS
  ADF -->|"identity_principal_id"| GRANT
  GRANT -->|"data plane access, without which managed identity fails at first use"| ST
  IR -->|"name, into integration_runtime_name"| THIS
  THIS -->|"name, referenced BY NAME and never by id"| DS

  classDef this fill:#0078D4,stroke:#004578,color:#ffffff,stroke-width:2px
  classDef keystone fill:#004578,stroke:#00243d,color:#ffffff,stroke-width:2px
  classDef sibling fill:#eef3f8,stroke:#b9c8d8,color:#1b2733
  class THIS this
  class ADF keystone
  class RG,ST,KVLS,GRANT,IR,DS sibling

Two edges carry the point: the service endpoint comes straight from the storage account module and is the only credential-free way in; and the role assignment is what makes managed identity actually work — the linked service applies perfectly without it.

flowchart TB
  subgraph INPUTS["Inputs"]
    ID["name and data_factory_id, THE ONLY TWO FORCE-NEW FIELDS"]
    FORM["EXACTLY ONE of connection_string, connection_string_insecure, sas_uri, service_endpoint"]
    KVREF["sas_token_linked_key_vault_key, service_principal_linked_key_vault_key"]
    AUTH["use_managed_identity OR service_principal_id plus key, plus tenant_id"]
    META["storage_kind, integration_runtime_name, parameters, annotations, additional_properties"]
  end

  THIS["azurerm_data_factory_linked_service_azure_blob_storage.this"]

  subgraph OUTPUTS["Outputs"]
    PORTAL["connection_is_readable_in_the_azure_portal, true only for the insecure form"]
    UNMARKED["the insecure form is the ONLY one the provider leaves unmarked"]
    NOSEC["carries_no_secret, true only for service_endpoint plus managed identity"]
    MODE["connection_form and authentication_mode, both known at plan"]
    SPGAP["a_service_principal_id_was_supplied_with_no_key"]
    DEPR["the deprecated sas token block is deliberately not exposed"]
  end

  ID --> THIS
  FORM --> THIS
  KVREF --> THIS
  AUTH --> THIS
  META --> THIS

  FORM --> PORTAL
  FORM --> UNMARKED
  FORM --> NOSEC
  AUTH --> NOSEC
  FORM --> MODE
  AUTH --> MODE
  AUTH --> SPGAP
  KVREF --> SPGAP
  KVREF --> DEPR

  classDef this fill:#0078D4,stroke:#004578,color:#ffffff,stroke-width:2px
  classDef sibling fill:#eef3f8,stroke:#b9c8d8,color:#1b2733
  class THIS this
  class ID,FORM,KVREF,AUTH,META,PORTAL,UNMARKED,NOSEC,MODE,SPGAP,DEPR sibling

Schema notes that bite — verified against the live provider source:

• 🔴 connection_string_insecure is stored unencrypted by Azure and is readable in the portal, where connection_string shows as ******. Both travel over HTTPS; transport is not the difference.
• 🔴 It is also the only one of the four connection forms the provider does not mark sensitive, so it prints in clear text in plan and apply output. connection_string, sas_uri and service_endpoint are all marked.
• 🔴 service_principal_key carries no sensitive flag either.
• 🔴 EXACTLY ONE of the four connection forms is required — supplying none is as invalid as supplying two, and the rule is a schema rule, so it refuses a bad configuration at terraform plan, offline.
• ⚠️ use_managed_identity conflicts with service_principal_id, and the provider enforces it.
• ⚠️ service_principal_id and service_principal_key are NOT paired here — unlike the Azure SQL Database linked service, where the provider requires each with the other. Either may be supplied alone.
• ⚠️ A deprecated second spelling of the SAS-token block exists on this provider line. key_vault_sas_token conflicts with sas_token_linked_key_vault_key and is removed in the next major version. This module exposes only the surviving one.
• ⚠️ storage_kind is a closed, case-sensitive set of four — and it is a declaration, not a setting.
• ⚠️ The name validator is nearly inert — anchored end to end, it refuses only a value composed entirely of the punctuation its message lists. Shared by the whole linked-service and dataset family.
• ⚠️ Only name and data_factory_id are force-new. No location, no tags.
• ℹ️ The Resource ID's segment is lower-case linkedservices.
• ℹ️ No CustomizeDiff, so every provider check here is a schema rule and refuses a bad configuration at terraform plan, offline and without credentials.
• ℹ️ The requires-import error names this resource correctly.

Planning this resource is not credential access — nothing is read back as a secret, and this module emits none.

⚠️ Separately, whatever identity is chosen needs a DATA-PLANE role on the storage account — Storage Blob Data Reader or Storage Blob Data Contributor. Control-plane Contributor is not sufficient to read blobs. Nothing in this module creates that grant, and the linked service applies perfectly without it.

⚠️ A connection string or SAS URI is not scoped by any Azure role. It grants whatever it was minted with, to whoever holds it. Whoever can read the state file holds it.

• An existing Data Factory.
• An existing storage account, reachable from whichever integration runtime is used.
• For managed identity: a system-assigned identity on the factory, granted a data-plane blob role.
• For the Key Vault forms: an existing Key Vault linked service in the same factory, plus the secret.
• For an account behind a private endpoint or a network rule: a self-hosted or managed-virtual-network integration runtime, named in integration_runtime_name.

terraform-azurerm-data-factory-linked-service-azure-blob-storage/
├── providers.tf    # required_version + the pinned azurerm; no provider block
├── variables.tf    # 19 inputs, 27 validations, 5 of them marked sensitive
├── main.tf         # the keystone, 3 dynamic blocks, and the derived facts
├── outputs.tf      # 47 outputs; none is sensitive, because none carries a secret
├── README.md       # this file
├── SCOPE.md        # the cross-module contract
├── LICENSE         # MIT
└── .gitignore

module "blob_link" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-data-factory-linked-service-azure-blob-storage.git?ref=v1.0.0"

  name            = "ls-blob-corp"
  data_factory_id = module.data_factory.id

  # The credential-free form: an endpoint, and an identity.
  service_endpoint     = module.storage.primary_blob_endpoint
  use_managed_identity = true
}

The caller configures the provider, its authentication, and the mandatory features {} block:

provider "azurerm" {
  features {}
}

✅ That Quick Start is the one combination on this resource that puts no credential into the configuration or into Terraform state. module.blob_link.carries_no_secret reports true for it.

Consumes

Emits

module "blob" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-data-factory-linked-service-azure-blob-storage.git?ref=v1.0.0"

  name            = "ls-blob-corp"
  data_factory_id = module.data_factory.id

  service_endpoint     = module.storage.primary_blob_endpoint
  use_managed_identity = true
}

# Both of these hold the same string. They are not equally exposed.
connection_string          = var.blob_connection_string # Azure stores it ENCRYPTED; portal shows ******
connection_string_insecure = var.blob_connection_string # Azure stores it PLAIN;    portal shows the value

# Refused at `terraform plan`, offline and without credentials:
#   (none of the four supplied)                -> "EXACTLY ONE of connection_string, ..."
#   connection_string + service_endpoint       -> "EXACTLY ONE of connection_string, ..."
#   sas_uri + service_endpoint                 -> "EXACTLY ONE of connection_string, ..."

service_endpoint = module.storage.primary_blob_endpoint # exactly one

sas_uri = "https://stcorp.blob.core.windows.net/"

sas_token_linked_key_vault_key = {
  linked_service_name = "ls-keyvault" # the Key Vault linked service, BY NAME -- not a Resource ID
  secret_name         = "blob-sas-token"
}

# The provider still accepts this on the 4.x line:
#   key_vault_sas_token { ... }
# It conflicts with sas_token_linked_key_vault_key and is REMOVED in the next major version.
# This module exposes only the surviving spelling:

sas_token_linked_key_vault_key = {
  linked_service_name = "ls-keyvault"
  secret_name         = "blob-sas-token"
}

service_endpoint     = module.storage.primary_blob_endpoint
service_principal_id = "11111111-2222-3333-4444-555555555555" # the APPLICATION (client) ID
tenant_id            = "contoso.onmicrosoft.com"

service_principal_linked_key_vault_key = {
  linked_service_name = "ls-keyvault"
  secret_name         = "blob-sp-key"
}

service_endpoint     = module.storage.primary_blob_endpoint
service_principal_id = "11111111-2222-3333-4444-555555555555"
# ...and no key of any kind. ACCEPTED.

# Refused at `terraform plan`, offline and without credentials:
#   use_managed_identity = true
#   service_principal_id = "1111...."
#     -> "service_principal_id CONFLICTS WITH use_managed_identity"

use_managed_identity = true # choose one

storage_kind = "StorageV2" # Storage | StorageV2 | BlobStorage | BlockBlobStorage, CASE-SENSITIVE

service_endpoint         = module.storage.primary_blob_endpoint
use_managed_identity     = true
integration_runtime_name = "ir-vnet" # a NAME, from a managed-vnet or self-hosted runtime module

name = "ls-blob-corp"  # accepted, despite '-' being in the "not allowed" list
name = "ls.blob/corp"  # also accepted, despite '.' and '/'
# name = "---"         # REFUSED -- the one shape the provider's validator actually catches
# name = ""            # refused BY THIS MODULE; the provider accepts it

annotations = ["owner:data-platform", "classification:internal"]

check "no_credential_in_state" {
  assert {
    condition     = module.blob.carries_no_secret
    error_message = "This linked service puts a credential into Terraform state; service_endpoint + managed identity would not."
  }
}

check "not_the_portal_readable_form" {
  assert {
    condition     = !module.blob.connection_is_readable_in_the_azure_portal
    error_message = "connection_string_insecure is stored unencrypted and is readable by anyone who can view the factory."
  }
}

check "the_principal_has_a_key" {
  assert {
    condition     = !module.blob.a_service_principal_id_was_supplied_with_no_key
    error_message = "A service principal ID was supplied with no key by any route; the provider does not enforce the pairing on this resource."
  }
}

module "resource_group" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-resource-group.git?ref=v1.0.0"

  name     = "rg-data-eastus"
  location = "eastus"
}

module "storage" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-storage-account.git?ref=v1.0.0"

  name                = "stcorpdataeastus"
  resource_group_name = module.resource_group.name
  location            = module.resource_group.location
}

module "data_factory" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-data-factory.git?ref=v1.0.0"

  name                   = "adf-corp-eastus"
  resource_group_name    = module.resource_group.name
  location               = module.resource_group.location
  public_network_enabled = false
}

# The blob linked service, carrying no credential at all.
module "blob" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-data-factory-linked-service-azure-blob-storage.git?ref=v1.0.0"

  name            = "ls-blob-corp"
  data_factory_id = module.data_factory.id
  description     = "Corporate data lake landing zone."

  service_endpoint     = module.storage.primary_blob_endpoint
  use_managed_identity = true
  storage_kind         = "StorageV2"

  annotations = ["owner:data-platform", "classification:internal"]
}

# Without this, the managed identity above authenticates as nobody.
module "blob_data_grant" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-role-assignments.git?ref=v1.0.0"

  scope = module.storage.id

  role_assignments = {
    factory_reads_blobs = {
      principal_id         = module.data_factory.identity_principal_id
      role_definition_name = "Storage Blob Data Reader"
      principal_type       = "ServicePrincipal"
    }
  }
}

check "the_composition_carries_no_secret" {
  assert {
    condition     = module.blob.carries_no_secret
    error_message = "This composition was written to hold no credential; something reintroduced one."
  }
}

output "blob_linked_service_name" {
  value = module.blob.name
}

Identity (both force-new): name, data_factory_id. Connection (exactly one): connection_string, connection_string_insecure, sas_uri, service_endpoint — all four marked sensitive by this module. Credential: sas_token_linked_key_vault_key, service_principal_linked_key_vault_key, use_managed_identity, service_principal_id, service_principal_key (sensitive), tenant_id. The account: storage_kind. Metadata: description, integration_runtime_name, parameters, annotations, additional_properties, timeouts.

There is no tags input — the resource exposes none, and annotations are not tags.

variable "name" { type = string }            # required, force-new
variable "data_factory_id" { type = string } # required, force-new

# EXACTLY ONE of the four below. All are sensitive in this module; the provider marks only three.
variable "connection_string" { type = string, default = null, sensitive = true }
variable "connection_string_insecure" { type = string, default = null, sensitive = true } # portal-readable
variable "sas_uri" { type = string, default = null, sensitive = true }
variable "service_endpoint" { type = string, default = null, sensitive = true }           # carries no credential

variable "sas_token_linked_key_vault_key" {   # REQUIRES sas_uri
  type = object({
    linked_service_name = string # a NAME, not a Resource ID
    secret_name         = string
  })
  default = null
}

variable "service_principal_linked_key_vault_key" {
  type = object({
    linked_service_name = string
    secret_name         = string
  })
  default = null
}

variable "use_managed_identity" { type = bool, default = false } # conflicts with service_principal_id
variable "service_principal_id" { type = string, default = null } # a UUID; the APPLICATION id
variable "service_principal_key" { type = string, default = null, sensitive = true }
variable "tenant_id" { type = string, default = null }            # a GUID or a tenant NAME
variable "storage_kind" { type = string, default = null }         # Storage|StorageV2|BlobStorage|BlockBlobStorage

variable "description" { type = string, default = null }
variable "integration_runtime_name" { type = string, default = null } # a NAME
variable "parameters" { type = map(string), default = {} }
variable "annotations" { type = list(string), default = [] }          # ORDERED; not tags
variable "additional_properties" { type = map(string), default = {} } # validated by nothing

variable "timeouts" {
  type = object({
    create = optional(string)
    read   = optional(string)
    update = optional(string)
    delete = optional(string)
  })
  default = null
}

The choice of connection form is a security decision. Four are offered, exactly one is required, and three of them put a credential into Terraform state. Only service_endpoint does not: it names the account and carries nothing else, so paired with an identity it is the one combination on this resource that holds no secret anywhere. carries_no_secret is true for exactly that combination and false for every other, including the near-misses — an endpoint without an identity, or an identity alongside a plaintext service principal key.

connection_string_insecure is worse than its name, and the two reasons compound. Azure stores it unencrypted within the payload, so it is readable in the Azure portal by anyone who can view the Data Factory — where the ordinary connection_string displays as ****** because Azure stores that one as a secure string. Both are sent over HTTPS, so transport is not the difference; visibility is. On top of that, it is the only one of the four the provider does not mark sensitive, so a configuration using the resource directly prints it in clear text in plan output, apply output and CI logs. This module marks its own input sensitive, which fixes the second problem and does nothing about the first — the portal visibility is a property of what Azure stores, and no Terraform setting reaches it.

The provider's pairing rules differ from its siblings', and the difference matters. Here use_managed_identity conflicts with service_principal_id, and that is enforced. But service_principal_id and service_principal_key are not required with each other — unlike the Azure SQL Database linked service, where the provider pairs them in both directions. So a principal ID with no key by any route is accepted, applies cleanly, and fails at first use. The module reports that case rather than refusing it, because the key may legitimately arrive through service_principal_linked_key_vault_key.

One block has two spellings and only one survives. The provider carries key_vault_sas_token alongside sas_token_linked_key_vault_key; they conflict with each other, the former is deprecated, and its own message says it is removed in the next major version. This module exposes only the survivor, so configuration written against it does not need rewriting later. That is a deliberate reduction of the provider's surface, and it is the kind that costs a caller nothing.

Nothing here is verified. Creating the linked service does not connect to the account, does not parse the connection string beyond non-emptiness, does not check that the SAS token is valid, and does not check that the identity can read a blob. A completely wrong linked service applies cleanly and fails when a dataset or copy activity first uses it. The most common instance is a managed identity with no data-plane role — control-plane Contributor on the storage account does not grant blob access, and nothing in the plan says so.

Two library rules shape this table. Secure-by-default cannot fully apply, because one of the four connection forms must be supplied and the safest cannot be a default — so the compensations are a Quick Start that uses the credential-free form, an output that says whether you achieved it, and an explicit statement of what sensitive does not do. And no validation {} refuses a value the provider accepts: the insecure form, a dangling service principal ID, and a mismatched storage_kind are all reported rather than refused.

terraform init -backend=false
terraform validate
terraform fmt -check

Pin the module at a tag — ?ref=v1.0.0 — never a branch. This module is plan-only; a human applies from CI.

🔒 Before any apply that carries a connection string or SAS URI, confirm where state is stored. An encrypted, access-controlled remote backend is the control that protects those values; sensitive = true is not — and service_endpoint with a managed identity removes the question entirely.

terraform validate covers every check the provider applies here — there is no CustomizeDiff.

Offline, without credentials, the module's proof harness confirms:

• the four-way connection rule refuses none of the four and every pair and triple tried, and accepts each of the four alone;
• 🔴 the sensitivity asymmetry is read from the binary schema, not asserted — connection_string, sas_uri and service_endpoint must be marked sensitive by the provider, and connection_string_insecure and service_principal_key must not be;
• 🔴 the deliberate omission is asserted in both directions — the deprecated key_vault_sas_token must exist in the provider schema and be absent from this module's variables;
• carries_no_secret has one fixture per branch, including all three near-misses;
• the service-principal pairing gap is exercised in each of its four states;
• sas_token_linked_key_vault_key without sas_uri is refused;
• all four storage_kind values are accepted and a lowercase one is refused;
• every name the provider's own message disowns is accepted, and only the all-punctuation shape refused;
• exactly five inputs are marked sensitive and no output is, checked per block with an anchored expression.

Only terraform plan and apply exercise the ARM call. Nothing at any stage verifies the account, the credential, the endpoint, or the data-plane grant.

id                                        = "/subscriptions/00000000-.../factories/adf-corp/linkedservices/ls-blob-corp"
name                                      = "ls-blob-corp"
data_factory_name                         = "adf-corp"
connection_form                           = "service_endpoint"
authentication_mode                       = "managed_identity"
carries_no_secret                         = true
secrets_were_supplied_in_plaintext        = false
connection_is_readable_in_the_azure_portal = false
uses_service_endpoint                     = true
a_service_principal_id_was_supplied_with_no_key = false
storage_kind                              = "StorageV2"
runs_on_the_factory_default_integration_runtime = true
force_new_fields                          = ["name", "data_factory_id"]

• azurerm_data_factory_linked_service_azure_blob_storage
• azurerm_data_factory_linked_service_key_vault — the linked service the Key Vault blocks reference
• Store credentials in Azure Key Vault — the pattern behind both Key Vault blocks
• Managed identity for Data Factory — the identity that needs the data-plane grant
• Copy and transform data in Azure Blob Storage — the connector this linked service configures
• Azure built-in roles for storage — Storage Blob Data Reader and friends
• SCOPE.md — this module's cross-module contract

💙 "Infrastructure as Code should be standardized, consistent, and secure."