Using Secrets in Userdata

Do you want to use Secrets in your userdata, but you are worried about them being exposed on the venue-side? Read on...

First Things First

In Tuono, we use the term userdata to describe the post-configuration code that needs to be ran when your infrastructure is instantiated. This may be variously referred to as user data (AWS) and Custom Data (Azure). Currently, we support the use of BASH, Powershell shells, as well as cloud-init in your userdata scripts.

Userdata is the perfect way to run your post-configuration setup/bootstrapping, but unfortunately, it cannot be used to supply secure data as this is presented in plain text within the venue. To resolve this, we need a mechanism to pass Tuono Secret data in to the secure secret vault of the venue, and then recall that information in the body of the userdata. This is to ensure that the secure data is never leaked.

NOTE: userdata is stored in plain text on the venue side

Luckily, we have a Tuono native method to interface with our Secret Vault and push secrets in to the native vault mechanism of the vendors, Parameter Store (AWS) and Key Vault (Azure). To retrieve these values, you can use well-documented methods to retrieve this data within userdata, ensuring that it is not leaked throughout the process. For our example, we'll be using Azure, pushing a Tuono Secret to the Azure Key Vault, and then retrieving it within our userdata.

Code

In this example, I am passing the Secret appliance_password to the blueprint,

variables:  
  appliance_password:
    type: secret

In the secret stanza, Tuono is creating a Key Vault called appliancepassword and a secret called appliancepassword. We are passing the Secret variable defined above as the value of this Key Vault entry.

security:
  secret:
    appliancepassword:
      value: (( appliance_password ))
      venue:
        azure:
          key_vault_name: appliancepassword

In the compute stanza, we are instructing Tuono to create an appropriate Azure Managed Identity which will allow the created VM to authenticate the the Key Vault and access the stored appliancepassword secret.

compute:
  vm:
    key-vault-example:
      ...
      configure:
        secrets: appliancepassword

Userdata

OK, that's all fine and well. We have our Secrets stored in the Key Vault, and we have our Managed Identity. What now?

In this example I used .NET as I found this to be extremely reliable, right back to Windows 2008 R2. You can use Powershell just as easily.

Here in these 12 lines, we make an API call to the internal address 169.254.169.254, which will then grant us a Bearer Token. This leverages the Managed Identity we created above to authenticate the VM.

With this token, we can then authenticate against the Key Vault itself, by passing the token as the header in the next call to the Key Vault. In this case we simply write the value out to file, but the $value variable can be used for other code that needs to leverage this secret.

Note the correct URL for the call:

https://**<keyvault>**.vault.azure.net/secrets/**<secret_name>**?api-version=7.1

$Client = New-Object System.Net.WebClient
$Client.Headers.add("Metadata", "true")
$Uri = 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https%3A%2F%2Fvault.azure.net'
$access_token = ($Client.DownloadString($Uri) | convertfrom-json).access_token

$Client = New-Object System.Net.WebClient
$Client.Headers.add("Authorization", "Bearer $access_token")
$Client.Headers.add("Accept", "application/json")
$Uri = 'https://appliancepassword.vault.azure.net/secrets/appliancepassword?api-version=7.1'
$value = ($Client.DownloadString($Uri) | convertfrom-json).value

Write-Output "The secret value is: $value" | Out-File -FilePath 'C:\output.txt'

Closing Remarks

Hopefully you can see how powerful this is. What we have done here is effectively create an ephemeral Key Vault in which we store the Tuono Secret as a native Key Vault Secret for later retrieval. That is to say, a secret that is logically scoped to this environment, only accessible to this VM and created and destroyed in lockstep with the Tuono Environment. This means that you don't need to manage multiple secrets in multiple places, but rather, you can centralise them in the Tuono Secret Vault, leverage them wherever they are needed and clean them up when they are no longer needed, automatically.