Keeping Secrets: State of the Union - Evgenij Smirnov - PSConfEU 2023

In this session, we delve into the topic of secret management. As someone coming from a security background, I emphasize the importance of designing systems that are secure from the start to prevent leaks and breaches. Our organizations face constant threats from attackers, and secrets like passwords and application tokens serve as vital safeguards for our systems. We explore different types of secrets and reference architectures, including the use of secure strings and XML files for encryption. The main objective is to prevent malicious actors from gaining control of our machines and to strive for improved software architectures.

Moving on to the conversation, we focus on two use cases related to secret management. The first scenario involves an operator who possesses access to secrets and utilizes them for authentication with cloud services. This can prove challenging as the operator assumes sole responsibility for managing these secrets. If the operator's workstation is separate from Active Directory and they do not log in with an Active Directory account, we consider the second mentioned software architecture as secure. However, when the goal is to share scripts with colleagues or publish them on platforms like GitHub, secret management becomes necessary.

To address this challenge, we discuss how secret management abstracts the process of safeguarding secrets from the specific vault technology being used. To illustrate this concept, we demonstrate the usage of the Microsoft PowerShell secret management module with a KeyPass vault. We provide guidance on installing the required modules and registering the vault. Once connected, we extract a vSphere credential stored in the vault.

While secret management greatly enhances interactive PowerShell usage, we approach it from an automation perspective, where scripts need to authenticate to other systems without exposing user credentials. We present two use cases: self-service automation scripts that interact with user profiles and scripts that need to run on multiple machines. However, we also acknowledge the challenge of managing secrets when they change and discuss the limitations of scripting hosts in terms of providing secure access to secrets. Our objective is to provide a PSCredential object to a script.

To address the need to provide credentials to a script rather than the machine or user running the script, we propose integrating a secret vault with a script host. This integration validates the script's identity, integrity, and the caller's credentials before executing the script with injected credentials. To illustrate the concept, we create a small mock-up using a SQLite database to store script information and perform checks. Securing this process can be challenging, but we suggest that third-party tools like ScriptRunner and Automator should provide validation before passing stored credentials to scripts.

Furthermore, we discuss the possibility of implementing a trusted host design using Windows' protected service mechanism or a service running as a system. We also mention the use of certificate-based authentication and secrets distribution to enhance security in handling certificates. We explain how self-signed certificates with the necessary key usage OID can be created using an enterprise PKI or Microsoft's PKI. The self-signed certificates work similarly, with the advantage of auto-enrollment from Microsoft's PKI, ensuring the private key is never exposed during the process.

To deliver a secret using this system, we create a vault that holds the clear text of the secret. The user acquires a document encryption certificate and provides the public key to the vault admin. The admin, who never sees the private keys, can extract the secret using secret management with the vault and protect it using the CMS message with the public key. This ensures that only end entities with the private key can decrypt the secret.