Skip to content

Secrets Management Integration

Jump to bottom
aaboyle878 edited this page Jan 10, 2024 · 8 revisions

Secrets Manager


As our project is hosted using the azure cloud we will make use of the built in secrets manager Azure Key Vault for any sensitive data i.e. usernames, passwords and connection links, we will also then assign permissions to the managed-user account so that when deploy the app it can retrieve our secrets for the vault and successfully deploy the app.

Permissions granted

When granting access to the secrets manager we wanted to use the least access approach and as such have assigned the system managed identity the role of Key Vault Secrets Office meaning that the account can view the content of the secret but is unable to remove or edit the secret which ensures the secret won't be deleted by accident while aiding with the removal from hard coded values within the source code. we have also granted Key Vault Admin to ensure that the necessary permissions were in place to allow for the creation, versioning, editing and removal of the secrets from the key vault

Secrets Stored

The secrets we have chosen to store with the vault are:

  • DB Host
  • DB Name
  • DB Username
  • DB Password These are all values which will allow for a secure connection to be established to the DB while the use of Key Vault also removes the need to have hard coded values with the code ensuring that it is more secure.

Creating Managed Identity

As Part of integrating our AKS deployment with Key Vault we need a service user that would be able to authenticate with the Key Vault and retrieve the credentials that are stored there so we might use them to deploy and connect to the app.
The starting point of setting up this identity was to run the command az aks update --resource-group <resource-group> --name <cluster-name> --enable-managed-identity from here you will receive a prompt asking if you which to switch from a service principal to managed identity, when you enable the managed identity the next step will be to update the node pool for the cluster as when we run the previous command the kubelet will still remain on the service principal.
The command to update the nodepool is az aks nodepool upgrade --resource-group <resource-group> --cluster-name <cluster-name> --name <nodepool-name> --node-image-only this will trigger the nodepool of the cluster to be updated and will allow the update from service principal to managed identity to be applied to the kubelet.
Once our node pool has been updated/upgraded we then seek to find out the client id/principal if of the managed identity and this can be done using az aks show --resource-group <resource-group> --name <aks-cluster-name> --query identityProfile or az identity show --ids <identity-resource-id>
Once we have the identity profile information we can then assign a role to the identity in our case as previous stated we have assigned the role Key Vault Secrets Officer to the managed identity and as such to assign the identity we will use the command `az role assignment create --role "Key Vault Secrets Officer" --assignee --scope /subscriptions//resourceGroups//providers/Microsoft.KeyVault/vaults/
Once the previous command has been executed we can verify the role has been granted by checking the Role Assignment section of IAM within the Key Vault on the GUI and we should see our kubelet present with the Key Vault Secret Officer role as can be seen below. kubeletIdentity

Python Libraries

As part of enabling secure authentication via the secrets manage some updates need to be made to the initial Flask Web App and the requirements.txt that is used with the docker file.

  • requirements.txt
    For this file we need to add the packages we wish to download when the docker image is building.The changes we made here are adding:
    • azure-identity
    • azure-key vault-secrets requirements
  • app.py
    In the main application we import the required classes from the packages we have imported in this case they are:
    • ManagedIdentityCredential
      This class will allow for the retrieval of the the system managed identity we set up earlier and use it to authenticate with the cluster and the Key Vault to retrieve the secrets we require to connect the app to the host db
    • SecretClient
      This class contains the method/function we will use to access the content of the named secret that is passed as an agreement when it is called N.B. It is important when using the get_secret function that the name of the secret matches the one within the vault exactly otherwise it can cause issues with the deployment of the app e.g the deployment will fail due to pods being stuck in an error cycle. To retrieve the secret we will create an instance of the SecretClient Class which will have our Key Vault Host URL and the Managed Identity passed through as arguments.
    • key_vault_url This is the path that member accounts with the necessary access can use to view the content of the Key vault, in the case of our app the only account with this access is the Kubelet managed identity app.py_secrets_changes
Clone this wiki locally