From 59dc7283b15ad6485ca30ca7105f06ed230581bd Mon Sep 17 00:00:00 2001 From: Tom Bamford Date: Tue, 15 Jun 2021 12:50:21 +0100 Subject: [PATCH] WIP update guides, docs homepage and readme --- docs/guides/azure_cli.md | 32 ++++++- docs/guides/managed_service_identity.md | 35 +++----- docs/guides/microsoft-graph.md | 20 +++-- .../guides/service_principal_configuration.md | 63 ++++++++------ docs/index.md | 86 +++++++++---------- 5 files changed, 133 insertions(+), 103 deletions(-) diff --git a/docs/guides/azure_cli.md b/docs/guides/azure_cli.md index a8cb0f314c..0bb53c7512 100644 --- a/docs/guides/azure_cli.md +++ b/docs/guides/azure_cli.md @@ -25,7 +25,7 @@ We recommend using either a Service Principal or Managed Identity when running T ## Logging into the Azure CLI -~> **Using other clouds** 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: +~> **Using other clouds** 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, so that the correct authentication service is used. You can do this by running: ```shell $ az cloud set --name AzureChinaCloud|AzureGermanCloud|AzureUSGovernment @@ -39,6 +39,8 @@ Firstly, login to the Azure CLI using: $ az login --allow-no-subscriptions ``` +The `--allow-no-subscriptions` argument enables access to tenants that have no linked subscriptions, in addition to tenants that do. + Once logged in - it's possible to list the Subscriptions and Tenants associated with the account via: ```shell @@ -64,7 +66,7 @@ The output (similar to below) will display one or more Tenants and/or Subscripti ] ``` -The provider will select the tenant ID from your default Azure CLI account. If you have more than one tenant listed in the output of `az account list`, for example if you are a guest user in other tenants, you can specify the tenant to use. +Each entry shown is referred to as an `Azure CLI account`. The provider will select the tenant ID from your default Azure CLI account. If you have more than one tenant listed in the output of `az account list`, for example if you are a guest user in other tenants, you can specify the tenant to use. ```shell $ export ARM_TENANT_ID=00000000-0000-0000-0000-000000000000 @@ -81,13 +83,13 @@ provider "azuread" { } ``` -Alternatively, you can configure the Azure CLI to authenticate against the tenant you are managing with Terraform. +Alternatively, you can configure the Azure CLI to default to the tenant you are managing with Terraform. ```bash $ az login --allow-no-subscriptions --tenant "TENANT_ID_OR_DOMAIN" ``` --> **Tenants and Subscriptions** The AzureAD provider operates on tenants and not on subscriptions. We recommend always specifying `az login --allow-no-subscription` as it will force the Azure CLI to report tenants with no associated subscriptions, or if your user account does not have any roles assigned against your subscriptions. +-> **Tenants and Subscriptions** The AzureAD provider operates on tenants and not on subscriptions. We recommend always specifying `az login --allow-no-subscriptions` as it will force the Azure CLI to report tenants with no associated subscriptions, or where your user account does not have any roles assigned for a subscription. --- @@ -116,3 +118,25 @@ provider "azuread" { 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. + +## Disabling Azure CLI authentication + +For compatibility reasons and to ensure a positive user experience when running Terraform interactively, Azure CLI authentication is enabled by default. It's possible to disable authentication using Azure CLI, which you may wish to do in automated environments such as CI/CD pipelines or when scripting operations with Terraform. + +To do so, add the `use_cli` configuration property in the Provider block. + +```hcl +provider "azuread" { + use_cli = false +} +``` + +Alternatively, you can set the `ARM_USE_CLI` environment variable. + +```shell +# sh +export ARM_USE_CLI=false + +# PowerShell +$env:AAD_USE_MICROSOFT_GRAPH = "false" +``` diff --git a/docs/guides/managed_service_identity.md b/docs/guides/managed_service_identity.md index ca5aee4604..67f20c5a67 100644 --- a/docs/guides/managed_service_identity.md +++ b/docs/guides/managed_service_identity.md @@ -22,15 +22,15 @@ Once you have configured a Service Principal as described in this guide, you sho [Managed identities][azure-managed-identities] for Azure resources can be used to authenticate to Azure Active Directory. There are two types of managed identities: system-assigned and user-assigned. This article is based on system-assigned managed identities. -Managed identities work in conjunction with Azure Resource Manager (ARM), Azure AD, and the Azure Instance Metadata Service (IMDS). Azure resources that support managed identities expose an internal IMDS endpoint that the client can use to request an access token. No credentials are stored on the VM, and the only additional information needed to bootstrap the Terraform connection to Azure is the Tenant ID. +Managed identities work in conjunction with Microsoft Graph, Azure AD, and the Azure Instance Metadata Service (IMDS). Azure resources that support managed identities expose an internal IMDS endpoint that the client can use to request an access token. No credentials are stored on the VM, and the only additional information needed to bootstrap the Terraform connection to Azure is the Tenant ID. -Azure AD creates an AD identity when you configure an Azure resource to use a system-assigned managed identity. The configuration process is described in more detail below. Azure AD then creates a service principal to represent the resource. The lifecycle of a system-assigned identity is tied to the resource it is enabled for: it is created when the resource is created and it is automatically removed when the resource is deleted. +Azure AD creates a tenant-wide security principal when you configure an Azure resource to use a system-assigned managed identity. The configuration process is described in more detail below. The lifecycle of a system-assigned identity is tied to the resource it is enabled for: it is created when the resource is created and it is automatically removed when the resource is deleted. Not all Azure services support managed identities, and availability varies by region. Configuration details vary slightly among services. For more information, see [Services that support managed identities for Azure resources][azure-managed-identities-services]. -When using a managed identity, you can only manage resources in the tenant where the corresponding service principal is homed. If you need to manage multiple tenants from the same location, we suggest using Service Principal Authentication with a [client certificate](service_principal_client_certificate.html) or [client secret](service_principal_client_secret.html) so that you can specify different credentials for each tenant. +When using a managed identity, you can only manage resources in the tenant where the corresponding service principal is homed. If you need to manage multiple tenants from the same location, we suggest instead using Service Principal Authentication with a [client certificate](service_principal_client_certificate.html) or [client secret](service_principal_client_secret.html) so that you can specify different credentials for each tenant. -## Configuring a VM to use a Managed system-assigned managed identity +## Configuring a VM to use a system-assigned managed identity The (simplified) Terraform configuration below configures a Virtual Machine with a system-assigned identity, and then outputs the Object ID of the corresponding Service Principal: @@ -54,7 +54,7 @@ output "example_msi_object_id" { Refer to the [azurerm_linux_virtual_machine][azurerm_linux_virtual_machine] and [azurerm_windows_virtual_machine][azurerm_windows_virtual_machine] documentation for more information on how to use these resources to launch a new virtual machine. -The implicitly created Service Principal should have the same or similar name as your virtual machine. At this point you will need to assign permissions to access Azure Active Directory to create and modify Azure Active Directory objects such as users and groups. We recommend the Directory Roles method. See the [Configuring a Service Principal for managing Azure Active Directory](service_principal_configuration.html#method-1-directory-roles-recommended) guide for more information. +The implicitly created Service Principal should have the same or similar name as your virtual machine. At this point you will need to assign permissions to access Azure Active Directory to create and modify Azure Active Directory objects such as users and groups. See the [Configuring a Service Principal for managing Azure Active Directory][azuread-service-principal-permissions] guide for more information. ## Configuring Managed Identity in Terraform @@ -72,16 +72,7 @@ Note that when using managed identity for authentication, the tenant ID must als -> **Using a Custom MSI Endpoint?** In the unlikely event you're using a custom endpoint for Managed 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 to be used: - -```hcl -provider "azuread" { - # Whilst version is optional, we /strongly recommend/ using it to pin the version of the Provider to be used - version = "=1.1.0" -} -``` - -More information on [the fields supported in the Provider block can be found here](../index.html#argument-reference). +See the main provider documentation for more information on [the fields supported in the Provider block][azuread-provider-fields]. At this point running either `terraform plan` or `terraform apply` should allow Terraform to run using Managed Identity. @@ -91,26 +82,24 @@ It's also possible to enable Managed Identity within the Provider Block: ```hcl provider "azuread" { - # Whilst version is optional, we /strongly recommend/ using it to pin the version of the Provider to be used - version = "=1.1.0" - use_msi = true tenant_id = "00000000-0000-0000-0000-000000000000" } ``` -Note that when using managed identity for authentication, the tenant ID must also be specified. - --> **Using a Custom MSI Endpoint?** In the unlikely event you're using a custom endpoint for Managed Identity - this can be configured using the `msi_endpoint` field - however this shouldn't need to be configured in regular use. +Remember when using managed identity for authentication, the tenant ID must also be specified. -More information on [the fields supported in the Provider block can be found here](../index.html#argument-reference). +See the main provider documentation for more information on [the fields supported in the Provider block][azuread-provider-fields]. At this point running either `terraform plan` or `terraform apply` should allow Terraform to run using Managed Identity. -Next you should follow the [Configuring a Service Principal for managing Azure Active Directory](service_principal_configuration.html) guide to grant the Service Principal necessary permissions to create and modify Azure Active Directory objects such as users and groups. +Next you should follow the [Configuring a Service Principal for managing Azure Active Directory][azuread-service-principal-configuration] guide to grant the Service Principal necessary permissions to create and modify Azure Active Directory objects such as users and groups. [azure-managed-identities]: https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview [azure-managed-identities-services]: https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/services-support-managed-identities +[azuread-provider-fields]: https://registry.terraform.io/providers/hashicorp/azuread/latest/docs#argument-reference +[azuread-service-principal-configuration]: https://registry.terraform.io/providers/hashicorp/azuread/latest/docs/guides/service_principal_configuration +[azuread-service-principal-permissions]: https://registry.terraform.io/providers/hashicorp/azuread/latest/docs/guides/service_principal_configuration#method-1-api-roles-recommended-for-service-principals [azurerm_linux_virtual_machine]: https://www.terraform.io/docs/providers/azurerm/r/linux_virtual_machine.html [azurerm_windows_virtual_machine]: https://www.terraform.io/docs/providers/azurerm/r/windows_virtual_machine.html diff --git a/docs/guides/microsoft-graph.md b/docs/guides/microsoft-graph.md index 66c545131b..0448de1e08 100644 --- a/docs/guides/microsoft-graph.md +++ b/docs/guides/microsoft-graph.md @@ -285,15 +285,17 @@ resource "random_uuid" "example_app_user_impersonation_scope" {} resource "azuread_application" "example" { display_name = "example-app" - oauth2_permissions { - admin_consent_description = "Allow the application to access example-app on behalf of the signed-in user." - admin_consent_display_name = "Access example-app" - id = random_uuid.example_app_user_impersonation_scope.result - is_enabled = true - type = "User" - user_consent_description = "Allow the application to access example-app on your behalf." - user_consent_display_name = "Access example-app" - value = "user_impersonation" + api { + oauth2_permission_scope { + admin_consent_description = "Allow the application to access example-app on behalf of the signed-in user." + admin_consent_display_name = "Access example-app" + id = random_uuid.example_app_user_impersonation_scope.result + is_enabled = true + type = "User" + user_consent_description = "Allow the application to access example-app on your behalf." + user_consent_display_name = "Access example-app" + value = "user_impersonation" + } } } ``` diff --git a/docs/guides/service_principal_configuration.md b/docs/guides/service_principal_configuration.md index 02ff8a9e32..18f2ae8ecf 100644 --- a/docs/guides/service_principal_configuration.md +++ b/docs/guides/service_principal_configuration.md @@ -1,5 +1,5 @@ --- -page_title: "Configuring a Service Principal to manage an Azure Active Directory" +page_title: "Configuring a Service Principal to manage Azure Active Directory" subcategory: "Authentication" --- @@ -18,7 +18,7 @@ We recommend using either a Service Principal or Managed Identity when running T ## Creating a Service Principal -A Service Principal represents an application within Azure Active Directory whose authentication tokens can be used as the `client_id`, `client_secret`, and `tenant_id` fields needed by Terraform. +A Service Principal represents an application within Azure Active Directory whose properties and authentication tokens can be used as the `tenant_id`, `client_id` and `client_secret` fields needed by Terraform. Depending on how the service principal authenticates to azure it can be created in a number of different ways: * [Authenticating to Azure using a Service Principal and a Client Certificate](service_principal_client_certificate.html) @@ -28,17 +28,44 @@ Depending on how the service principal authenticates to azure it can be created Now that you have created and authenticated an Application / Service Principal pair, you will need to grant some permissions to administer Azure Active Directory. You can choose either of the following methods to achieve similar results. -### Method 1: Directory Roles (recommended) +### Method 1: API roles (recommended for service principals) -With this method, you will assign directory roles to the Service Principal you created, to grant the desired permissions to administer objects in your Azure Active Directory tenant. +This method involves granting API roles to your Application, and then granting consent for your Service Principal to access the APIs in its own capacity (i.e. not on behalf of a user). -Navigate to the [**Azure Active Directory** overview][azure-portal-aad-overview] within the [Azure Portal][azure-portal]. Go to the [**Roles and Administrators** blade][azure-portal-aad-roles-blade]. +Navigate to the [Azure Active Directory overview][azure-portal-aad-overview] within the [Azure Portal][azure-portal] and select the [App Registrations blade][azure-portal-aad-applications-blade]. Locate your registered Application and click on its display name to manage it. + +Go to the API Permissions blade for the Application and click the "Add a permission" button. In the pane that opens, select "Microsoft Graph". + +Choose "Application Permissions" for the permission type, and check the permissions you would like to assign. The permissions you need will depend on which directory objects you wish to manage with Terraform. The following table shows the required permissions by resource: + +Resource(s) | Role Name(s) +-------- | --------------- +`data.azuread_application`
`data.azuread_service_principal` | Application.Read.All +`data.azuread_domains` | Domain.Read.All +`data.azuread_group`
`data.azuread_groups` | Group.Read.All +`data.azuread_user`
`data.azuread_users` | User.Read.All +`azuread_application`
`azuread_application_app_role`
`azuread_application_certificate`
`azuread_application_oauth2_permission_scope`
`azuread_application_password`
`azuread_service_principal`
`azuread_service_principal_certificate`
`azuread_service_principal_password` | Application.ReadWrite.All +`azuread_group`
`azuread_group_member` | Group.ReadWrite.All +`azuread_user` | User.ReadWrite.All + +Depending on the configuration of your AAD tenant, you may also need to grant the Directory.Read.All and/or Directory.ReadWrite.All roles. If a resource you are using is not shown in the table above, consult the resource documentation. + +After assigning permissions, you will need to grant consent for the service principal to utilise them. The easiest way to do this is by clicking the Grant Admin Consent button in the same API Permissions pane. You will need to be signed in to the Portal as a Global Administrator. + +The Application now has the necessary permissions to administer your Azure Active Directory tenant. + + +### Method 2: Directory Roles (recommended for users, i.e. Azure CLI authentication) + +With this method, you will assign directory roles to your User Principal, to grant the desired permissions to administer objects in your Azure Active Directory tenant. The following steps may need to be performed by an existing Global Administrator, if that is someone else. + +Navigate to the [Azure Active Directory overview][azure-portal-aad-overview] within the [Azure Portal][azure-portal]. Go to the [Roles and Administrators blade][azure-portal-aad-roles-blade]. Locate the role you wish to assign and click on it. Consult the [documentation for administrator role permissions][admin-roles-docs] from Microsoft for more information about the available roles and the permissions they grant. -Click "Add assignments" and type the name of your Service Principal in the search box to locate it. If you know the Object ID of the Service Principal, verify that it is the same. Select it and click the "Add" button to assign the role. +Click "Add assignments" and type the display name or user principal name of your User in the search box to locate it. If you know the Object ID of the User, verify that it is the same. Select it and click the "Add" button to assign the role. -The choice of which directory roles to assign will be specific to your organisations Commonly used roles include: +The choice of which directory roles to assign will be specific to your organisation's security policy. Commonly used roles include: Role | Description --------------------------- | ----------------------------------------------------------------------------------------------------------------------- @@ -48,25 +75,13 @@ Role | Description `Groups Administrator` | Create and manage groups. `User Administrator` | Create and manage users _and_ groups. -### Method 2: API access with admin consent - -This method involves granting API scopes to your Application, and then granting consent for your Application to access the APIs in its own capacity (i.e. not on behalf of a user). - -Navigate to the [**Azure Active Directory** overview][azure-portal-aad-overview] within the [Azure Portal][azure-portal] and select the [**App Registrations** blade][azure-portal-aad-applications-blade]. Locate your registered Application and click on its display name to manage it. - -Go to the API Permissions blade for the Application and click the "Add a permission" button. In the pane that opens, select "Azure Active Directory Graph" (under the Supported Legacy APIs subheading). Do not select "Microsoft Graph", as the provider does not currently make use of this API. - -Choose "Application Permissions" for the permission type, and check the permissions you would like to assign. The permissions you need will depend on which directory objects you are seeking to manage with Terraform. We suggest the following permissions: - -- `Application.ReadWrite.All` -- `Directory.ReadWrite.All` - -Note that these permissions do not cover all use cases. Notable actions you cannot perform with permissions granted in this way include deleting groups and deleting users. - -Once you have assigned the permissions, you will need to grant admin consent. This requires that you are signed in to the Portal as a Global Administrator. Click the "Grant admin consent" button and confirm the action. +Once the desired directory role is assigned, you may need to obtain a new access token in order for the role to take effect. This can be performed by signing out and signing back in to the Azure CLI. -The Application now has permission to administer your Azure Active Directory tenant. +```shell +$ az logout +$ az login --allow-no-subscriptions +``` [admin-roles-docs]: https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles [azure-portal]: https://portal.azure.com/ diff --git a/docs/index.md b/docs/index.md index 01babc38c8..66e3824dfc 100644 --- a/docs/index.md +++ b/docs/index.md @@ -1,63 +1,65 @@ # Azure Active Directory Provider -The Azure Provider can be used to configure infrastructure in [Azure Active Directory](https://azure.microsoft.com/en-us/services/active-directory/) using the Azure Resource Manager API's. Documentation regarding the [Data Sources](/docs/configuration/data-sources.html) and [Resources](/docs/configuration/resources.html) supported by the Azure Active Directory Provider can be found in the navigation to the left. +The Azure Provider can be used to configure infrastructure in [Azure Active Directory](https://azure.microsoft.com/en-us/services/active-directory/) using the [Microsoft Graph](https://docs.microsoft.com/en-us/graph/overview) API. Documentation regarding the [Data Sources](https://www.terraform.io/docs/language/data-sources/index.html) and [Resources](https://www.terraform.io/docs/language/resources/index.html) 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](https://github.com/hashicorp/terraform-provider-azuread/blob/main/CHANGELOG.md) for version information and release notes. -## Authenticating to Azure Active Directory - -Terraform supports a number of different methods for authenticating to Azure Active Directory: - -* [Authenticating to Azure Active Directory using the Azure CLI](guides/azure_cli.html) -* [Authenticating to Azure Active Directory using Managed Service Identity](guides/managed_service_identity.html) -* [Authenticating to Azure Active Directory using a Service Principal and a Client Certificate](guides/service_principal_client_certificate.html) -* [Authenticating to Azure Active Directory using a Service Principal and a Client Secret](guides/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. - ## Example Usage ```hcl -# Configure the Microsoft Azure Active Directory Provider +# Configure Terraform +terraform { + required_providers { + azuread = { + source = "hashicorp/azuread" + version = "~> 2.0.0" + } + } +} + +# Configure the Azure Active Directory Provider provider "azuread" { - version = "=0.7.0" + tenant_id = "00000000-0000-0000-0000-000000000000" } # Create an application resource "azuread_application" "example" { - name = "ExampleApp" + display_name = "ExampleApp" } # Create a service principal resource "azuread_service_principal" "example" { - application_id = "${azuread_application.example.application_id}" + application_id = azuread_application.example.application_id } ``` +## Authenticating to Azure Active Directory + +Terraform supports a number of different methods for authenticating to Azure Active Directory: + +* [Authenticating to Azure Active Directory using the Azure CLI](guides/azure_cli.html) +* [Authenticating to Azure Active Directory using Managed Identity](guides/managed_service_identity.html) +* [Authenticating to Azure Active Directory using a Service Principal and a Client Certificate](guides/service_principal_client_certificate.html) +* [Authenticating to Azure Active Directory using a Service Principal and a Client Secret](guides/service_principal_client_secret.html) + +--- + +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. + ## Features and Bug Requests -The Azure Active Directory provider's bugs and feature requests can be found in the [GitHub repo issues](https://github.com/hashicorp/terraform-provider-azuread/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 prioritise work based on the number of thumbs on an issue. +Bugs and feature requests can be reported on the [GitHub issues tracker](https://github.com/hashicorp/terraform-provider-azuread/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 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. +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 +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/hashicorp/terraform-provider-azuread/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/hashicorp/terraform-provider-azuread/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 +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 --- @@ -72,9 +74,7 @@ If you have configuration questions, or general questions about using the provid 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. - -* `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. - +* `environment` - (Optional) The Cloud Environment which be used. Possible values are `global`, `germany`, `china`, `usgovernmentl4` and `usgovernmentl5`. Defaults to `global`. This can also be sourced from the `ARM_ENVIRONMENT` environment variable. * `tenant_id` - (Optional) The Tenant ID which should be used. This can also be sourced from the `ARM_TENANT_ID` Environment Variable. --- @@ -82,7 +82,6 @@ The following arguments are supported: When authenticating as a Service Principal using a Client Certificate, the following fields can be set: * `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_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. More information on [how to configure a Service Principal using a Client Certificate can be found in this guide](guides/service_principal_client_certificate.html). @@ -97,13 +96,18 @@ More information on [how to configure a Service Principal using a Client Secret --- -When authenticating using Managed Service Identity, the following fields can be set: +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 Managed Identity be used for authentication? This can also be sourced from the `ARM_USE_MSI` 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. +More information on [how to configure a Service Principal using Managed Identity can be found in this guide](guides/managed_service_identity.html). -* `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`. +--- + +For Azure CLI authentication, the following fields can be set: -More information on [how to configure a Service Principal using Managed Service Identity can be found in this guide](guides/managed_service_identity.html). +* `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`. --- @@ -113,10 +117,6 @@ 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`. -* `metadata_host` - (Optional, **Deprecated**) 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_HOST` Environment Variable. This property is deprecated and will be removed in version 2.0 of the provider. - -~> **Note:** `environment` must be set to the requested environment name in the list of available environments held in the `metadata_host`. - * `partner_id` - (Optional) A GUID/UUID that is [registered](https://docs.microsoft.com/azure/marketplace/azure-partner-customer-usage-attribution#register-guids-and-offers) 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 Environments - more information can be found [in the documentation for Providers](https://www.terraform.io/docs/configuration/providers.html#multiple-provider-instances).