I am working with terraform to spin up different resource in azure. Some of those resources have sensitive data that I would like to store securely in aws secret manager.
Is this a doable process in terraform?
What it is confusing me is the following question:
To be able to access aws secret manager and spin up azure resources, should I have both provider declared in my terraform?
thank you very much for any advice and clarification you can offer
To be able to access aws secret manager and spin up azure resources,
should I have both provider declared in my terraform?
Of course, yes. You need to configure Azure provider and AWS provider for each one.
And I agree with Matt, if the resources have sensitive data, you can use the Azure Key Vault. then you can use only one provider and it will spend less time to get them.
Related
how to maintain encryption/decryption of Kubernetes Secrets in AKS. I referred this link https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ but as per this link https://feedback.azure.com/d365community/idea/ec780bf4-f724-ec11-b6e6-000d3a4f0da0 I am not sure whether this feature is available in Azure Kubernetes Service (AKS).
consider managing the secrets in azure key vault. Integrate AKS cluster with azure key vault to source the secrets when the pod is started.
Following link would be helpful --> https://medium.com/swlh/integrate-azure-key-vault-with-azure-kubernetes-service-1a8740429bea
I know with Azure Kubernetes service we can use managed identities to access azure resources like keyvaults. But i'm trying to learn if same procedure can be applied to a kubernetes cluster which is hosted on azure. My aim is to have kubernetes cluster in azure with 2 worker and 2 controller nodes but pods residing on those nodes should access azure keyvault with managed identity method similar to AKS. Is there anyway we can do it without coding in application?
I understand the scope of this question is big but it is really helpful if somebody provide any high level steps ?
thanks,
Santosh
That's totally possible. AAD Pod identities rely on AAD (Azure Active Directory) and its permissions.
At the end AKS will have an infrastructure behind the scenes. So if you plan to not use AKS but install a cluster by yourself, for example with AKS engine, you can use AAD Pod Identities / Managed Instances.
All you need is that those machines reside in "Azure" and rely on what is called Azure Instance Metadata Service (IMDS). Even you can enroll new machine instances coming outside from Azure with the project ARC. Anyway I cannot talk about it with Managed instances since I have not used it, anyway it should follow a similar pattern.
Here you have a good article that explains AAD Pod identities:
https://itnext.io/the-right-way-of-accessing-azure-services-from-inside-your-azure-kubernetes-cluster-14a335767680
I have a pipeline in Azure Devops building and pushing some images to DockerHub. These images are pushed to a production and development environment, but are also available for pulling for local development. For secrets in production and development in Azure we just use keystore and variable groups. However, we haven't found a good solution for injecting secrets when working locally.
For instance, in appsettings.json we have a ClientSecret parameter that is used for authenticating against Azure AD. How can we insert this parameter into appsettings.json during the release pipeline and not have it be visible to someone else later?
Some suggestions include using file transform in the pipeline, but this is not optimal as we don't really want to change any files. Another suggestion is using --build-arg in the pipeline, but these arguments become visible with docker history.
So how can I inject a secret into appsettings.json in a Docker image, and this secret should preferably not be visible anywhere at all?
As you have mentioned, with using File transforms a=nd variable substitution is a less configuration and quick approach.
Besides, you could also choose to use Azure Key Vault.
Azure Key Vault helps teams to securely store and manage sensitive
information such as keys, password, certificates, etc. in a
centralized storage which are safeguarded by industry-standard
algorithms, key lengths, and even hardware security modules. This
prevents information exposure through source code, a common mistake
that many developers make. Many developers leave sensitive information
such as database connection strings, passwords, private keys, etc. in
their source code which when gained by malicious users can result in
undesired consequences.
Access to a key vault requires proper authentication and authorization
and with RBAC, teams can have even fine granular control who has what
permissions over the sensitive data.
As for how to use Azure Key Vault in Azure DevOps, you could kindly refer below blog:
How to inject Azure Key Vault secrets in the Azure DevOps CI/CD
pipelines
Using secrets from Azure Key Vault in a pipeline
How to use docker image secret with Azure Key Vault, you could take a look at this link: Publishing a Single Image Docker Container with Secrets from VS2017 and Running it on Azure
More ways for your reference: 7 Ways to Deal with Application Secrets in Azure
I was reading https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview and midway through realized my brain was boiling.
Is there a more intuitive explanation to what it is and why it eliminates the need to store credentials in the source code?
Try https://azure.microsoft.com/en-us/blog/keep-credentials-out-of-code-introducing-azure-ad-managed-service-identity/.
You can think of it as if your Azure Resource (ie. a VM) is the identity. Say you want to access a blob in Azure Storage from your Azure virtual machine. One option is to create an AAD application and put the client id and client secret (password) into your code or configuration file. This is the problem that managed identities try to solve.
With a managed identity assigned to the VM, Azure knows that the VM has an identity, so your code just calls storage directly, using the token obtained from the managed identity. You don't need to store a client secret to get that managed identity token, because Azure already knows 'who' the VM is and allows it to use the managed identity implicitly.
I have several versions of the same web app running on the same subscription service.
I have 2 logical environments. Dev and UAT.
I have WebAppDev and WebAppUAT.
I have two key vaults KVDev and KVUAT.
How can I configure the correct web app to use the correct key vault?
What process assigns the web apps to key vaults?
Edit:
I had assumed that the key vault would act like the secrets do when developing.
This
Tutorial
seems to suggest that the key vault can be used as a configuration provider. However, the web app is not accessing the key vault values.
Get the Object ID from the identity blade of the web app.
Find your azure key vault and create a new access policy using the Object Id of web app.
Alternatively use the following in the powershell cli.
Set-AzKeyVaultAccessPolicy –VaultName -ObjectId "" -PermissionsToKeys backup,create,delete,get,import,list,restore -PermissionsToSecrets get,list,backup,restore,recover
Follow this tutorial and copy the context from the Program.cs in the sample code.
Tutorial
Taking a different angle, the current questions and comments tackle the authentication to KeyVault.
However, it sounds like a more fundamental problem and that you need to vary your configuration per environment.
i.e. WebAppDev needs to be configured to use a KVDev URL and WebAppUAT needs to use KVUAT URL.
Assuming you are using App Service Plans; this documentation provides a mechanism to store environment specific configuration along with guidance on how to use it for your programming language of choice, you will need to refer to the Application Specific configuration section.
https://learn.microsoft.com/en-us/azure/app-service/configure-common
Configuring in the portal will get you so far, but over time you will likely wish to contain the configuration in a release management pipeline so you don't need to configure things by hand. Azure DevOps Pipeline is one such tool for this:
https://learn.microsoft.com/en-us/azure/devops/pipelines/get-started/?toc=%2Fazure%2Fdevops%2Fpipelines%2Ftoc.json&bc=%2Fazure%2Fdevops%2Fboards%2Fpipelines%2Fbreadcrumb%2Ftoc.json&view=azure-devops
To get you started there is a specific deployment task which can aid in setting configuration for App Service Plans: https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/azure-rm-web-app-deployment?view=azure-devops
Over time I'd suggest rather than splitting configuration between a Release Pipeline and source control, instead having configuration which doesn't require deployment time modifications instead to stay source controlled in ARM templates, but that is an answer in it's own right so I won't confuse matters with too much detail.
If you want to access Azure key Vault by programming with SDK or REST API, then it would not be a problem. Because different key vaults have different DNS names. When you try to retrieve a secret or key in your code, you need to use its identify URL which contains its key vault DNS name. It will finally find the target key vault.
If you want to use key vault in web app with managed identity, you may refer to the tutorial: Use Azure Key Vault with an Azure web app in .NET
In that tutorial, you will enable the identity of a web app. And then you can assign access policy to that identity. In this way, the web app will be able to access the key vault with managed identity.