Authenticating as a Service Principal using a Certificate

[Phydeauxman]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Service Principals can be created to use a certificate versus a password. The certificate can even be generated by Key Vault and renewed periodically based on the policy it was created with. Would be a great addition to Terraform to be able to authenticate a Service Principal using the certificate stored in a Key Vault.

[tombuildsstuff]

hi @Phydeauxman

Thanks for opening this issue :)

So there's two feature requests here:

1. Updating the AzureRM Provider to support authenticating as a Service Principal via a Certificiate

This is something we want to do but I can't give a timeframe for it unfortunately; It's worth noting that the Azure Stack provider would also benefit from this change since it to supports authenticating as a Service Principal using a certificate.

2. Loading a Certificate from a Key Vault and using that to authenticate

There's a chicken-and-egg problem here in that you need to be able to authenticate against the Key Vault in order to be able to pull the certificate out; as such we don't plan to implement this directly. That said - you should be able to do this using the azurerm_key_vault_certificate requested in this issue once support for that has been added and issue 1 above has been fixed.

Since the second issue's already being tracked in #1455 I'm going to re-scope this issue to focus on the first issue - which is support for authenticating as a Service Principal using a Certificate.

Thanks!

[Phydeauxman]

@tombuildsstuff thanks for the detailed reply. Understand your position on #2 but we currently use a deployment framework where a User that only has User level permissions and Get,List perms on a Key Vault can run a Terraform deployment by executing a Powershell script as their persona which grabs the Terraform Service Principal password from the Key Vault and then executes the deployment as the Service Principal. Currently we generate complex passwords for Service Principals and store them in Key Vault but being able to use certificates in this scenario would be better as you are able to better manage them over passwords. And of course...certs are better than passwords :).

[tombuildsstuff]

@Phydeauxman that's one option, it should be possible to achieve the same thing both today (using a Service Principal via Password) and when Certificate auth is supported without the PowerShell script fwiw, since provider blocks can be interpolated from other resources (e.g. this example from testing #1564):

provider "azurerm" {
  alias           = "second"
  client_id       = "${azurerm_azuread_application.test.application_id}"
  client_secret   = "${azurerm_azuread_service_principal_password.test.value}"
  tenant_id       = "${data.azurerm_client_config.current.tenant_id}"
  subscription_id = "${data.azurerm_client_config.current.subscription_id}"
}

[Phydeauxman]

@tombuildsstuff interesting approach...will have to give that a try. Can you help me understand here what would happen with a provider configuration like that?

[tombuildsstuff]

that'll instantiate a second instance of a provider which can then be used as-so:

resource "azurerm_resource_group" "test" {
  name = "tom-second"
  location = "North Europe"
  provider = "azurerm.second"
}

it's worth noting the values must exist ahead of time (so loaded from a data source, for example) - but this allows you to chain providers together (e.g. provision a cluster using AKS and then use the Kubernetes provider to provision Pods, or something). (Whilst it won't work to create a Service Principal and then instantiate a Provider in the same run due a bug in Terraform Core, I'd expect that'll be fixed in the future)

[Phydeauxman]

@tombuildsstuff I guess the part that is confusing me are the 2 lines below:

client_id       = "${azurerm_azuread_application.test.application_id}"
client_secret   = "${azurerm_azuread_service_principal_password.test.value}"

Are these a thing? Are they documented somewhere?

[tombuildsstuff]

@Phydeauxman the client_id and client_secret fields are documented on the Provider page (along with some others). The azurerm_azuread_service_principal_password resource is a new (as-yet unreleased) resource which will be shipping in v1.10 of the AzureRM Provider.

[Phydeauxman]

@tombuildsstuff thanks...thought I was going crazy for a minute trying to figure out what azurerm_azuread_service_principal_password was.

[tombuildsstuff]

hey @Phydeauxman

Sorry for the delayed update here!

To give an update here: we've been trying to determine the best approach for how to refactor the Authentication functionality in this Provider for a while to enable this without introducing more complexity.

We've recently decided to split this authentication package out of this Provider and into it's own library; which means that it can be reused across the AzureRM Provider, the Azure Stack Provider and the AzureRM Backend (in Terraform Core). I've opened #2199 which refactors the Authentication logic out into it's own package - such that we'll be able to split it into it's own library in the near future.

Once that's done - given the way the authentication package is designed (insofar as each authentication method is self-contained & feature-toggled) - it should be fairly straightforward to add support for authenticating as a Service Principal using a Client Certificate. We've currently scheduled this work for v1.20 - by which time this split out library should be vendored into the projects outlined above.

As such - whilst I'm unable to give an exact timeframe for when this'll land, it should be in the not-too-distant future :)

Thanks!

[tombuildsstuff]

👋

To post a follow-up here: support for Client Certificate Authentication has been added in
this commit however it's intentionally feature-toggled off at this point. A prerequisite for enabling support for this is writing a new "how-to" guide for this Authentication method - so the rollout plan outlined above (as a part of v1.20) is still valid :)

Thanks!

[Phydeauxman]

@tombuildsstuff thanks for the follow-up info and the great work!

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!