Just bringing my thoughts to this list; The OpenStack Summit Talk (https://youtu.be/6cjepMGQfrM?t=883) shows a proof-of-concept where they're able to use Barbican to protect glance.conf ( or any-other.conf ) passwords; but someone ask the winning question (I have linked to the exact time) which is "How does one then protect the Barbican or Vault?" The answer given ( I believe by Tin Lam?) pretty much hits the nail on the head - this leads to a chicken-and-egg issue - since Barbican or Vault must be accessible to the hosts/services which have the configuration files, then anyone who can see the configuration files' contents can then take the next logical step and ask the secret provider for the secret, using whatever privileges that host/service already has to request the secret. In their example, they suggest that the Barbican's credentials could be kept out of the configuration file by using environment variables, but that's just having the unencrypted credential in a different place; a privileged user on that host/service can access the service's environment variables, then request the key from Barbican. In the summit talk, they only go through one risk scenario which is what they are trying to address; which is when a developer reaches out to a vendor for support they might inadvertently send the entire configuration file, passwords and all, and that is the risk they're looking to mitigate. If you're using Kolla-ansible, your configuration files already don't have the passwords, as they're typically configuration overrides, supplementing the kolla-ansible j2 templates - unless you're pulling the fully compiled configuration files out of the running containers, and sending those. At the start of the Summit, they talk about some other avenues they did _not_ try because it introduced significant complexity; one of which was to encrypt the configuration files, or partially encrypt the contents of the configuration files so that the credentials were not stored in plain text at rest. This would have mitigated AT&T's requirement of developers sending full configuration files to vendors, but is less cloud-native and proposes new technological challenges such as what to do when you need to rotate those credentials. It may or may not afford you greater security than using Barbican or Vault, as at some point the service accessing that configuration file needs the keys to decrypt the contents of the configuration file; so we're back to square one - a user with privileged access to read the configuration files presumably has enough privileged access to access to configuration file's decryption key. The trade off is a non-linear scale of "Complexity and Greater Security <--------> Convenience but Lesser Security". Everyone's risk appetite for where they land on that scale is different, and a mature organisation will be able to shift around on that scale as they become more competent in overcoming complexity, and can then benefit from the greater security. So, depending on your risk profile, and what risks you are trying to mitigate, using Barbican or Hashicorp Vault to store secrets, and have the services collect these secrets as needed might not address your particular risks. Presuming you follow a Hashicorp Vault service, or a similar service, to protect your keys, and you dialled up the security using ACLs and Policies, you could greatly increase the secrecy of your credentials, but at a significant increase to your risk of service availability/interruption (i.e. What if the Vault goes away/down? What if you lose the trust relationship with your vault/policy - how do you recover?). If the increased secrecy mitigates some significant risks, that's great - you just want to make sure that you aren't introducing new, potentially far more impactful risks to your setup. One way to go very hard to the "Complexity and Greater Security" scale, you could consider re-building and changing every kolla container's runtime user/group and privileges, so that even using docker privilege escalation tricks can't access the kolla service container, but this requires a lot of tooling, and has far reaching consequences for things like troubleshooting and applying updates. I would encourage anyone who is looking to enhance their security position to do a genuine threat and risk assessment - really put down on paper (or a spreadsheet, or your risk analysis tooling if you're lucky enough to have some) to determine whether or not the steps you're taking to address a security concern have merit, or whether the effort could be more effectively used elsewhere. Kind Regards, Joel McLean – Micron21 Pty Ltd -----Original Message----- From: elnazcloud@gmail.com <elnazcloud@gmail.com> Sent: Tuesday, 29 July 2025 5:21 PM To: openstack-discuss@lists.openstack.org Subject: RE: [kolla][barbican] Secure password management in Kolla-Ansible using Castellan Yes, we are using Ansible Vault to encrypt our passwords.yml, and all sensitive values are stored encrypted in that file. However, our concern is that—even though the secrets are encrypted at deployment time—they still end up as plaintext in the final config files inside the containers (e.g., nova.conf). As highlighted in the OpenStack Summit talk, there's an initiative to improve secret handling by avoiding storing passwords directly in service configuration files, even on disk. Instead, passwords would be referenced or pulled dynamically from a secure external source, such as Barbican or HashiCorp Vault, via Castellan integration. So while encrypting passwords.yml with Ansible Vault is a good first step, we're interested in going further — specifically, preventing plaintext secrets from appearing in config files altogether, as part of a more secure design. Thanks in advance!