Protecting AWS CLI credentials
Daniel Nashed – 20 August 2022 10:13:46
Hmmm ... I have been looking for a solution for a while and I was really surprised there is no good solution out there.
Docker for example has credentials helper to protect passwords.
I just found an approach to protect my AWS credentials and this brings up the secure key/value store I started to implement first in Domino and then on Linux level.
Usually your credentials would look like the following - A simple to read file, which cannot be protected.
I mostly use AWS CL it in a root user context, which has high permissions on the machine anyway -- but there are also ways to protect data from the root account!
Example: .aws/credentials
[default]
aws_access_key_id = XKIAZOXNXRHW7IPXCBBB
aws_secret_access_key = SY7/bI68F9Notess3NGFE/O7G70TdvpuT7wwV9Xi
You can configure AWS CLI to get it's credentials from another program.
Obviously the bash example is not intended to be used in production.
But I will probably extend my secure key/value store project to return AWS credentials in JSON format.
If you have an application, which could safely return data, the configuration would look like this:
Example: .aws/credentials with credentials helper
[profile developer]
credential_process = /local/aws/credentials.sh myaccount
Reference: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sourcing-external.html
Secure Key/Value store idea
My vault idea isn't new and I played with remote and local callers.
For remote callers a TLS enabled interface authenticated by IP and secret could make sense
Local callers could be controlled by process calling and other aspects.
Building a secure key/value store would involve storing the data encrypted on disk and the lookup key could be defined in the configuration. And a separate secret could be used to decrypt the blob.
I don't know how much interest would be out there for a generic tool, which might even help us to protect Domino server.ids.
The first version will be probably for my current needs instead of a generic tool.
I have played with OpenSSL encryption APIs some weeks ago.
Using AES 256 for encryption would be a good idea and isn't that difficult to implement -But it would result independency on OpenSSL.
Any feedback about this new idea is really appreciated.
- Would be a generic tool interesting?
- Would you have specific use cases?
- How do you protect your AWS credentials today?
-- Daniel
- Comments [4]
1Christian Henseler 20.08.2022 20:11:23 Protecting AWS CLI credentials
Not specific to AWS credentials, we are using CyberArk vaults to store and manage various non Domino credentials & Domino certifier files (there are still some use cases where certifier id files are necessary).
While CyberArk is able to automatically manage/change AD credentials (and many more systems), there is no native interface into Domino.
As a result we have to change passwords in AD and various databases - e.g. Directory Assistance and dbs using AD credentials with application impersonation - manually.
Would be great to have a more integrated tooling.
Unfortunately, SAML is not an option in our use cases or requirements are not given on the AD side.
2Daniel Nashed 21.08.2022 4:42:07 Protecting AWS CLI credentials
@Christian,
my point was a bit different. AWS credentials are usually on disk in a file, which the user needs to e able to read.
Anyone else having access to the file -- like any other application running in the same user contect, could read it.
That's currently my main concert about AWS credentials. There are solutions for SSH, where you protect the key with a password and have an SSH agent supplying the password.
Storing any kind of credentials on disk. Or even storing private keys on disk, like an encrypted PEM, isn't good security practice.
For example the private key of an SSL certificate is often pretty unprotected on disk. Some applications use PKC12 and specify the password in the application.
And this would be also possible for PEM files, which can be AES 256 encrypted.
Domino 12 CertMgr stores the keys in the new certstore.nsf, encrypted for the CertMgr server and all servers explicitly specified in "Servers with access: ". And only encrypted PKCS12 and PEMs are supported for export (with a certain entropy for the password).
In earlier releases the only supported format was the the old IBM on disk key format "KYR" with a stash file with an encoded password!
Your case is a bit different. You are looking for a way to update passwords regularly. There is no standard interface for those type of operation. It's always vendor specific and CyberArc built that integration for Windows.
Beside changing certifier passwords, which is a different story and they need to be protected in a different way, it's simple to set passwords in Notes/Domino by an application with proper access.
I have not heared from that type of requirement from any other customer. Implementing a standard interface for changing passwords for LDAP accounts and other application accounts (could be also the person doc password for inbound LDAP connections etc) would also introduce a new type of risk. It would not be a difficult interface for a vendor like CypberArc to write. Or are you aware of any standard interfaces Domino as an application. I found one for LDAP --> https://www.ietf.org/rfc/rfc3062.txt. But I did not find one for POP3 or IMAP. And I am not aware of any standard protocols supporting user account password changes in other ways. But that doesn't cover your directory assistance LDAP account password.
If this is an important requirement for your environment, it would be a custom solution, to update those type of account passwords automatically. Could be REST based interface someone could write in 2-3 days. Does CyberArc support REST based interfaces?
-- Daniel
3Lucas 14.01.2024 4:23:25 Protecting AWS CLI credentials
Check out granted [.] dev. Not only is it invaluable for multiple aws accounts it will securely store your credentials.
4Daniel Nashed 15.01.2024 17:11:03 Protecting AWS CLI credentials
@Lucas, thanks for the tip.
This is AWS specific. I am looking for a more generic solution, which can handle more requirements.
I started my own project. A vault that can handle secrets in many different ways. One of the outputs is a credentials helper.
the secrets can be configured to be constrained by time, count, requesting binary, requesting user and are stored in files owned by a different user (invoked via SUID for that user) encrypted on rest with AES256 with server wide seal/unseal operation. each secret has a key and an access key. each entry is encrypted with the access key. so even someone gets access to the files and the encryption key/password for the host, all secrets are still encrypted per secret.
The output can be a credential helper, starting an SSH Agent or exposing the secret time/count/binary/user based with another temporary secret which name and access key can be passed to a process via environment variables (similar to what a SSH agent does with it's socket.
In addition it can also output to a FIFO, which could be used for NGINX or other solutions, which require a password in a file.