AEM secret management without git or environment variables?

[PeterJS]

I'm looking for a security best practices guide or recommendation for AEM that includes how to manage secrets, for example credentials like API tokens, passwords or keys for third party services integrated with AEM. I'm not a security professional, though I'm curious enough to learn more about the area as getting security, less wrong, seems hard.

The AEM Security Checklist could be a good place, though it doesn't cover third party secret management as far as I can tell? Though perhaps it's more like Integrating with Third-Party Services - though again this doesn't seem to cover secrets directly (screenshots in specific guides like Salesforce look like it uses an HTML input type password field, though lack enough depth to see if the password just gets stored in another JCR node somewhere, or are more deeply locked down by AEM - is it even possible to know)? What if I have a third party integration requirement which doesn't have an AEM plugin yet?

For context, the well known (though not universal) 12factor.net/config does require a strict separation of config from code, which seems to often be interpreted by the industry in practice as put secrets into the environment (though it does not really say that).

This AEM cloud post talks about environment variables as one way to store secret client settings, though as summarised here (via this, which clarifies 12factor, jokes aside

• Given that the environment is implicitly available to the process, it's hard, if not impossible, to track access and how the contents get exposed (ps -eww ).

• It's common to have applications grab the whole environment and print it out for debugging or error reporting. So many secrets get leaked to PagerDuty that they have a well-greased internal process to scrub them from their infrastructure.

• Environment variables are passed down to child processes, which allows for unintended access. This breaks the principle of least privilege. Imagine that as part of your application, you call to a third-party tool to perform some action—all of a sudden that third-party tool has access to your environment, and god knows what it will do with it.

• When applications crash, it's common for them to store the environment variables in log-files for later debugging. This means plain-text secrets on disk.

• Putting secrets in ENV variables quickly turns into tribal knowledge. New engineers who are not aware of the sensitive nature of specific environment variables will not handle them appropriately/with care (filtering them to sub-processes, etc).

I'm curious if that could be rebutted, i.e. environment variables actually are safe to use in AEM? Or if any of the above could be used to demonstrate env vars are flawed? Could git-based secrets be the lesser of two evils here especially if that was already in a codebase (Hippocratic Oath)?

Or more ideally, if someone, ideally a security professional, has come across a better secrets or vault style solution?

If it's simply not in AEM (yet?) though external services could be useful, I'd be open to seeing if say Azure Key Vault, AWS KMS or Google Cloud KMS is a reasonable piece of a demonstrably better solution? Has anyone tried something like that - if so how did it go?

[arunpatidar · Accepted solution]

hi,

we use AWS secret manager to store all the secret and the reason for that is to store secret at one place for all the applications within organization/project.

In AEM git, we just stored the secret placeholders (AWS Secret key) and during a Cloud manager maven build(prepare-package) we get the secret from AWS and replace it for packaging and that is install in AEM.

Although with this approach secrets can be seen from AEM CRXDE.

I have never tried same for the AEMaaCS though.