Secrets Management
Dalet Flex, like any other software, handles sensitive information. Whether it is passwords, SSL certificates private keys, encryption keys and third-party systems access keys, these are critical data that, if leaked, can compromise your system's security.
Ensuring that such sensitive information is stored in a secure way, which access would be limited to a limited set of authorized people is paramount.
Dalet Flex deployment framework enforces usage of encrypted secrets.
In order to do so, sensitive data (whether they are infrastructure-related with Terraform or configuration-related with Ansible) are stored as a YAML formatted list of key/value items in a locally encrypted vault file.
Master Key
As a tradeoff between agnosticity and security and to remain compatible with possibly Internet-disconnected (i.e. air-gapped) deployments, Dalet chose not to rely on specific third-party cloud-based key management systems (KMS).
Secrets are managed the following way instead:
- All sensitive key/value items are stored in a platform-specific local secret file.
- This file is encrypted with AES265 using a master key, making its content unreadable to whoever without knowledge or access to the said master key.
- The master key is to be dynamically provided at Terraform/Ansible deployment runtime stages to allow decryption (and then usage) of secret file.
- Ansible's tasks execution is configured to obfuscate any sensitive data output from runtime logs.
- The secret files, are stored AES256-encrypted, on platform's Git repository, allowing for version control and rollback/comparison, if/when required.
Secrets encryption can be done in 2 distinctive ways:
- Using Mozilla SOPS for Terraform input/output sensitive data.
- Using Mozilla SOPS or Ansible Vault for Ansible input sensitive data.
It is vital to understand that complete's platform security and secrets management relies on the master key management.
It is customer and operator's responsibility to ensure that this key remains safely stored and that its access remains limited to the required people only.
If the master key is to be compromised, all associated encrypted sensitive data will be as well.
One needs to acknowledge that master key is the only lock to your vault. If master key was to be lost, damage would be irremediable. There is NO WAY to recover encrypted sensitive data from the loss of master key and your whole system will be bricked.
Master Key Generation
It is good practice to use a different master key per system. Let's suppose that you are running both a staging and a production environments, different people might be involved in its day-to-day management and maintenance and using the same key to encrypt/decrypt sensitive data from both systems would be a rookie mistake.
Dalet OpsCtl allows you to easily generate a new set of master keys in a very secure way.
$ opsctl vault init
will create a new Ansible Vault master key for you and save it in the platform's key management system, if any.
$ opsctl secrets init
will create a new Mozilla SOPS master key for you and save it in the platform's key management system, if any.
Key Management Providers
As detailed in Platform Metadata section, every platform infrastructure and configuration as code comes with a root META.yml file, consumed by OpsCtl, describing various metadata about how the platform is to be managed.
Usage of OpsCtl allows you to offload the complexity of master key access, storage and retrieval by automatically connecting to the platform specific key management backend, as to be able to decrypt and encrypt secret files on the fly.
Platform's metadata secrets.provider variable will instruct OpsCtl how to manage master key access.
At the time of writing, supported secrets key management providers are:
- AWS Secrets Manager, which is the default, recommended choice.
- Hashicorp Vault, SaaS or private, as a recommended alternative.
- File based, which is absolutely unsecure and not recommended for production but comes in handy for specific kind of deployments.
- Usage input, where operator is required to provide the master key at each Ansible/Terraform invocation.
Again, storage of the master key is customer's operator responsbility.
Access to key management provider remains specific to each customer. Dalet heavily suggests SSO and MFA usage with nominative or group ACL authorization checks using third-parties like LDAP or Okta.
Working with secrets ...
OpsCtl being able to automatically retrieve master key from the selected key management provider, it comes in handy to quickly create, view or edit secret-encrypted files.
The vault sub-command makes it easy to interact with files.
$ opsctl help vault
Usage:
opsctl vault [command]
Available Commands:
create Create a new Ansible Vault encrypted secret file
edit Update/Edit an existing Ansible Vault encrypted file
encrypt Encrypt a specific file using Ansible Vault
get Get Ansible Vault secret
init Initialize a new Ansible-Vault master key
view View content of an existing Ansible Vault encrypted file
Editing your Ansible secret variables file is then as easy as:
$ opsctl vault edit ansible/vars/secrets.yml
which will, in-turn, decrypt it on the fly, open it in your favorite text editor (defined by $EDITOR environment variable), and encrypt it back once saved.
Encrypting a private-key SSL certificate file is even easier:
$ opsctl vault encrypt ansibles/files/cert.pem
The secrets sub-command makes it as easy to interact with files.
$ opsctl help secrets
Usage:
opsctl secrets [command]
Available Commands:
all Get All secrets from Secrets Manager
edit Create/Update/Edit a SOPS-encrypted file
encrypt Encrypt an existing plain-text file with SOPS
get Get SOPS public key
init Initialize a new SOPS private/public key pair
view Display content of a SOPS-encrypted file
with an equialent behavior to vault sub-command.