0

For an Azure Service Principal, we have below keys in config file

<add key="SubscriptionId" value="" />
<add key="ClientId" value="" />
<add key="ClientSecret" value="" />
<add key="TenantId" value="" />

Is there any azure key vault like service available, where we can securely keep these keys and use it based on demand?

Jaish Mathews
  • 766
  • 1
  • 9
  • 25
  • is this for the webapp or? – 4c74356b41 Feb 07 '18 at 18:27
  • 2
    Yeah, could you add more details on the setup? What services you are currently using etc. For Web Apps for instance there is a nice combination of Managed Service Identity + Key Vault to manage secrets. – juunas Feb 07 '18 at 18:31
  • OK. It's not for any PaaS service specific operation, but general management operation. I.e. Using management SDKs, create resource groups, storage accounts, VM etc...remotely. Also use terraform to do provisioning in azure etc...So general provisioning in azure than any specific PaaS operation. – Jaish Mathews Feb 08 '18 at 06:56

1 Answers1

2

The client secret is more important than the rest, which needs to be secure. Unfortunately, it is the gateway to call to your KeyVault even if you store it to KeyVault. There is not the only way to authenticate Azure AD with client secret. Instead of client secret, you can use your certificate when creating a key. Uploading that certificate will give you a thumbprint. You then need to upload your private key (aka PEM or PFX) somewhere in Azure, commonly in application or Azure App Service (ref https://learn.microsoft.com/en-us/azure/app-service/app-service-web-ssl-cert-load). Your application code just needs to read through the certificate (of course you need to set password for your certificate) and if thumbprint is matched, you are authorized by Azure AD.

Other sensitive information such as storage access key, database connection string, Redis cache key, VM password or your corporate certificate can be stored in KeyVault.

If you don't like the complex process to get access token, have a look at Managed Service Identity which lets an Azure service become a service principal itself. There is not a need for client app registration and client secret. MSI is currently in preview stage and available to some services.

EagleDev
  • 1,754
  • 2
  • 11
  • 31
  • I agree with Ng, and I blogged about storing [configuration data](https://mcguirev10.com/2017/12/23/easy-configuration-sharing-with-azure-key-vault.html) and [x509 certs](https://mcguirev10.com/2018/01/10/storing-certificates-azure-keyvault.html) as Key Vault secrets. Too much code for a comment. As long as the secrets-consumers are authorized to use Key Vault via MSI (ie. server-side calls to retrieve keys), you need only store the non-sensitive Key Vault URI in consumer-local config. – McGuireV10 Feb 08 '18 at 12:53