Skip to Content

Secrets management

Last modified by Pekka Koskimäki on 2026/06/15 10:32
Contents

Secrets management

In general secrets can be divided into three categories

  1. Personal secrets
  2. Secrets shared by a team or group
  3. Secrets used by software/applications

Of these the first one is generally considered to be outside centralized secrets management, but the latter two should be kept safe.

The current guidelines for the University of Helsinki recommend using Azure Key Vaults for secret management for the latter two categories.

Personal secrets

The recommendation is to use a service that creates crypthographically secure passwords. Examples of this are Keepass and it's variations, and online services. The author of this page recommends a local solution over a cloud solution, but this also means backups fall on the user.

For more info about using keepass, check the helpdesk wiki site on it: https://helpdesk.it.helsinki.fi/ohjeet/tietokone-ja-tulostaminen/tyoasemapalvelu/salasanojen-hallintaohjelma-keepass

Secrets for teams and software

For all of these, secrets for different environments, or at least for prod and non-prod systems should be kept separate.

For secrets that are meant to be shared between humans, some easy solutions are listed below. For all of these, users are responsible for backups, versioning, key rotation, keeping their local copy up-to-date and secure sharing of possible main password. Thus, Azure Key Vault may prove easier to use.

WhatTechnoiogiesWhere to storeNotes
A shared file with a single secret that opens it.For example ansible-vault or keepass

git, onedrive, management server

Less secure than other options, but easier to use. The main secret could be stored in Azure Key Vault to make sharing it easier.
gpg-encypted pass that can only be opened by a list of peoplegpg (or gpg2) and passgit or management server

Requires technical knowledge, every time a secret is modified (deleted, added, changed) a new commit + encryption is required. Users need a separate way to share their most recent gpg public keys. May lead to git conflicts and issues when keys expire.

Better solution when the Secret can only be read by a known subset of identities

Information

Solutions like 1pass, firstpass etc should be avoided due to the combined costs possibly exceeding the University's allowed limits for products without open bidding. Or having multiple separate teams could be in violation of the license agreement, since many solutions require an organization with at least X users to enroll as an organization. 

Also having multiple solutions like this removes the ability for the university security teams to respond to security incidents. And having multiple separate solutions will lead to uncontrolled secrets sprawl.

For secrets used by software or machines, a central secrets management solution is preferable.

Since many programming languages support reading secrets directly from Azure Key Vault (and Kubernetes has external tools for this), needing to have the secrets locally should be avoided when possible. The Gitops and Secrets: State of the union talk from ArgoCon Europe 2026 mentions that most programming languages already have support for checking if a file containing the secrets changes, and how everyone should be reloading this file when the change happens so that secret rotation can happen automatically and seamlessly.