Azure Key Vault (WIP)

Azure Key Vault is a service found in the Azure portal (portal.azure.com). It can be used to store secrets in addition to other sensitive material.

Basic principles

Azure Key Vault is an online service, so to use it both the users and possible automation need to access portal.azure.com.

The list price for the service is ~0.03 €/10 000 secret operations

• This means around 0.30 € per year if one secret operation is done every 5 minutes.
  • In comparison, most self hosted options are hundreds per user.
• Certificate renewals and operations for advanced key types are more expensive.
  • https://azure.microsoft.com/en-us/pricing/details/key-vault/

Access management

Access management is done in tiers

• Subscription
  • A high level concept used for billing.
  • Contains resource groups.
• Resource group
  • Container inside which resources in Azure are created. Only Microsoft 365 admins can create these.
  • Resource groups are also used for cost management, especially in cases where a single resource group ends up costing more than normal.
• Key Vault (resource)
  • Container for secrets.
• Secret
  • Single secret, like a password.

PIM or Privileged Identity Management: A way for authorized users to temporarily activate higher than normal permissions

• This enables users to have just-in-time privileged access, instead of everyone always being an admin
• PIM is used to create and manage Key Vaults within a resource group.

Access Control (IAM): A per resource way to configure access to this resource

• E.g In an existing Key Vault:
  • User A can always create new secrets and edit the contents of existing secrets
  • User B can only use existing secrets, but can't do writes or deletes
• Instead of using privileged access tied to personal accounts, using group memberships is preferable if proper RBAC is upheld with groups.
  • Azure has all of the group memberships from IAM (idm.helsinki.fi)

Commonly used privileges (Azure roles)

• Key Vault Contributor
  • Only for managing Key vaults.
• Key Vault Data Access Administrator
  • Managing permissions inside Key Vaults.
• Application Developer
  • Allows creation of service principals, which are used by the applications to access secrets.
• ​​​​​Key Vault [Certificate/Crypto/Secrets] Officer
  • Allows management of specific resource type in the Key Vault, excluding access control.
• ​​​​​Key Vault [Certificate/Crypto/Secrets] User
  • Allows reading of specific resource type in the Key Vault.
• More info in the Microsoft Learn.

Technically O365 have the ability to gain access to all key vaults for the University.

• This is mentioned for clarity, but can be disregarded. This is the same as not trusting the database admins, linux admins or any other group managing a service in the University.
• When checking the access to a Key Vault, you will see the names of Microsoft 365 admins.

Microsoft recommends creating a separate Key Vault for each environment. More data in Best practices for using Azure Key Vault

Ordering a resource group

Each resource group's costs will be directed towards their appropriate unit/team as necessary. In order to do this, resource groups should clearly denote who owns the group and what it is used for. Because of this, the chosen naming convention is UNIT-TEAM-SERVICE. For example, Flamma that is managed by Verkkopalvelut (Vepa), which is a team in Tietotekniikkakeskus (Tike) would have a resource group called Tike-Vepa-Flamma. If a key vault is needed for non specific secrets, the name would be Tike-Vepa-General.

A resource group can be requested by sending an email to helpdesk@helsinki.fi The format of the email should be something like

Instead of single admin users, an idm-group can also be used. Helpdesk instructions for ordering an admin account

During the resource group order, the ability to create Service Principals can be requested by listing the users who need the role Application Developer

Key Vault Management

Every higher access option in portal.azure.com starts with PIM or Privileged Identity Management.

PIM

• In the portal search for PIM and click on Microsoft Entra Privileged Identity Management.
• Click "Activate" under "Activate just in time".
• From the left bar click "Azure resources" under Activate
  • Use the filter if necessary to narrow down to just a single resource group
  • Activate Key Vault Contributor when creating new vaults or editing/deleting existing vaults
  • Activate Key Vault Data Access Administrator when editing access to new or existing vaults
