It is not a secret that it is hard to manage sensitive information. Azure Key Vault allows you to securely store this kind of information ranging from secrets & certificates to cryptographic keys.
Great! But how do you use it? How do I authenticate with it and how do I build robust applications with it?
Come join me and I'll walk you through the challenges and give you some recommendations.
4. Nice to meet you
Tom Kerkhove
• Azure Consultant at Codit
• Microsoft Azure MVP & Advisor
• Belgian Azure User Group (AZUG)
blog.tomkerkhove.be
@TomKerkhove
tomkerkhove
6. Great! Let’s ship it?!
× No centralized secret management
× No secure storage for sensitive information
× No way to revoke access for a specific user/application
× No way to updating secrets when they have expired/been rolled
× No control over whom has access
7. Introducing Azure Key Vault
• Provides secure storage for sensitive information, including storing
cryptographic keys in hardware security modules (HSM)
• Automatically failing over to secondary region in read-only mode
• Allows you to :
• Store sensitive information as secret
• Use keys for cryptographical purposes
• Manage certificates
8. Keys & Secrets
• Secret
• Used to store sequences of bytes
• Consumers can read & write
secret values to it
• Encrypted before stored in vault
• Limited to 10 kB
• Typically used for connection
strings, authentication keys, etc.
• Key
• Stores a RSA 2048, 3072 & 4096 key
• Can be used to perform crypto
operations such as encryption &
signing
• Can’t be read back
• Higher latency
9. Different types of keys
• Software Keys
• Operations performed on VM in
Azure
• Typically used for Dev/Test
• Cheap
• HSM Keys
• Stored encrypted in HSM
• Operations performed on HSM
directly
• Requires Premium Vault
• More secure
15. Authenticating to Azure Key Vault
• Authentication is fully handled by Azure Active Directory
• Only works for the default Azure AD directory
• Use basic or certificate authentication
• However, you still need to store authentication information in your
configuration
private async Task<string> AuthenticationCallback(string authority, string resource, string scope)
{
var adApplicationId = configuration.Get<string>("KeyVault.Auth.ApplicationId");
var adApplicationSecret = configuration.Get<string>("KeyVault.Auth.AppSecret");
var authContext = new AuthenticationContext(authority);
var clientCredential = new ClientCredential(adApplicationId, adApplicationSecret);
var token = await authContext.AcquireTokenAsync(resource, clientCredential);
return token.AccessToken;
}
19. Great! Let’s ship it?!
✓ Control over whom has access
✓ Centralized secret management
✓ Secure storage for sensitive information
✓ Capability to revoke access for a specific user/application
✓ Capability to update secrets when they have expired/been rolled
× Keys to the kingdom are still stored as before
20. Enter Azure AD Managed Service Identity (MSI)
• Delegate authentication to the Azure resource that runs your app
• Azure Resource Manager will create & assign an Azure AD
Application to your resource
• Currently only supports system-defined
AD Application names
• Not all Azure services support this, yet
• No authentication information nor
authentication logic required
• Super easy and more secure
23. Great! Let’s ship it?!
✓ Control over whom has access
✓ Centralized secret management
✓ Secure storage for sensitive information
✓ Capability to revoke access for a specific user/application
✓ Capability to update secrets when they have expired/been rolled
✓ Authentication delegated to Azure
❕ Not all Azure services already support MSI
25. Authorization
• Managing vault instance (“control-plane”)
• Based on RBAC roles
• Managing vault contents (“data-plane”)
• Defined in “Advanced Access Policies”
• Granular control over assigned permissions
• Permissions defined on a vault-level
• Assigned to AD user, group or application
• Ie. only set secrets without being able to see them
27. Authorization
• Be careful about whom can manage your vault instance
• Take into account that people can add themselves to permissions to the
vault contents
• Use least-priviledge principle
• If they don’t need it, don’t give it to them
29. Great! Let’s ship it?!
✓ Secrets securely stored
× Everybody can access each others secrets
× Single point of failure
• Think about your security boundaries
• Vault level permissions – Be careful whom can do what
• Use multiple Key Vault instances if they have different security boundaries
• Use resource locks on your vault instance
• Prevent people from accidentally deleting all your secrets
33. Great! Let’s ship it?!
✓ Secrets securely stored
✓ Seperation of domains
× Not scalable
• Cache secrets
• Avoids hitting Azure Key Vault when scaling out
• Avoids unrequired network calls
• Use in-memory cache only and make it short-lived
• Your application should be aware of this
36. Great! Let’s ship it?!
× You cannot trust your vault consumers
× People leave the company, but what do they take with them?
× Leaked credentials are not being revoked
• Automatically generate new authentication keys
• Limits risk of leaked credentials usage
• (Azure) Automation is your best friend
• Your application should be aware of this
❕ You cannot do this with all secrets
❕ Be careful – Other applications might be using the same credentials
37. WebCache
Key: foo
Secret: ServiceBus
Name: ServiceBus
Secret: foo
Step 1: Generate new secondary key
Step 2: Update secret to use secondary key
Step 3: Generate new primary key
Step 4: Update secret to use primary key
Generate keys
38. Name: ServiceBus
Secret: bar
WebCache
Key: foo
Secret: ServiceBus
Name: ServiceBus
Secret: foo
Step 1: Generate new secondary key
Step 2: Update secret to use secondary key
Step 3: Generate new primary key
Step 4: Update secret to use primary key
Generate keys
Get uncached secret
Key: bar
47. Miscellanious
• Be transparent
• Secrets & keys are versioned, make sure that consumers are aware of these
• This is important for cryptographical scenarios where decryption needs to
use the correct version of the key
• Key Vault is not a configuration store
• You need to build your own configuration store
• Dependencies fail
• Make sure you handle downtime of your dependency, if possible at all
• Key Vault integration in VSTS
48. Managing secrets in VSTS
Variable Groups*
Build / Release
Environment
Built-in Task*
Inline**
* Integration with Azure Key Vault
52. Takeaways
• Security should not be an after thought
• It is about limiting the risk of exposure, not removing it
• Go Key Vault all the way, including build & release
• Do not use one central Key Vault, use one per security domain
• Delegate authentication to Azure with Azure AD MSI
• Automatically roll your secrets and keep your vault up to date