Please let me know how to backup Azure WAF Resource Configuration/settings. I am not able find anything related to waf backup setting/configuration.
Go to Application Gateway -> Export Template
The template contains all configuration/settings for your WAF
I appreciate this question is a little old now - the answer already given and accepted is technically valid but note that any export of an Application Gateway you do that uses "SSL Certificates" will not include the certificates in the export.
So if you were to try and re-create the Application Gateway from the exported JSON, it will probably not work and may need additional configuration to re-import the SSL certificates referenced by listeners.
For information, you can also use the Export-AzResourceGroup cmdlet to export your App Gateway but this too does not include the SSL certificates.
A fairly recent (end of 2020) addition which alleviates this to some extent is the ability to pass a reference to a Key Vault certificate but this requires a User Assigned Managed Identity to be associated with the Application Gateway which has permissions to access the certificates and secrets (if they had passwords when added to the Key Vault).
Create a user-assigned managed identity - look for Managed Identities in the Azure Portal.
Configure your key vault - this basically means add permissions to the Key Vault for the Managed Identity to be able to manage certificates and read secrets.
Configure the application gateway. Use the Set-AzApplicationGatewayIdentity cmdlet to assign the UA-MI account's ID to the Application Gateway.
The instructions above are abbreviated from this article (which I'll get grief for adding, but I'm not regurgitating documentation here for the sake of it): https://learn.microsoft.com/en-us/azure/application-gateway/key-vault-certs
Remember that I said the key vault integration alleviates the issue to some extent. Using references still doesn't resolve the issue completely as I believe there are still some pieces of secret information omitted from exports which would be needed to fully re-create the Application Gateway in a working state.
Related
In Azure you can setup an App Config and a KeyVault. The point of the KeyVault being to store more sensitive data than your App Config and be able to regulate access to the config and vault separately.
So what is the benefit of using a keyvault reference in the app config?
You are basically allowing anyone with access to the app config to access certain values in your keyvault and are bypassing the additional layer of security the vault normally provides.
The additional layer being required auth to the vault to access those same values if they aren't referenced in the config.
I really don't understand what benefit keyvault references give you.
This blog article by Jan de Vries explains them in more detail: https://jan-v.nl/post/2021/using-key-vault-with-azure-app-configuration/.
The relevant part for your question:
As it happens, the code for accessing App Configuration doesn’t give your application permission to retrieve secrets from Key Vault.
The application retrieves them from Key Vault, not from App Configuration.
App Config only holds the reference, not the actual value.
Official docs also mention this:
Your application uses the App Configuration client provider to retrieve Key Vault references, just as it does for any other keys stored in App Configuration. In this case, the values stored in App Configuration are URIs that reference the values in the Key Vault. They are not Key Vault values or credentials. Because the client provider recognizes the keys as Key Vault references, it uses Key Vault to retrieve their values.
Your application is responsible for authenticating properly to both App Configuration and Key Vault. The two services don't communicate directly.
I suppose there are different approaches to using the KeyVault, but the way I tend to use it is as follows.
My application will have a set of secrets, which I store locally using the Secrets Manager, you would add the secret for your application:
dotnet user-secrets set "Movies:ServiceApiKey" "12345"
Your application can then read this setting using _moviesApiKey = Configuration["Movies:ServiceApiKey"]; as you'll see in the link above. Obviously, there's no way you can see this value in the code, but your application can read it from the Secrets Manager.
If you do forget the values, you can use the following command to retrieve them:
dotnet user-secrets list
KeyVault will work as your Secrets Manager within Azure. So, your application will need to have permission to access the KeyVault, and in my case I store the Vault name in the appsettings.json, and during the bootstrapping, I include the KeyVault configuration if running in Production mode i.e. on the Azure Server and not locally.
public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.ConfigureLogging(logging =>
{
logging.ClearProviders();
logging.AddConsole();
logging.AddAzureWebAppDiagnostics();
})
.ConfigureAppConfiguration((context, config) =>
{
if (context.HostingEnvironment.IsProduction())
{
IConfigurationRoot builtConfig = config.Build();
ConfigurationBuilder keyVaultConfigBuilder = new ConfigurationBuilder();
keyVaultConfigBuilder.AddAzureKeyVault(builtConfig["VaultName"]);
IConfigurationRoot keyVaultConfig = keyVaultConfigBuilder.Build();
config.AddConfiguration(keyVaultConfig);
}
})
.UseStartup<Startup>();
Note, the check for context.HostingEnvironment.IsProduction(). Within the appsettings, I have:
"VaultName": "https://yourkvname.vault.azure.net/"
So, the only reference I have to the KeyVault from the application is the name, and that should be secure as only the application will have access to the keys/secrets.
One thing to note, you need to make sure that the names match both for your local secrets and the ones in the KeyVault. In my case, I am running on a Windows platform, so I needed to make a small change to the names using double dashes (--) in place of the colon (:), so...
Movies:ServiceApiKey
Becomes
Movies--ServiceApiKey
When working in Azure, storing secrets in Key Vault is a good idea. And to make it better, there’s the Key Vault Reference notation. This feature makes sure no one can read the secret(s) unless someone grants permission.
Speaking of secrets, they should never be directly stored in application settings of a Function App (same goes for App Services by the way). Why not ? Because secrets would be available to anyone who has access to the Function App in the Azure Portal. The right way is to use an Azure Key Vault which is the Azure component for securely storing and accessing secrets 🔒. Once your secrets are in the key vault, you have to grant the Key Vault access to the identity of your Function App and you can then reference the secrets you need directly in your application settings. These are called Key Vault references because an application setting does not contain directly the value of a secret but a reference to the secret which is stored in Key Vault. When running, your function will automatically have access to the secret and its value as an environment variable, as if it was a normal application setting.
Key Vault references work for both App Services and Function Apps and are particularly useful for existing applications that have their secrets stored in settings because securing the secrets with Azure Key Vault references does not require any code change.
Reference: https://www.techwatching.dev/posts/azure-functions-custom-configuration
https://www.sharepointeurope.com/using-key-vault-references-with-azure-app-configuration/
We deploy a Linux App Service to Azure using terraform. The relevant configuration code is:
resource "azurerm_app_service" "webapp" {
app_settings = {
DOCKER_REGISTRY_SERVER_URL = "https://${local.ctx.AcrName}.azurecr.io"
DOCKER_REGISTRY_SERVER_USERNAME = data.azurerm_key_vault_secret.acr_admin_user.value
DOCKER_REGISTRY_SERVER_PASSWORD = data.azurerm_key_vault_secret.acr_admin_password.value
...
}
...
}
The problem is that terraform does not consider app_settings a secret and so it outputs in the clear the DOCKER_REGISTRY_SERVER_PASSWORD value in the Azure DevOps output (I obfuscated the actual values):
So, I am wondering - can docker running on an Azure Linux App Service host authenticate with the respective ACR without us having to pass the password in a way that makes it so obvious to every one who can inspect the pipeline output?
The following article seems relevant in general - https://docs.docker.com/engine/reference/commandline/login, but it is unclear how we can apply it in my context, if at all.
Also, according to https://feedback.azure.com/forums/169385-web-apps/suggestions/36145444-web-app-for-containers-acr-access-requires-admin#%7Btoggle_previous_statuses%7D Microsoft has started working on something relevant, but looks like this is still a work in progress (almost 5 months).
I'm afraid you must set the environment variables about DOCKER_REGISTRY_* to pull the images from the ACR, it's the only way to do that designed by Azure. But for the sensitive info about the password, it also provides a way to hide it. You can use the Key Vault to store the password in secret, and then get the password from the secret. Take a look at the document Use Key Vault references for App Service. So you can change the app_setting for the password like this:
DOCKER_REGISTRY_SERVER_PASSWORD = "#Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret/ec96f02080254f109c51a1f14cdb1931)"
Or
DOCKER_REGISTRY_SERVER_PASSWORD = "#Microsoft.KeyVault(VaultName=myvault;SecretName=mysecret;SecretVersion=ec96f02080254f109c51a1f14cdb1931)"
Then it just shows the reference of the Key Vault, not the exact password.
Unfortunately Azure Web Apps do not support interacting with ACR using a managed identity, you must pass those Environment Variables to the App Service.
Terraform does not currently support applying a "sensitive" flag to arbitrary values. You can define outputs as sensitive, but it will not help with values you want to hide during the plan phase.
I would suggest checking out https://github.com/cloudposse/tfmask, using the TFMASK_RESOURCES_REGEX configuration to block the output you want to hide during your pipeline. If you're averse to adding dependencies, similar effect could be achieved by piping terraform apply through grep --invert-match "DOCKER_REGISTRY" instead.
#charles-xu has a good answer as well if you want to set up mappings between keyvault and your web app then push your tokens into kv secrets.
Now it's possible to use managed identity to pull images from ACR.
You may do the next:
go to your Container Registry page in the Azure portal
Open the tab Access Control (IAM)
The open Role assignments tab
Add role assignment AcrPull to your App Service or Function App
In the Deployment Center of your App Service choose Managed Identity for the Authentication setting.
Or you may use CLI by following the steps from the official documentation (link below):
https://learn.microsoft.com/en-us/azure/app-service/configure-custom-container?pivots=container-linux#use-managed-identity-to-pull-image-from-azure-container-registry
After you added role assignment DOCKER_REGISTRY_SERVER_URL, DOCKER_REGISTRY_SERVER_USERNAME and DOCKER_REGISTRY_SERVER_PASSWORD settings may be removed from App Service's App Settings.
I was trying to get the connection string from the azure key vault for azure functions. These are the steps I did,
Created a managed identity(System assigned) in the azure functions
Create a secret in an azure key vault
Add access policies to give permission to the azure function app
Added an entry in the app settings for connection string where the value was #Microsoft.KeyVault(SecretUri=SECRETURLOFKEYVAULT)
But when I run the azure function I am getting below error,
"Keyword not supported: #microsoft.keyvault(secreturi....."
This is how I have enabled managed identity,
And my access policy looks like below,
Any help would be much appreciated
I ran into a similar problem by following the tutorial. My remedy was a restart of the function app. Saving of the app setting was not enough for the Function App to start using the Key Vault secret provider correctly.
According to the steps you provided, it have no problem to work well. Here is the tutorial about get key vault secrets in Azure Function you could refer to.
Note: Add access policies to the azure function app with the Get permission on secrets and that was enough.
Also, here is a similar issue that get same error like you which is due to IP Address restriction blocking it.
This issue occurred while testing on local. It was resolved after doing an az login.
I have gotten a Redhat OpenShift online starter vps, for hosting my discord bot. I've uploaded it to github, minus my discord token and other API keys, of course :^)
How would I get OpenShift to use store and read client secrets?
I'm using the nodejs8 framework if that helps.
Secrets have no place in a source version control hosting service like GitHub.
Regarding OpenShift, it includes Secrets, an encoded-64 configmap in which you can inject confidential information.
But that long-term confidential information storage (to be injected in OpenShift secrets) ought to be stored in a proper Vault.
Like, for instance, the Hashicorp Vault, as described by the article "Managing Secrets on OpenShift – Vault Integration"
The rest describes that solution, but even if you don't use that particular host, the general idea (an external vault-type storage) remains:
An Init Container (run before the main container of a pod is started) requests a wrapped token from the Vault Controller over an encrypted connection.
Wrapped credentials allow you to pass credentials around without any of the intermediaries having to actually see the credentials.
The Vault Controller retrieves the pod details from the Kubernetes API server.
If the pod exists and contains the vaultproject.io/policies annotation, the Vault Controller calls Vault and generates a unique wrapped token with access to the Vault policies mentioned in the annotation. This step requires trust on pod author to have used to right policies. The generated token has a configurable TTL.
The Vault Controller “calls back” the Init Container using the pod IP obtained from the Kubernetes API over an encrypted connection and delivers it the newly created wrapped token. Notice that the Vault Controller does not trust the pod, it only trusts the master API.
The Init Container unwraps the token to obtain a the Vault token that will allow access to the credentials.
The Vault token is written to a well-known location in a volume shared between the two containers (emptyDir) and the Init Container exits.
The main container reads the token from the token file. Now the main container can use the token to retrieve all the secrets allowed by the policies considered when the token was created.
If needed, the main container renews the token to keep it from expiring.
I'm using a Azure Resource Manager(ARM) template to create and update a resource group in a release definition in Visual Studio Team Services(VSTS). I'm using the same template to upload the .pfx certificate to the web app.
For the first deployment the certificate got uploaded perfectly, but from the next deployment the deployment fails with the error "Another certificate exists with same thumbprint ******** at location West US in the Resource Group MyResourceGroup".
I tried recreating the webapp, but to my surprise the deployment fails for the first time itself. Looks like the certificate got uploaded to the resource group.
Is there a way to overwrite the existing .pfx certificate for every deployment.
You do not have to upload certificate for all deployments. The first certificate will become available to all deployments
Certificates are exposed at the resource group level, so deploying the same certificate again will definitely error out.
However, I don't see a reason as to why you need to upload a certificate.
Does your application need to read this certificate? if yes, then there is a different way to do this. See this article:
https://azure.microsoft.com/en-us/blog/using-certificates-in-azure-websites-applications/
Until today I had never encountered this error. I have been able to redeploy my applications, certificates and all, with no issues. I believe in my case that someone had previously manually added the certificate using a different name, possibly through the portal, and then when my pipeline executed it attempted to add the certificate using a different name.
Certificates are child resources of Microsoft.Web under the resource group. There are likely a number of options for resolving but I am going to focus on removing the certificate using Resource Explorer. (I bet that there is a Azure CLI or Azure PowerShell command to do this too.)
In resource explorer, locate the certificates node associated with your resource group using the left hand navigation pane. This will likely be in something like subscriptions -> {subscription name} -> resourceGroups -> {resource group name} -> providers -> Microsoft.Web -> certificates -> {certificate name}
Once located, select your certificate and then can use the Actions (POST, DELETE) tab in the right hand pane to delete the certificate. You should then be able to redeploy.