The IP address 169.254.169.254 is a special address for the Azure Instance Metadata Service (IMDS). It’s used to retrieve information about the Azure VM instance, such as access tokens, which can be used to authenticate requests to services like Azure Key Vault. This IP address is only available inside Azure VMs.

Since your applications are deployed on both Azure VMs and on-premise VMs, this can be a challenge because 169.254.169.254 is only accessible from Azure VMs, not from external machines. For on-premise VMs, you should consider using other authentication methods like client secrets or certificates, which can be configured through Azure AD.

Here are the basic steps to retrieve secrets from Azure Key Vault using the REST API:

Authentication: If the app is running on an Azure VM, you can use IMDS to obtain an OAuth 2.0 token from Azure AD. Otherwise, for on-premise VMs, you can use a client ID and client secret or a certificate.

Example of retrieving a token with curl:

curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://vault.azure.net' -H Metadata:true

Requesting secrets: Once you have the token, you can make a REST request to access secrets from Azure Key Vault.

Example of a request using the token:

curl -H "Authorization: Bearer <token>" https://<your-vault-name>.vault.azure.net/secrets/<secret-name>?api-version=7.0

If you are looking for examples of integrating Azure Key Vault with a .NET 4.5 application, unfortunately, .NET Framework 4.5 doesn’t have built-in support for Azure Key Vault. However, you can manually make HTTP requests to Azure Key Vault’s REST API using classes like HttpClient in .NET.

The IP address 169.254.169.254 is a link-local address commonly used for communication between devices on the same local network without requiring a DHCP server. In the context of Azure, this address is used to access the metadata service for Azure VMs.

Security of Using 169.254.169.254
Limited Access: The address is accessible only from the VMs themselves. This means it cannot be reached from the internet or other networks, which is a positive aspect for security.

Sensitive Information: Accessing the metadata endpoint can retrieve sensitive information, such as credentials and access tokens. Therefore, it is crucial to handle this data carefully.

Best Practices for Security
Limit Access: Ensure that only authorized processes and users within the VM can access the metadata.

Use Managed Identities: Utilize managed identities for accessing Azure resources, reducing the need to manage credentials manually.

Monitoring and Logging: Implement monitoring and logging to track who accesses the metadata and when.

Updates and Patching: Keep the operating system and applications updated with the latest security patches.

Network Configuration: If possible, limit the exposure of the VMs to the internet by using Network Security Groups (NSGs) to filter incoming and outgoing traffic.

Documentation
Unfortunately, there does not appear to be detailed official documentation from Microsoft specifically regarding the use of the IP address 169.254.169.254 for Azure VMs. However, you can find general information about Azure VM metadata in the official Azure documentation, which explains how to use this endpoint to access instance metadata.

If needing to do this in code for Framework 4.5, then it’s perhaps worth knowing there are a couple of deprecated nuget packages that should allow you do the job.

• Microsoft.Azure.KeyVault
• Microsoft.IdentityModel.Clients.ActiveDirectory

Note: Deprecated in MS parlance means no longer in development.

Provided you have Set up the Vault, registered an App in Azure-AD, and granted access to the vault from the app, then it should essentially be a case of requesting a key-secret from the vault, using the app-name, app-key and key-name.