Getting credentials at runtime from AWS Secrets Manager

[abinoam]

Hi @jcormier

With this code I'm being able to get credentials at runtime from aws secrets manager service.

I tried to follow the way the docker-redmine's code is already working.

If you feel I should improve something, just let me know.

I tried to be as much descriptive in the README as possible. Perhaps it got too long. Tell me if you want me to change it or move the specific instructions to another place (wiki? Another .md behind /docs/?)

See: https://github.com/abinoam/docker-redmine/tree/aws_secrets?tab=readme-ov-file#aws-rds-integration

[jcormier]

I tried to be as much descriptive in the README as possible. Perhaps it got too long. Tell me if you want me to change it or move the specific instructions to another place (wiki? Another .md behind /docs/?)

I think moving to a separate md file under docs would make sense, its quite long. With pointers in the main README.

Also add the two new configs to the configuration section with pointers to the new doc.

Everything else looks good. well done

[jcormier]

How does it authenticate with the AWS secrets manager? Is the secrets name itself enough?

[abinoam]

How does it authenticate with the AWS secrets manager? Is the secrets name itself enough?

Short answer: Yes. It just need the name of the resource. And what blocks other machines of reading this resource (the secret) is a policy set that says "Only this VM can access this secret by name".

But, the main advantage here is that the container will get credentials at runtime (not hardcoded).
So, if there's a problem, I just put it down and up again and it will get the new credentials.
So, I will be able to rotate credentials more easily without using environment variables.

The current approach is still not the "gold" but it's a step toward it.
The VM (AWS EC2 instance) has an identity so I can set the policies on it.
But the VM has an operating system running on it, then docker, then the container.
So, AWS can't have a "normal" identity for the container running redmine.
So, at least for now, all containers running inside the machine should be trusted.
Because if a different container (in the same VM) tries to read the same secret, it will succeed as the policy is for the whole VM.

As soon as I have time, I will try to improve that, and perhaps the path is through "AssumeRole" ('im not sure).

PS: If I use the container service of AWS, the container will have its unique id, which would make it possible to set the policy for the container itself (as it's also an AWS resource).
But running containers in the proper aws container service is more expensive than running several containers in a single VM.

Long answer: (with the help of ChatGPT because my english is not good enough to explain it)

AWS Secrets Manager authentication works by leveraging AWS Identity and Access Management (IAM) policies. Each resource in AWS (e.g., a VM or secret) has a unique identity, such as an ARN. IAM policies define which resources can access which others. For example:

IAM Role for the VM: The VM (or container running on it) is assigned an IAM role that grants explicit permission to access specific secrets in Secrets Manager. The "cloud" enforces this policy based on the resource identities.

Resource-Specific Policies: If the container is moved to a different VM without the correct role, access is denied automatically. This is enforced at the resource level, without relying on IPs or DNS.

Layered Security: Even if credentials from Secrets Manager are compromised, additional policies (e.g., allowing only the original VM to connect to the database) prevent unauthorized use.

This setup ensures tight, identity-based security managed by AWS without external configurations.

[jcormier]

Thanks for the explanation. Sounds interesting. I've never used AWS for anything so it's all new to me.

[abinoam]

Hi @jcormier,

I have improved the aws docs with a debuggin session and some more minor details.
I've moved it to docs/aws.md.
And let only a link to it in the README.md

Please let me know if you think it's ok now.
Feel free to make any adjustments you think is appropriate.

And, thanks again for maintaining this repo!!! 🤜 🤛

[abinoam]

I plan to further develop this feature in the future to include:

• Better integration with AWS.
• Support for other cloud providers (e.g., Google Cloud, Azure, Oracle).
• Integration with Doppler.

Additionally, I aim to upstream these improvements to the main Redmine repository.

However, to achieve this, I will need:

• Time to study the Rails codebase in depth, particularly the database connectivity layer.

As such, I can't provide a precise timeline just yet.

For now, this PR addresses specific issues encountered by a "client"—a software house owned by a friend. In a way, I should say that this PR was sponsored by TruStep BR.

[abinoam]

🤜 🤛 @jcormier !