| Hi red, The plugin is designed the way it is because most Jenkins installations will be in the same AWS account as their secrets, and because moving Jenkins further from the secrets imposes steep costs. It will be most secure if it authenticates using IAM instance profiles (EC2) or fine-grained service roles (EKS), and it will be most reliable if it can access Secrets Manager within Amazon's internal network, so both these things are encouraged. When Jenkins is run in a different cloud from Secrets Manager, the costs become apparent:
- Jenkins can't use IAM instance profiles, so you must provision an AWS access key pair for Jenkins, and then guard that key pair closely, because if it is stolen then the attacker can access every secret that Jenkins can access.
- Jenkins can't access Secrets Manager through Amazon's network, so its Secrets Manager connection is at the mercy of the public Internet. You can improve this somewhat by establishing an AWS PrivateLink between Jenkins and Secrets Manager, but it still won't be as good.
No code in this plugin can solve the data locality problem, as it arises from your cloud architecture, and can only be properly addressed by altering your cloud architecture. So before going the multi-cloud route, consider if you can:
- Co-locate CJOC with the secrets (move CJOC to EC2 or EKS).
- Co-locate the secrets with CJOC (move the secrets that CJOC needs to Google Cloud; this will only work if CJOC is the only user of those secrets).
If none of the above options work then you will need to use the "escape hatch" of passing the AWS key pair to the CJOC container through environment variables or system properties. |
