diff --git a/README.md b/README.md index 87fc640ca177..5e578d4b8c58 100644 --- a/README.md +++ b/README.md @@ -43,9 +43,9 @@ Using the provider ``` # Configure the Microsoft Azure Provider provider "azurerm" { - # NOTE: Environment Variables can also be used for Service Principal authentication - # Terraform also supports authenticating via the Azure CLI too. - # see here for more info: http://terraform.io/docs/providers/azurerm/index.html + # More information on the authentication methods supported by + # the AzureRM Provider can be found here: + # http://terraform.io/docs/providers/azurerm/index.html # subscription_id = "..." # client_id = "..." @@ -54,32 +54,17 @@ provider "azurerm" { } # Create a resource group -resource "azurerm_resource_group" "main" { +resource "azurerm_resource_group" "example" { name = "production-resources" location = "West US" } # Create a virtual network in the production-resources resource group -resource "azurerm_virtual_network" "network" { +resource "azurerm_virtual_network" "test" { name = "production-network" - resource_group_name = "${azurerm_resource_group.main.name}" - location = "${azurerm_resource_group.main.location}" + resource_group_name = "${azurerm_resource_group.example.name}" + location = "${azurerm_resource_group.example.location}" address_space = ["10.0.0.0/16"] - - subnet { - name = "subnet1" - address_prefix = "10.0.1.0/24" - } - - subnet { - name = "subnet2" - address_prefix = "10.0.2.0/24" - } - - subnet { - name = "subnet3" - address_prefix = "10.0.3.0/24" - } } ``` @@ -88,7 +73,7 @@ Further [usage documentation is available on the Terraform website](https://www. Developing the Provider --------------------------- -If you wish to work on the provider, you'll first need [Go](http://www.golang.org) installed on your machine (version 1.9+ is *required*). You'll also need to correctly setup a [GOPATH](http://golang.org/doc/code.html#GOPATH), as well as adding `$GOPATH/bin` to your `$PATH`. +If you wish to work on the provider, you'll first need [Go](http://www.golang.org) installed on your machine (version 1.11+ is *required*). You'll also need to correctly setup a [GOPATH](http://golang.org/doc/code.html#GOPATH), as well as adding `$GOPATH/bin` to your `$PATH`. To compile the provider, run `make build`. This will build the provider and put the provider binary in the `$GOPATH/bin` directory. @@ -99,24 +84,26 @@ $ $GOPATH/bin/terraform-provider-azurerm ... ``` -In order to test the provider, you can simply run `make test`. +In order to run the unit tests for the provider, you can run: ```sh $ make test ``` -In order to run the full suite of Acceptance tests, run `make testacc`. +The majority of tests in the provider are Acceptance Tests - which provisions real resources in Azure. It's possible to run the entire acceptance test suite by running `make testacc` - however it's likely you'll want to run a subset, which you can do using a prefix, by running: + +``` +make testacc TESTARGS='-run=TestAccAzureRMResourceGroup' +``` -The following ENV variables must be set in your shell prior to running acceptance tests: -- ARM_CLIENT_ID -- ARM_CLIENT_SECRET -- ARM_SUBSCRIPTION_ID -- ARM_TENANT_ID -- ARM_TEST_LOCATION -- ARM_TEST_LOCATION_ALT +The following Environment Variables must be set in your shell prior to running acceptance tests: -*Note:* Acceptance tests create real resources, and often cost money to run. +- `ARM_CLIENT_ID` +- `ARM_CLIENT_SECRET` +- `ARM_SUBSCRIPTION_ID` +- `ARM_TENANT_ID` +- `ARM_ENVIRONMENT` +- `ARM_TEST_LOCATION` +- `ARM_TEST_LOCATION_ALT` -```sh -$ make testacc -``` +**Note:** Acceptance tests create real resources in Azure which often cost money to run. diff --git a/azurerm/provider.go b/azurerm/provider.go index 9336bc664ac2..038e54ac9c0d 100644 --- a/azurerm/provider.go +++ b/azurerm/provider.go @@ -30,12 +30,6 @@ func Provider() terraform.ResourceProvider { DefaultFunc: schema.EnvDefaultFunc("ARM_CLIENT_ID", ""), }, - "client_secret": { - Type: schema.TypeString, - Optional: true, - DefaultFunc: schema.EnvDefaultFunc("ARM_CLIENT_SECRET", ""), - }, - "tenant_id": { Type: schema.TypeString, Optional: true, @@ -48,17 +42,27 @@ func Provider() terraform.ResourceProvider { DefaultFunc: schema.EnvDefaultFunc("ARM_ENVIRONMENT", "public"), }, - "skip_credentials_validation": { - Type: schema.TypeBool, + // Client Certificate specific fields + "client_certificate_password": { + Type: schema.TypeString, Optional: true, - DefaultFunc: schema.EnvDefaultFunc("ARM_SKIP_CREDENTIALS_VALIDATION", false), + DefaultFunc: schema.EnvDefaultFunc("ARM_CLIENT_CERTIFICATE_PASSWORD", ""), }, - "skip_provider_registration": { - Type: schema.TypeBool, + "client_certificate_path": { + Type: schema.TypeString, Optional: true, - DefaultFunc: schema.EnvDefaultFunc("ARM_SKIP_PROVIDER_REGISTRATION", false), + DefaultFunc: schema.EnvDefaultFunc("ARM_CLIENT_CERTIFICATE_PATH", ""), }, + + // Client Secret specific fields + "client_secret": { + Type: schema.TypeString, + Optional: true, + DefaultFunc: schema.EnvDefaultFunc("ARM_CLIENT_SECRET", ""), + }, + + // Managed Service Identity specific fields "use_msi": { Type: schema.TypeBool, Optional: true, @@ -69,6 +73,19 @@ func Provider() terraform.ResourceProvider { Optional: true, DefaultFunc: schema.EnvDefaultFunc("ARM_MSI_ENDPOINT", ""), }, + + // Advanced feature flags + "skip_credentials_validation": { + Type: schema.TypeBool, + Optional: true, + DefaultFunc: schema.EnvDefaultFunc("ARM_SKIP_CREDENTIALS_VALIDATION", false), + }, + + "skip_provider_registration": { + Type: schema.TypeBool, + Optional: true, + DefaultFunc: schema.EnvDefaultFunc("ARM_SKIP_PROVIDER_REGISTRATION", false), + }, }, DataSourcesMap: map[string]*schema.Resource{ @@ -315,14 +332,17 @@ func Provider() terraform.ResourceProvider { func providerConfigure(p *schema.Provider) schema.ConfigureFunc { return func(d *schema.ResourceData) (interface{}, error) { builder := &authentication.Builder{ - SubscriptionID: d.Get("subscription_id").(string), - ClientID: d.Get("client_id").(string), - ClientSecret: d.Get("client_secret").(string), - TenantID: d.Get("tenant_id").(string), - Environment: d.Get("environment").(string), - MsiEndpoint: d.Get("msi_endpoint").(string), + SubscriptionID: d.Get("subscription_id").(string), + ClientID: d.Get("client_id").(string), + ClientSecret: d.Get("client_secret").(string), + TenantID: d.Get("tenant_id").(string), + Environment: d.Get("environment").(string), + MsiEndpoint: d.Get("msi_endpoint").(string), + ClientCertPassword: d.Get("client_certificate_password").(string), + ClientCertPath: d.Get("client_certificate_path").(string), // Feature Toggles + SupportsClientCertAuth: true, SupportsClientSecretAuth: true, SupportsManagedServiceIdentity: d.Get("use_msi").(bool), SupportsAzureCliToken: true, diff --git a/website/azurerm.erb b/website/azurerm.erb index 064073e2e329..2c8851e556d4 100644 --- a/website/azurerm.erb +++ b/website/azurerm.erb @@ -9,17 +9,25 @@ > Azure Provider + + + > + Authentication diff --git a/website/docs/auth/azure_cli.html.markdown b/website/docs/auth/azure_cli.html.markdown new file mode 100644 index 000000000000..50c70b883f9b --- /dev/null +++ b/website/docs/auth/azure_cli.html.markdown @@ -0,0 +1,130 @@ +--- +layout: "azurerm" +page_title: "Azure Provider: Authenticating via the Azure CLI" +sidebar_current: "docs-azurerm-authentication-azure-cli" +description: |- + This guide will cover how to use the Azure CLI as authentication for the Azure Provider. + +--- + +# Azure Provider: Authenticating using the Azure CLI + +Terraform supports a number of different methods for authenticating to Azure: + +* Authenticating to Azure using the Azure CLI (which is covered in this guide) +* [Authenticating to Azure using Managed Service Identity](managed_service_identity.html) +* [Authenticating to Azure using a Service Principal and a Client Certificate](service_principal_client_certificate.html) +* [Authenticating to Azure using a Service Principal and a Client Secret](service_principal_client_secret.html) + +--- + +We recommend using either a Service Principal or Managed Service Identity when running Terraform non-interactively (such as when running Terraform in a CI server) - and authenticating using the Azure CLI when running Terraform locally. + +## Important Notes about Authenticating using the Azure CLI + +* Prior to version 1.20 the AzureRM Provider used a different method of authorizing via the Azure CLI where credentials reset after an hour - as such we'd recommend upgrading to version 1.20 or later of the AzureRM Provider. +* Terraform only supports authenticating using the `az` CLI (and this must be available on your PATH) - authenticating using the older `azure` CLI or PowerShell Cmdlets is not supported. +* Authenticating via the Azure CLI is only supported when using a User Account. If you're using a Service Principal (for example via `az login --service-principal`) you should instead authenticate via the Service Principal directly (either using a [Client Secret](service_principal_client_secret.html) or a [Client Certificate](service_principal_client_certificate.html)). + +--- + +## Logging into the Azure CLI + +~> **Note**: If you're using the **China**, **German** or **Government** Azure Clouds - you'll need to first configure the Azure CLI to work with that Cloud. You can do this by running: + +```shell +$ az cloud set --name AzureChinaCloud|AzureGermanCloud|AzureUSGovernment +``` + +--- + +Firstly, login to the Azure CLI using: + +```shell +$ az login +``` + +Once logged in - it's possible to list the Subscriptions associated with the account via: + +```shell +$ az account list +``` + +The output (similar to below) will display one or more Subscriptions - with the `id` field being the `subscription_id` field referenced above. + +```json +[ + { + "cloudName": "AzureCloud", + "id": "00000000-0000-0000-0000-000000000000", + "isDefault": true, + "name": "PAYG Subscription", + "state": "Enabled", + "tenantId": "00000000-0000-0000-0000-000000000000", + "user": { + "name": "user@example.com", + "type": "user" + } + } +] +``` + +Should you have more than one Subscription, you can specify the Subscription to use via the following command: + +```bash +$ az account set --subscription="SUBSCRIPTION_ID" +``` + +--- + +## Configuring Azure CLI authentication in Terraform + +Now that we're logged into the Azure CLI - we can configure Terraform to use these credentials. + +To configure Terraform to use the Default Subscription defined in the Azure CLI - we can use the following Provider block: + +```hcl +provider "azurerm" { + # Whilst version is optional, we /strongly recommend/ using it to pin the version of the Provider being used + version = "=1.20.0" +} +``` + +More information on [the fields supported in the Provider block can be found here](../index.html#argument-reference). + +At this point running either `terraform plan` or `terraform apply` should allow Terraform to run using the Azure CLI to authenticate. + +--- + +It's also possible to configure Terraform to use a specific Subscription - for example: + +```hcl +provider "azurerm" { + # Whilst version is optional, we /strongly recommend/ using it to pin the version of the Provider being used + version = "=1.20.0" + + subscription_id = "00000000-0000-0000-0000-000000000000" +} +``` + +More information on [the fields supported in the Provider block can be found here](../index.html#argument-reference). + +At this point running either `terraform plan` or `terraform apply` should allow Terraform to run using the Azure CLI to authenticate. + +--- + +If you're looking to use Terraform across Tenants - it's possible to do this by configuring the Tenant ID field in the Provider block, as shown below: + +```hcl +provider "azurerm" { + # Whilst version is optional, we /strongly recommend/ using it to pin the version of the Provider being used + version = "=1.20.0" + + subscription_id = "00000000-0000-0000-0000-000000000000" + tenant_id = "11111111-1111-1111-1111-111111111111" +} +``` + +More information on [the fields supported in the Provider block can be found here](../index.html#argument-reference). + +At this point running either `terraform plan` or `terraform apply` should allow Terraform to run using the Azure CLI to authenticate. diff --git a/website/docs/auth/managed_service_identity.html.markdown b/website/docs/auth/managed_service_identity.html.markdown new file mode 100644 index 000000000000..ac49c2aacbed --- /dev/null +++ b/website/docs/auth/managed_service_identity.html.markdown @@ -0,0 +1,100 @@ +--- +layout: "azurerm" +page_title: "Azure Provider: Authenticating via Managed Service Identity" +sidebar_current: "docs-azurerm-authentication-managed-service-identity" +description: |- + This guide will cover how to use Managed Service Identity as authentication for the Azure Provider. + +--- + +# Azure Provider: Authenticating using Managed Service Identity + +Terraform supports a number of different methods for authenticating to Azure: + +* [Authenticating to Azure using the Azure CLI](azure_cli.html) +* Authenticating to Azure using Managed Service Identity (which is covered in this guide) +* [Authenticating to Azure using a Service Principal and a Client Certificate](service_principal_client_certificate.html) +* [Authenticating to Azure using a Service Principal and a Client Secret](service_principal_client_secret.html) + +--- + +We recommend using either a Service Principal or Managed Service Identity when running Terraform non-interactively (such as when running Terraform in a CI server) - and authenticating using the Azure CLI when running Terraform locally. + +## What is Managed Service Identity? + +Certain services within Azure (for example Virtual Machines and Virtual Machine Scale Sets) can be assigned an Azure Active Directory identity which can be used to access the Azure Subscription. This identity can then be assigned permissions to a Subscription, Resource Group or other resources using the Azure Identity and Access Management functionality - however by default no permissions are assigned. + +Once a resource is configured with an identity, a local metadata service exposes credentials which can be used by applications such as Terraform. + +## Configuring Managed Service Identity + +The (simplified) Terraform Configuration below configures a Virtual Machine with Managed Service Identity, and then grants it Contributor access to the Subscription: + +```hcl +data "azurerm_subscription" "current" {} + +resource "azurerm_virtual_machine" "test" { + # ... + + identity = { + type = "SystemAssigned" + } +} + +data "azurerm_builtin_role_definition" "contributor" { + name = "Contributor" +} + +resource "azurerm_role_assignment" "test" { + name = "${azurerm_virtual_machine.test.name}" + scope = "${data.azurerm_subscription.primary.id}" + role_definition_id = "${data.azurerm_subscription.subscription.id}${data.azurerm_builtin_role_definition.contributor.id}" + principal_id = "${lookup(azurerm_virtual_machine.test.identity[0], "principal_id")}" +} +``` + +## Configuring Managed Service Identity in Terraform + +At this point we assume that Managed Service Identity is configured on the resource (e.g. Virtual Machine) being used - and that permissions have been assigned via Azure's Identity and Access Management system. + +Terraform can be configured to use Managed Service Identity for authentication in one of two ways: using Environment Variables or by defining the fields within the Provider block. + +You can configure Terraform to use Managed Service Identity by setting the Environment Variable `ARM_USE_MSI` to `true`; as shown below: + +```shell +$ export ARM_USE_MSI=true +``` + +-> **Using a Custom MSI Endpoint?** In the unlikely event you're using a custom endpoint for Managed Service Identity - this can be configured using the `ARM_MSI_ENDPOINT` Environment Variable - however this shouldn't need to be configured in regular use. + +Whilst a Provider block is _technically_ optional when using Environment Variables - we'd strongly recommend defining one to be able to pin the version of the Provider being used: + +```hcl +provider "azurerm" { + # Whilst version is optional, we /strongly recommend/ using it to pin the version of the Provider being used + version = "=1.20.0" +} +``` + +More information on [the fields supported in the Provider block can be found here](../index.html#argument-reference). + +At this point running either `terraform plan` or `terraform apply` should allow Terraform to run using Managed Service Identity. + +--- + +It's also possible to configure Managed Service Identity within the Provider Block: + +```hcl +provider "azurerm" { + # Whilst version is optional, we /strongly recommend/ using it to pin the version of the Provider being used + version = "=1.20.0" + + use_msi = true +} +``` + +-> **Using a Custom MSI Endpoint?** In the unlikely event you're using a custom endpoint for Managed Service Identity - this can be configured using the `msi_endpoint` field - however this shouldn't need to be configured in regular use. + +More information on [the fields supported in the Provider block can be found here](../index.html#argument-reference). + +At this point running either `terraform plan` or `terraform apply` should allow Terraform to run using Managed Service Identity. diff --git a/website/docs/auth/service_principal_client_certificate.html.markdown b/website/docs/auth/service_principal_client_certificate.html.markdown new file mode 100644 index 000000000000..9bfb261f2811 --- /dev/null +++ b/website/docs/auth/service_principal_client_certificate.html.markdown @@ -0,0 +1,140 @@ +--- +layout: "azurerm" +page_title: "Azure Provider: Authenticating via a Service Principal and a Client Certificate" +sidebar_current: "docs-azurerm-authentication-service-principal-client-certificate" +description: |- + This guide will cover how to use a Service Principal (Shared Account) with a Client Certificate as authentication for the Azure Provider. + +--- + +# Azure Provider: Authenticating using a Service Principal with a Client Certificate + +Terraform supports a number of different methods for authenticating to Azure: + +* [Authenticating to Azure using the Azure CLI](azure_cli.html) +* [Authenticating to Azure using Managed Service Identity](managed_service_identity.html) +* Authenticating to Azure using a Service Principal and a Client Certificate (which is covered in this guide) +* [Authenticating to Azure using a Service Principal and a Client Secret](service_principal_client_secret.html) + +--- + +We recommend using either a Service Principal or Managed Service Identity when running Terraform non-interactively (such as when running Terraform in a CI server) - and authenticating using the Azure CLI when running Terraform locally. + +--- + +## Creating a Service Principal + +A Service Principal is an application within Azure Active Directory which can be used as a means of authentication, either [using a Client Secret](service_principal_client_secret.html) or a Client Certificate (which is documented in this guide) and can be created though the Azure Portal. + +This guide will cover how to generate a client certificate, how to create a Service Principal and then how to assign the Client Certificate to the Service Principal so that it can be used for authentication. Once that's done finally we're going to grant the Service Principal permission to manage resources in the Subscription - to do this we're going to assign `Contributor` rights to the Subscription - however [it's possible to assign other permissions](https://azure.microsoft.com/en-gb/documentation/articles/role-based-access-built-in-roles/) depending on your configuration. + +--- + +## Generating a Client Certificate + +Firstly we need to create a certificate which can be used for authentication. To do that we're going to generate a Certificate Signing Request (also known as a CSR) using `openssl` (this can also be achieved using PowerShell, however that's outside the scope of this document): + +```shell +$ openssl req -newkey rsa:4096 -nodes -keyout "service-principal.key" -out "service-principal.csr" +``` + +-> During the generation of the certificate you'll be prompted for various bits of information required for the certificate signing request - at least one item has to be specified for this to complete. + +We can now sign that Certificate Signing Request, in this example we're going to self-sign this certificate using the Key we just generated; however it's also possible to do this using a Certificate Authority. In order to do that we're again going to use `openssl`: + +```shell +$ openssl x509 -signkey "service-principal.key" -in "service-principal.csr" -req -days 365 -out "service-principal.crt" +``` + +Finally we can generate a PFX file which can be used to authenticate with Azure: + +```shell +$ openssl pkcs12 -export -out "service-principal.pfx" -inkey "service-principal.key" -in "service-principal.crt" +``` + +Now that we've generated a certificate, we can create the Azure Active Directory application. + +--- + +### Creating the Service Principal + +We're going to create the Service Principal in the Azure Portal - to do this navigate to [the **Azure Active Directory** overview](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Overview) within the Azure Portal - [then select the **App Registration** blade](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RegisteredApps/RegisteredApps/Overview) and click **Endpoints** at the top of the **App Registration** blade. A list of URIs will be displayed and you need to locate the URI for **OAUTH 2.0 AUTHORIZATION ENDPOINT** which contains a GUID. This GUID is your Tenant ID (the `tenant_id` field mentioned above). + +Next, navigate back to [the **App Registration** blade](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RegisteredApps/RegisteredApps/Overview) - from here we'll create the Application in Azure Active Directory. To do this click **New application registration** at the top to add a new Application within Azure Active Directory. On this page, set the following values then press **Create**: + +- **Name** - this is a friendly identifier and can be anything (e.g. "Terraform") +- **Application Type** - this should be set to "Web app / API" +- **Sign-on URL** - this can be anything, providing it's a valid URI (e.g. https://terra.form) + +At this point the newly created Azure Active Directory application should be visible on-screen - if it's not, navigate to the [the **App Registration** blade](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RegisteredApps/RegisteredApps/Overview) and select the Azure Active Directory application. At the top of this page, the "Application ID" GUID is the `client_id` you'll need. + +### Assigning the Client Certificate to the Service Principal + +To associate the public portion of the Client Certificate (the `*.crt` file) with the Azure Active Directory Application - to do this select **Settings** and then **Keys**. This screen displays the Passwords (Client Secrets) and Public Keys (Client Certificates) which are associated with this Azure Active Directory Application. + +The Public Key associated with the generated Certificate can be uploaded by selecting **Upload Public Key**, selecting the file which should be uploaded (in the example above, this'd be `service-principal.crt`) - and then hitting **Save**. + +### Allowing the Service Principal to manage the Subscription + +Now that we've created the Application within Azure Active Directory and assigned the certificate we're using for authentication, we can now grant the Application permissions to manage the Subscription. To do this, [navigate to the **Subscriptions** blade within the Azure Portal](https://portal.azure.com/#blade/Microsoft_Azure_Billing/SubscriptionsBlade), select the Subscription you wish to use, then click **Access Control (IAM)** and finally **Add role assignment**. + +Firstly, specify a Role which grants the appropriate permissions needed for the Service Principal (for example, `Contributor` will grant Read/Write on all resources in the Subscription). More information about [the built in roles can be found here](https://azure.microsoft.com/en-gb/documentation/articles/role-based-access-built-in-roles/). + +Secondly, search for and select the name of the Application created in Azure Active Directory to assign it this role - then press **Save**. + +At this point the newly created Azure Active Directory Application should be associated with the Certificate that we generated earlier (which can be used as a Client Certificate) - and should have permissions to the Azure Subscription. + +--- + +### Configuring the Service Principal in Terraform + +As we've obtained the credentials for this Service Principal - it's possible to configure them in a few different ways. + +When storing the credentials as Environment Variables, for example: + +```bash +$ export ARM_CLIENT_ID="00000000-0000-0000-0000-000000000000" +$ export ARM_CLIENT_CERTIFICATE_PATH="/path/to/my/client/certificate.pfx" +$ export ARM_CLIENT_CERTIFICATE_PASSWORD="Pa55w0rd123" +$ export ARM_SUBSCRIPTION_ID="00000000-0000-0000-0000-000000000000" +$ export ARM_TENANT_ID="00000000-0000-0000-0000-000000000000" +``` + +The following Provider block can be specified - where `1.20.0` is the version of the Azure Provider that you'd like to use: + +```hcl +provider "azurerm" { + # Whilst version is optional, we /strongly recommend/ using it to pin the version of the Provider being used + version = "=1.20.0" +} +``` + +More information on [the fields supported in the Provider block can be found here](../index.html#argument-reference). + +At this point running either `terraform plan` or `terraform apply` should allow Terraform to run using the Service Principal to authenticate. + +--- + +It's also possible to configure these variables either in-line or from using variables in Terraform (as the `client_certificate_path` and `client_certificate_password` are in this example), like so: + +~> **NOTE:** We'd recommend not defining these variables in-line since they could easily be checked into Source Control. + +```hcl +variable "client_certificate_path" {} +variable "client_certificate_password" {} + +provider "azurerm" { + # Whilst version is optional, we /strongly recommend/ using it to pin the version of the Provider being used + version = "=1.20.0" + + subscription_id = "00000000-0000-0000-0000-000000000000" + client_id = "00000000-0000-0000-0000-000000000000" + client_certificate_path = "${var.client_certificate_path}" + client_certificate_password = "${var.client_certificate_password}" + tenant_id = "00000000-0000-0000-0000-000000000000" +} +``` + +More information on [the fields supported in the Provider block can be found here](../index.html#argument-reference). + +At this point running either `terraform plan` or `terraform apply` should allow Terraform to run using the Service Principal to authenticate. diff --git a/website/docs/authenticating_via_service_principal.html.markdown b/website/docs/auth/service_principal_client_secret.html.markdown similarity index 52% rename from website/docs/authenticating_via_service_principal.html.markdown rename to website/docs/auth/service_principal_client_secret.html.markdown index b489e0be990a..e5adbf222a8c 100644 --- a/website/docs/authenticating_via_service_principal.html.markdown +++ b/website/docs/auth/service_principal_client_secret.html.markdown @@ -1,17 +1,24 @@ --- layout: "azurerm" -page_title: "Azure Provider: Authenticating via a Service Principal" -sidebar_current: "docs-azurerm-index-authentication-service-principal" +page_title: "Azure Provider: Authenticating via a Service Principal and a Client Secret" +sidebar_current: "docs-azurerm-authentication-service-principal-client-secret" description: |- - This guide will cover how to use a Service Principal (Shared Account) as authentication for the Azure Provider. + This guide will cover how to use a Service Principal (Shared Account) with a Client Secret as authentication for the Azure Provider. --- -# Azure Provider: Authenticating using a Service Principal +# Azure Provider: Authenticating using a Service Principal with a Client Secret -Terraform supports authenticating to Azure through a Service Principal or the Azure CLI. +Terraform supports a number of different methods for authenticating to Azure: -We recommend using a Service Principal when running in a shared environment (such as within a CI server/automation) - and [authenticating via the Azure CLI](authenticating_via_azure_cli.html) when you're running Terraform locally. +* [Authenticating to Azure using the Azure CLI](azure_cli.html) +* [Authenticating to Azure using Managed Service Identity](managed_service_identity.html) +* [Authenticating to Azure using a Service Principal and a Client Certificate](service_principal_client_certificate.html) +* Authenticating to Azure using a Service Principal and a Client Secret (which is covered in this guide) + +--- + +We recommend using either a Service Principal or Managed Service Identity when running Terraform non-interactively (such as when running Terraform in a CI server) - and authenticating using the Azure CLI when running Terraform locally. ## Creating a Service Principal @@ -35,7 +42,6 @@ Firstly, login to the Azure CLI using: $ az login ``` - Once logged in - it's possible to list the Subscriptions associated with the account via: ```shell @@ -111,41 +117,98 @@ $ az vm list-sizes --location westus $ az account list-locations ``` +Finally, since we're logged into the Azure CLI as a Service Principal we recommend logging out of the Azure CLI (but you can instead log in using your user account): + +```bash +$ az logout +``` + +Information on how to configure the Provider block using the newly created Service Principal credentials can be found below. + +--- + ### Creating a Service Principal in the Azure Portal -There are two tasks needed to create a Service Principal via [the Azure Portal](https://portal.azure.com): +There are three tasks necessary to create a Service Principal using [the Azure Portal](https://portal.azure.com): 1. Create an Application in Azure Active Directory (which acts as a Service Principal) - 2. Grant the Application access to manage resources in your Azure Subscription + 2. Generating a Client Secret for the Azure Active Directory Application (which can be used for authentication) + 3. Grant the Application access to manage resources in your Azure Subscription ### 1. Creating an Application in Azure Active Directory -Firstly navigate to [the **Azure Active Directory** overview](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Overview) within the Azure Portal - [then select the **App Registration** blade](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RegisteredApps/RegisteredApps/Overview) and click **Endpoints** at the top of the **App Registration** blade. A list of URIs will be displayed and you need to locate the URI for **OAUTH 2.0 AUTHORIZATION ENDPOINT** which contains a GUID. This is your Tenant ID / the `tenant_id` field mentioned above. +Firstly navigate to [the **Azure Active Directory** overview](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Overview) within the Azure Portal - [then select the **App Registration** blade](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RegisteredApps/RegisteredApps/Overview) and click **Endpoints** at the top of the **App Registration** blade. A list of URIs will be displayed and you need to locate the URI for **OAUTH 2.0 AUTHORIZATION ENDPOINT** which contains a GUID. This GUID is your Tenant ID (the `tenant_id` field mentioned above). -Next, navigate back to [the **App Registration** blade](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RegisteredApps/RegisteredApps/Overview) - from here we'll create the Application in Azure Active Directory. To do this click **Add** at the top to add a new Application within Azure Active Directory. On this page, set the following values then press **Create**: +Next, navigate back to [the **App Registration** blade](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RegisteredApps/RegisteredApps/Overview) - from here we'll create the Application in Azure Active Directory. To do this click **New application registration** at the top to add a new Application within Azure Active Directory. On this page, set the following values then press **Create**: - **Name** - this is a friendly identifier and can be anything (e.g. "Terraform") - **Application Type** - this should be set to "Web app / API" - **Sign-on URL** - this can be anything, providing it's a valid URI (e.g. https://terra.form) -Once that's done - select the Application you just created in [the **App Registration** blade](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RegisteredApps/RegisteredApps/Overview). At the top of this page, the "Application ID" GUID is the `client_id` you'll need. +At this point the newly created Azure Active Directory application should be visible on-screen - if it's not, navigate to the [the **App Registration** blade](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RegisteredApps/RegisteredApps/Overview) and select the Azure Active Directory application. At the top of this page, the "Application ID" GUID is the `client_id` you'll need. + +### 2. Generating a Client Secret for the Azure Active Directory Application + +Now that the Azure Active Directory Application exists we can create a Client Secret which can be used for authentication - to do this select **Settings** and then **Keys**. This screen displays the Passwords (Client Secrets) and Public Keys (Client Certificates) which are associated with this Azure Active Directory Application. -Finally, we can create the `client_secret` by selecting **Keys** and then generating a new key by entering a description, selecting how long the `client_secret` should be valid for - and finally pressing **Save**. This value will only be visible whilst on the page, so be sure to copy it now (otherwise you'll need to regenerate a new key). +On this screen we can generate a new Password by entering a Description and selecting an Expiry Date, and then pressing **Save**. Once the Password has been generated it will be displayed on screen - _the Password is only displayed once_ so **be sure to copy it now** (otherwise you will need to regenerate a new key). This newly generated Password is the `client_secret` you will need. -### 2. Granting the Application access to manage resources in your Azure Subscription +### 3. Granting the Application access to manage resources in your Azure Subscription -Once the Application exists in Azure Active Directory - we can grant it permissions to modify resources in the Subscription. To do this, [navigate to the **Subscriptions** blade within the Azure Portal](https://portal.azure.com/#blade/Microsoft_Azure_Billing/SubscriptionsBlade), then select the Subscription you wish to use, then click **Access Control (IAM)**, and finally **Add**. +Once the Application exists in Azure Active Directory - we can grant it permissions to modify resources in the Subscription. To do this, [navigate to the **Subscriptions** blade within the Azure Portal](https://portal.azure.com/#blade/Microsoft_Azure_Billing/SubscriptionsBlade), then select the Subscription you wish to use, then click **Access Control (IAM)**, and finally **Add role assignment**. Firstly, specify a Role which grants the appropriate permissions needed for the Service Principal (for example, `Contributor` will grant Read/Write on all resources in the Subscription). There's more information about [the built in roles available here](https://azure.microsoft.com/en-gb/documentation/articles/role-based-access-built-in-roles/). Secondly, search for and select the name of the Application created in Azure Active Directory to assign it this role - then press **Save**. -## Creating a Service Principal through the Legacy CLI's +--- + +### Configuring the Service Principal in Terraform -It's also possible to create credentials via [the legacy cross-platform CLI](https://azure.microsoft.com/en-us/documentation/articles/resource-group-authenticate-service-principal-cli/) and the [legacy PowerShell Cmdlets](https://azure.microsoft.com/en-us/documentation/articles/resource-group-authenticate-service-principal/) - however we would highly recommend using the Azure CLI above. +As we've obtained the credentials for this Service Principal - it's possible to configure them in a few different ways. -## Configuring your Service Principal +When storing the credentials as Environment Variables, for example: + +```bash +$ export ARM_CLIENT_ID="00000000-0000-0000-0000-000000000000" +$ export ARM_CLIENT_SECRET="00000000-0000-0000-0000-000000000000" +$ export ARM_SUBSCRIPTION_ID="00000000-0000-0000-0000-000000000000" +$ export ARM_TENANT_ID="00000000-0000-0000-0000-000000000000" +``` + +The following Provider block can be specified - where `1.20.0` is the version of the Azure Provider that you'd like to use: + +```hcl +provider "azurerm" { + # Whilst version is optional, we /strongly recommend/ using it to pin the version of the Provider being used + version = "=1.20.0" +} +``` + +More information on [the fields supported in the Provider block can be found here](../index.html#argument-reference). + +At this point running either `terraform plan` or `terraform apply` should allow Terraform to run using the Service Principal to authenticate. + +--- + +It's also possible to configure these variables either in-line or from using variables in Terraform (as the `client_secret` is in this example), like so: + +~> **NOTE:** We'd recommend not defining these variables in-line since they could easily be checked into Source Control. + +```hcl +variable "client_secret" {} + +provider "azurerm" { + # Whilst version is optional, we /strongly recommend/ using it to pin the version of the Provider being used + version = "=1.20.0" + + subscription_id = "00000000-0000-0000-0000-000000000000" + client_id = "00000000-0000-0000-0000-000000000000" + client_secret = "${var.client_secret}" + tenant_id = "00000000-0000-0000-0000-000000000000" +} +``` -Service Principals can be configured in Terraform in one of two ways, either as Environment Variables or in the Provider block. Please see [this section](index.html#argument-reference) for an example of which fields are available and can be specified either through Environment Variables - or in the Provider Block. +More information on [the fields supported in the Provider block can be found here](../index.html#argument-reference). -~> **NOTE:** Authenticating using a Service Principal via the Azure CLI is unsupported. Service Principal credentials either need to be specified either as Environment Variables or in the Provider Block. +At this point running either `terraform plan` or `terraform apply` should allow Terraform to run using the Service Principal to authenticate. diff --git a/website/docs/authenticating_via_azure_cli.html.markdown b/website/docs/authenticating_via_azure_cli.html.markdown deleted file mode 100644 index 02627090cd6e..000000000000 --- a/website/docs/authenticating_via_azure_cli.html.markdown +++ /dev/null @@ -1,81 +0,0 @@ ---- -layout: "azurerm" -page_title: "Azure Provider: Authenticating via the Azure CLI" -sidebar_current: "docs-azurerm-index-authentication-azure-cli" -description: |- - This guide will cover how to use the Azure CLI to provide authentication for the Azure Provider. - ---- - -# Azure Provider: Authenticating using the Azure CLI - -Terraform supports authenticating to Azure using the Azure CLI, a Service Principal or via Managed Service Identity. - -We recommend [using a Service Principal when running in a shared environment](authenticating_via_service_principal.html) (such as within a CI server/automation) and authenticating via the Azure CLI when running Terraform locally. - -~> **NOTE:** Authenticating via the Azure CLI is only supported when using a User Account. If you're using a Service Principal (for example via `az login --service-principal`) you should instead [authenticate via the Service Principal directly](authenticating_via_service_principal.html). - -When authenticating via the Azure CLI, Terraform will automatically connect to the Default Subscription - this can be changed by using the Azure CLI - and is documented below. - -## Configuring the Azure CLI - -~> **Note:** There are multiple versions of the Azure CLI - the latest version is known as [the Azure CLI 2.0 (Python)](https://github.com/Azure/azure-cli), which can be used for authentication. Terraform does not support the older [Azure CLI (Node.JS)](https://github.com/Azure/azure-xplat-cli) or [Azure PowerShell](https://github.com/Azure/azure-powershell). - -This guide assumes that you have [the Azure CLI 2.0 (Python)](https://github.com/Azure/azure-cli) installed. - -~> **Note:** If you're using the **China**, **German** or **US Government** Azure Clouds, you'll need to first configure the Azure CLI to work with that Cloud. You can do this by running: - -```shell -$ az cloud set --name AzureChinaCloud|AzureGermanCloud|AzureUSGovernment -``` - ---- - -Firstly, login to the Azure CLI using: - -```shell -$ az login -``` - -~> **NOTE:** Authenticating via the Azure CLI is only supported when using a User Account. If you're using a Service Principal (for example via `az login --service-principal`) you should instead [authenticate via the Service Principal directly](authenticating_via_service_principal.html). - -This will prompt you to open a web browser, as shown below: - -```shell -To sign in, use a web browser to open the page https://aka.ms/devicelogin and enter the code XXXXXXXX to authenticate. -``` - -Once logged in, it's possible to list the Subscriptions associated with the account via: - -```shell -$ az account list -``` - -The output (similar to below) will display one or more Subscriptions: - -```json -[ - { - "cloudName": "AzureCloud", - "id": "00000000-0000-0000-0000-000000000000", - "isDefault": true, - "name": "PAYG Subscription", - "state": "Enabled", - "tenantId": "00000000-0000-0000-0000-000000000000", - "user": { - "name": "user@example.com", - "type": "user" - } - } -] -``` - -In the snippet above, `id` refers to the Subscription ID and `isDefault` refers to whether this Subscription is configured as the default. - -~> **Note:** When authenticating via the Azure CLI, Terraform will automatically connect to the Default Subscription. Therefore, if you have multiple subscriptions on the account, you may need to set the Default Subscription, via: - -```shell -$ az account set --subscription="SUBSCRIPTION_ID" -``` - -If you're previously authenticated using a Service Principal (configured via Environment Variables) - you must remove the `ARM_*` prefixed Environment Variables in order to be able to authenticate using the Azure CLI. diff --git a/website/docs/authenticating_via_msi.html.markdown b/website/docs/authenticating_via_msi.html.markdown deleted file mode 100644 index 8c4e0daf9104..000000000000 --- a/website/docs/authenticating_via_msi.html.markdown +++ /dev/null @@ -1,96 +0,0 @@ ---- -layout: "azurerm" -page_title: "AzureRM: Authenticating via Managed Service Identity" -sidebar_current: "docs-azurerm-index-authentication-msi" -description: |- - The Azure Resource Manager provider supports authenticating via multiple means. This guide will cover configuring a Managed Service Identity which can be used to access Azure Resource Manager. - ---- - -# Azure Provider: Authenticating using Managed Service Identity - -Terraform supports authenticating to Azure using Managed Service Identity, a Service Principal, or the Azure CLI. - -Instead of specifying a Service Principal or Azure CLI credentials, Managed Service Identity can be used to interact with other Azure Services from within a Virtual Machine in Azure. - -## Configuring Managed Service Identity - -Managed Service Identity allows an Azure virtual machine to retrieve a token to access the Azure API without needing to pass in credentials. This is accomplished by creating a service principal in Azure Active Directory that is associated to a virtual machine. The resulting service principal can then be granted permissions to Azure resources and API's. - -There are various ways to configure managed service identities. For more on this subject and the benefits of using managed identities, see the Microsoft article [What is managed identities for Azure resources?](https://docs.microsoft.com/en-us/azure/active-directory/msi-overview). You can then run Terraform from the MSI-enabled virtual machine by setting the `use_msi` provider option to `true`. - -### Configuring Managed Service Identity using Terraform - -Managed service identity can also be configured using Terraform. The following template shows how. Note that for a Linux VM you must use the `ManagedIdentityExtensionForLinux` extension. - -```hcl -resource "azurerm_virtual_machine" "virtual_machine" { - name = "test" - location = "${var.location}" - resource_group_name = "test" - network_interface_ids = ["${azurerm_network_interface.test.id}"] - vm_size = "Standard_DS1_v2" - - identity = { - type = "SystemAssigned" - } - - storage_image_reference { - publisher = "MicrosoftWindowsServer" - offer = "WindowsServer" - sku = "2016-Datacenter-smalldisk" - version = "latest" - } - - storage_os_disk { - name = "test" - caching = "ReadWrite" - create_option = "FromImage" - managed_disk_type = "Standard_LRS" - } - - os_profile { - computer_name = "test" - admin_username = "username" - admin_password = "password" - } - - os_profile_windows_config { - provision_vm_agent = true - enable_automatic_upgrades = false - } -} - -resource "azurerm_virtual_machine_extension" "virtual_machine_extension" { - name = "test" - location = "${var.location}" - resource_group_name = "test" - virtual_machine_name = "${azurerm_virtual_machine.virtual_machine.name}" - publisher = "Microsoft.ManagedIdentity" - type = "ManagedIdentityExtensionForWindows" - type_handler_version = "1.0" - - settings = < **Note:** This supercedes the [legacy Azure provider](/docs/providers/azure/index.html), which interacts with Azure using the Service Management API. +Interested in the provider's latest features, or want to make sure you're up to date? Check out the [changelog](https://github.com/terraform-providers/terraform-provider-azurerm/blob/master/CHANGELOG.md) for version information and release notes. -Use the navigation to the left to read about the available resources. +## Authenticating to Azure -# Creating Credentials +Terraform supports a number of different methods for authenticating to Azure: -Terraform supports authenticating to Azure through a Service Principal or the Azure CLI. +* [Authenticating to Azure using the Azure CLI](auth/azure_cli.html) +* [Authenticating to Azure using Managed Service Identity](auth/managed_service_identity.html) +* [Authenticating to Azure using a Service Principal and a Client Certificate](auth/service_principal_client_certificate.html) +* [Authenticating to Azure using a Service Principal and a Client Secret](auth/service_principal_client_secret.html) -We recommend [using a Service Principal when running in a shared environment](authenticating_via_service_principal.html) (such as within a CI server/automation) - and [authenticating via the Azure CLI](authenticating_via_azure_cli.html) when you're running Terraform locally. +--- -~> **NOTE:** Authenticating via the Azure CLI is only supported when using a User Account. If you're using a Service Principal (e.g. via `az login --service-principal`) you should instead [authenticate via the Service Principal directly](authenticating_via_service_principal.html). +We recommend using either a Service Principal or Managed Service Identity when running Terraform non-interactively (such as when running Terraform in a CI server) - and authenticating using the Azure CLI when running Terraform locally. ## Example Usage ```hcl # Configure the Azure Provider -provider "azurerm" {} +provider "azurerm" { + # whilst the `version` attribute is optional, we recommend pinning to a given version of the Provider + version = "=1.20.0" +} # Create a resource group -resource "azurerm_resource_group" "network" { +resource "azurerm_resource_group" "test" { name = "production" location = "West US" } # Create a virtual network within the resource group -resource "azurerm_virtual_network" "network" { +resource "azurerm_virtual_network" "test" { name = "production-network" + resource_group_name = "${azurerm_resource_group.test.name}" + location = "${azurerm_resource_group.test.location}" address_space = ["10.0.0.0/16"] - location = "${azurerm_resource_group.network.location}" - resource_group_name = "${azurerm_resource_group.network.name}" - - subnet { - name = "subnet1" - address_prefix = "10.0.1.0/24" - } - - subnet { - name = "subnet2" - address_prefix = "10.0.2.0/24" - } - - subnet { - name = "subnet3" - address_prefix = "10.0.3.0/24" - } } ``` +## Features and Bug Requests + +The Azure provider's bugs and feature requests can be found in the [GitHub repo issues](https://github.com/terraform-providers/terraform-provider-azurerm/issues). +Please avoid "me too" or "+1" comments. Instead, use a thumbs up [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) +on enhancement requests. Provider maintainers will often prioritize 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 provider. + +If you have a bug or feature request without an existing issue + +* if an existing resource or field is working in an unexpected way, [file a bug](https://github.com/terraform-providers/terraform-provider-azurerm/issues/new?template=bug.md). + +* if you'd like the provider to support a new resource or field, [file an enhancement/feature request](https://github.com/terraform-providers/terraform-provider-azurerm/issues/new?template=enhancement.md). + +The provider maintainers will often use the assignee field on an issue to mark +who is working on it. + +* An issue assigned to an individual maintainer indicates that maintainer is working +on the issue + +* If you're interested in working on an issue please leave a comment in that issue + +--- + +If you have configuration questions, or general questions about using the provider, try checking out: + +* [Terraform's community resources](https://www.terraform.io/docs/extend/community/index.html) +* [HashiCorp support](https://support.hashicorp.com) for Terraform Enterprise customers + + ## Argument Reference The following arguments are supported: -* `subscription_id` - (Optional) The subscription ID to use. It can also - be sourced from the `ARM_SUBSCRIPTION_ID` environment variable. +* `client_id` - (Optional) The Client ID which should be used. This can also be sourced from the `ARM_CLIENT_ID` Environment Variable. + +* `environment` - (Optional) The Cloud Environment which be used. Possible values are `public`, `usgovernment`, `german` and `china`. Defaults to `public`. This can also be sourced from the `ARM_ENVIRONMENT` environment variable. + +* `subscription_id` - (Optional) The Subscription ID which should be used. This can also be sourced from the `ARM_SUBSCRIPTION_ID` 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_id` - (Optional) The client ID to use. It can also be sourced from - the `ARM_CLIENT_ID` environment variable. +* `client_certificate_password` - (Optional) The password associated with the Client Certificate. This can also be sourced from the `ARM_CLIENT_CERTIFICATE_PASSWORD` Environment Variable. -* `client_secret` - (Optional) The client secret to use. It can also be sourced from - the `ARM_CLIENT_SECRET` environment variable. +* `client_certificate_path` - (Optional) The path to the Client Certificate associated with the Service Principal which should be used. This can also be sourced from the `ARM_CLIENT_CERTIFICATE_PATH` Environment Variable. -* `tenant_id` - (Optional) The tenant ID to use. It can also be sourced from the - `ARM_TENANT_ID` environment variable. +More information on [how to configure a Service Principal using a Client Certificate can be found in this guide](auth/service_principal_client_certificate.html). -* `use_msi` - (Optional) Set to true to authenticate using managed service identity. - It can also be sourced from the `ARM_USE_MSI` environment variable. +--- + +When authenticating as a Service Principal using a Client Secret, the following fields can be set: -* `msi_endpoint` - (Optional) The REST endpoint to retrieve an MSI token from. Terraform - will attempt to discover this automatically but it can be specified manually here. - It can also be sourced from the `ARM_MSI_ENDPOINT` environment variable. +* `client_secret` - (Optional) The Client Secret which should be used. This can also be sourced from the `ARM_CLIENT_SECRET` Environment Variable. -* `environment` - (Optional) The cloud environment to use. It can also be sourced - from the `ARM_ENVIRONMENT` environment variable. Supported values are: - * `public` (default) - * `usgovernment` - * `german` - * `china` +More information on [how to configure a Service Principal using a Client Secret can be found in this guide](auth/service_principal_client_secret.html). + +--- -* `skip_credentials_validation` - (Optional) Prevents the provider from validating - the given credentials. When set to `true`, `skip_provider_registration` is assumed. - It can also be sourced from the `ARM_SKIP_CREDENTIALS_VALIDATION` environment - variable; defaults to `false`. +When authenticating using Managed Service Identity, the following fields can be set: -* `skip_provider_registration` - (Optional) Prevents the provider from registering - the ARM provider namespaces, this can be used if you don't wish to give the Active - Directory Application permission to register resource providers. It can also be - sourced from the `ARM_SKIP_PROVIDER_REGISTRATION` environment variable; defaults - to `false`. +* `msi_endpoint` - (Optional) The path to a custom endpoint for Managed Service Identity - in most circumstances this should be detected automatically. This can also be sourced from the `ARM_MSI_ENDPOINT` Environment Variable. -## Testing +* `use_msi` - (Optional) Should Managed Service 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 Service Identity can be found in this guide](auth/managed_service_identity.html). + +--- -The following Environment Variables must be set to run the acceptance tests: +For some advanced scenarios, such as where more granular permissions are necessary - the following properties can be set: -~> **NOTE:** The Acceptance Tests require the use of a Service Principal - authenticating via either the Azure CLI or MSI is not supported. +* `skip_credentials_validation` - (Optional) Should the AzureRM Provider skip verifying the credentials being used are valid? This can also be sourced from the `ARM_SKIP_CREDENTIALS_VALIDATION` Environment Variable. Defaults to `false`. -* `ARM_SUBSCRIPTION_ID` - The ID of the Azure Subscription in which to run the Acceptance Tests. -* `ARM_CLIENT_ID` - The Client ID of the Service Principal. -* `ARM_CLIENT_SECRET` - The Client Secret associated with the Service Principal. -* `ARM_TENANT_ID` - The Tenant ID to use. -* `ARM_ENVIRONMENT` - The Azure Cloud Environment to use, such as `public`, `german` etc. Defaults to `public`. -* `ARM_TEST_LOCATION` - The primary Azure Region to provision resources in for the Acceptance Tests. -* `ARM_TEST_LOCATION_ALT` - The secondary Azure Region to provision resources in for the Acceptance Tests. This needs to be a different region to `ARM_TEST_LOCATION`. +* `skip_provider_registration` - (Optional) Should the AzureRM Provider skip registering any required Resource Providers? This can also be sourced from the `ARM_SKIP_PROVIDER_REGISTRATION` Environment Variable. Defaults to `false`.