The Azure Provider can be used to configure infrastructure in Azure Active Directory using the Microsoft Graph API. Documentation regarding the Data Sources and Resources supported by the Azure Active Directory Provider can be found in the navigation to the left.
Interested in the provider's latest features, or want to make sure you're up to date? Check out the changelog for version information and release notes.
If you're new to the AzureAD provider, check out our Learn tutorial, which guides practitioners through learning the Terraform configuration language and the AzureAD provider, with an example workflow for managing users and groups.
# Configure Terraform
terraform {
required_providers {
azuread = {
source = "hashicorp/azuread"
version = "~> 2.15.0"
}
}
}
# Configure the Azure Active Directory Provider
provider "azuread" {
tenant_id = "00000000-0000-0000-0000-000000000000"
}
# Retrieve domain information
data "azuread_domains" "example" {
only_initial = true
}
# Create an application
resource "azuread_application" "example" {
display_name = "ExampleApp"
}
# Create a service principal
resource "azuread_service_principal" "example" {
application_id = azuread_application.example.application_id
}
# Create a user
resource "azuread_user" "example" {
user_principal_name = "ExampleUser@${data.azuread_domains.example.domains.0.domain_name}"
display_name = "Example User"
password = "..."
}
Terraform supports a number of different methods for authenticating to Azure Active Directory:
We recommend using either a Service Principal or Managed Identity when running Terraform non-interactively (such as when running Terraform in a CI/CD pipeline), and authenticating using the Azure CLI when running Terraform locally.
Bugs and feature requests can be reported on the GitHub issues tracker. Please avoid "me too" or "+1" comments. Instead, use a thumbs up reaction on enhancement requests. Provider maintainers will often prioritise work based on the number of thumbs on an issue.
Community input is appreciated on outstanding issues! We love to hear what use cases you have for new features, and want to provide the best possible experience for you using the Azure Active Directory provider.
If you have a bug or feature request without an existing issue:
The provider maintainers will often use the assignee field on an issue to mark who is working on it.
If you have configuration questions, or general questions about using the provider, try checking out:
The following arguments are supported:
client_id
- (Optional) The Client ID which should be used when authenticating as a service principal. This can also be sourced from the ARM_CLIENT_ID
environment variable.client_id_file_path
(Optional) The path to a file containing the Client ID which should be used when authenticating as a service principal. This can also be sourced from the ARM_CLIENT_ID_FILE_PATH
environment variable.environment
- (Optional) The Cloud Environment which be used. Possible values are: global
(also public
), usgovernmentl4
(also usgovernment
), usgovernmentl5
(also dod
), germany
(also german
), and china
. Defaults to global
. This can also be sourced from the ARM_ENVIRONMENT
environment variable.metadata_host
- (Optional) The Hostname of the Azure Metadata Service (for example management.azure.com
), used to obtain the Cloud Environment when using a Custom Azure Environment. This can also be sourced from the ARM_METADATA_HOSTNAME
Environment Variable.tenant_id
- (Optional) The Tenant ID which should be used. This can also be sourced from the ARM_TENANT_ID
environment variable.When authenticating as a Service Principal using a Client Certificate, the following fields can be set:
client_certificate
- (Optional) A base64-encoded PKCS#12 bundle to be used as the client certificate for authentication. This can also be sourced from the ARM_CLIENT_CERTIFICATE
environment variable.client_certificate_password
- (Optional) The password for decrypting the client certificate bundle. This can also be sourced from the ARM_CLIENT_CERTIFICATE_PASSWORD
environment variable.client_certificate_path
- (Optional) The path to a PKCS#12 bundle (.pfx file) to be used as the client certificate for authentication. This can also be sourced from the ARM_CLIENT_CERTIFICATE_PATH
environment variable.More information on how to configure a Service Principal using a Client Certificate can be found in this guide.
When authenticating as a Service Principal using a Client Secret, the following fields can be set:
client_secret
- (Optional) The application password to be used when authenticating using a client secret. This can also be sourced from the ARM_CLIENT_SECRET
environment variable.client_secret_file_path
- (Optional) The path to a file containing the application password to be used when authenticating using a client secret. This can also be sourced from the ARM_CLIENT_SECRET_FILE_PATH
environment variable.
More information on how to configure a Service Principal using a Client Secret can be found in this guide.When authenticating as a Service Principal using Open ID Connect, the following fields can be set:
oidc_request_token
- (Optional) The bearer token for the request to the OIDC provider. This can also be sourced from the ARM_OIDC_REQUEST_TOKEN
or ACTIONS_ID_TOKEN_REQUEST_TOKEN
Environment Variables.oidc_request_url
- (Optional) The URL for the OIDC provider from which to request an ID token. This can also be sourced from the ARM_OIDC_REQUEST_URL
or ACTIONS_ID_TOKEN_REQUEST_TOKEN
Environment Variables.oidc_token
- (Optional) The ID token when authenticating using OpenID Connect (OIDC). This can also be sourced from the ARM_OIDC_TOKEN
Environment Variable.oidc_token_file_path
- (Optional) The path to a file containing an ID token when authenticating using OpenID Connect (OIDC). This can also be sourced from the ARM_OIDC_TOKEN_FILE_PATH
Environment Variable.use_oidc
- (Optional) Should OIDC be used for Authentication? This can also be sourced from the ARM_USE_OIDC
Environment Variable. Defaults to false
.More information on how to configure a Service Principal using OpenID Connect can be found in this guide.
When authenticating using Managed Identity, the following fields can be set:
msi_endpoint
- (Optional) The path to a custom endpoint for Managed Identity - in most circumstances this should be detected automatically. This can also be sourced from the ARM_MSI_ENDPOINT
environment variable.use_msi
- (Optional) Should a Managed Identity be used for authentication? This can also be sourced from the ARM_USE_MSI
environment variable. Defaults to false
.More information on how to configure a Service Principal using Managed Identity can be found in this guide.
For Azure CLI authentication, the following fields can be set:
use_cli
- (Optional) Should Azure CLI be used for authentication? This can also be sourced from the ARM_USE_CLI
environment variable. Defaults to true
.For more advanced scenarios, the following additional arguments are supported:
disable_terraform_partner_id
- (Optional) Disable sending the Terraform Partner ID if a custom partner_id
isn't specified. The default Partner ID allows Microsoft to better understand the usage of Terraform and does not give HashiCorp any direct access to usage information. This can also be sourced from the ARM_DISABLE_TERRAFORM_PARTNER_ID
environment variable. Defaults to false
.
partner_id
- (Optional) A UUID that is registered with Microsoft to facilitate partner resource usage attribution. This can also be sourced from the ARM_PARTNER_ID
environment variable.
It's also possible to use multiple Provider blocks within a single Terraform configuration, for example to work with resources across multiple Azure Active Directory Tenants or Environments - more information can be found in the documentation for Providers.
Logging output can be controlled with the TF_LOG
or TF_LOG_PROVIDER
environment variables. Exporting TF_LOG=DEBUG
will increase the log verbosity and emit HTTP request and response traces to stdout when running Terraform. This output is very useful when reporting a bug in the provider.
Note that whilst we make every effort to remove authentication tokens from HTTP traces, they can still contain very identifiable and personal information which you should carefully censor before posting on our issue tracker.