• After activating privileges, type in Key vault to the search bar and go to Key Vaults

Creating a key vault

(For users needing HSM keys, please request help by contacting the help desk if no information is available.

Click create and fill the form, below are the most commonly filled fields

After filling the form, click Review + Create and proceed with creating the Key Vault. If successful, you will be directed to the overview page of the created Key Vault.

Managing Key Vault Permissions

After activating Key Vault Data Access Administrator in PIM, head to Key Vaults and click on the Key Vault being managed.

Head to Access control (IAM) -> Role Assignments -> Add Role Assignments. Key Vaults may contain Secrets, Certificates or Cryptographic Keys, and there are pre-existing roles for each. The roles most commonly used are Officer and User for each section of a Key Vaults contents.

• Officer
  • Read, write, delete
• User
  • Read only

Choose the Role -> Next. Assign access to User, group or service principal. Then from + Select members a search bar opens, where both University accounts and iam-groups can be searched for. Multiple people and/or groups can be selected for a single role. A description should be added, for example "Adding read access for members of the project" or "Adding lead developer XXX XXXX as a Secret officer". These will be helpful down the road, especially when new members are onboarded or if misuse is identified.

Using Azure Key Vaults

The usage of Azure Key Vaults can be done by people, either using the az-client or the GUI. For Automation needs, read AWX/AAP

Using the GUI

Once inside a chosen Key Vault, choose Objects -> Secrets from the left bar. Secrets can be added, deleted or viewed from here. Similar options available for crypto and keys.

Using the az-client

https://learn.microsoft.com/en-us/cli/azure/keyvault?view=azure-cli-latest

Key Vault Automation

These instructions are still a work in progress, and will be linked here once available.

Authentication into Azure Key Vault for automation will be done using Service Principals. If you didn't request the Application Developer role in Azure while ordering a Resource Group, request one from Helpdesk.

• Ansible Automation Platform/AWX
  • native integrations
• Kubernetes
  • External Secrets operator or Secrets Store CSI driver

Creating a Service Principal

To create a Service Principal, your account must have the Application Developer role in Azure. If you do not have this role, contact the helpdesk to request it for your admin account (and the admin accounts of necessary other members of your team).

Go to PIM (Privileged Identity Management) and activate the role "Application Developer". Then in the Azure portal search for "App registrations", then create a new one. Remember to keep naming consistent with the convention "hy - <department> - <sovellussalkku_id> - <extra_info>.
The department should be it's most commonly used shortname, e.g. tike for tietotekniikkakeskus or cs for computer science department. If a shortname has not been used before, prefer a shortname comprised of the english name without the word 'department'".

Examples would include hy-tike-0001442-awx, hy-kk-0002345-backup-automation and hy-cs-00001234-openshift.


Also remember to create a credential secret so that you can use the Service Principal in your automations. The default secret lifetime is recommended.

You can also create the Service Principal / App Registration using the az client after logging in with az login. In this case, a credential secret will be created and posted to your terminal.

Then give the created application the required access as described in managing permissions

Renaming a Service Principal/Application

An App registration can be renamed from it's page by click Manage -> Branding & properties. At the top the name can be changed. You can also add internal notes at the bottom of this page.

Giving others management access to a Service Principal

Go to manage -> Owners -> Add owners. This is only supported for user accounts at the time of writing.

https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions#owned-application-registrations

Security considerations

Having a single resource group per logical unit, e.g. application, team, use case etc and then having a separate key vault per ENVIRONMENT (e.g. test, prod, dev) is enough. Separate resource groups are not required.

Service Principals and other machine access to vaults spanning multiple environments should be avoided when possible.

The Roles used for permanent memberships in a single Vault should be limited to

• Key Vault [Certificate/Crypto/Secrets] Officer
• Key Vault [Certificate/Crypto/Secrets] User

Also these Roles should be based on RBAC and not tied to singular users.

Key Vault and single key soft deletions should be turned on.