https://aws.amazon.com/about-aws/whats-new/2022/07/aws-identity-access-management-iam-roles-anywhere-workloads-outside-aws/ may be a good choice for AWS users, particularly if the Jenkins server is not Internet-facing (and it is impractical to mirror the public key to something that is). Document the considerations here and compare to use of web identity federation.
Currently it seems the Roles Anywhere private key is as much of a risk for leakage as a traditional static key, unless you have some form of trusted infrastructure generating temporary credentials and passing them on to builds. It also seems harder to rotate the CA (though you can use CRLs), whereas with OIDC you merely start publishing a new key set without needing to explicitly notify AWS.
It seems you can make policies be sensitive to specific X.509 subjects; is this comparable in expressiveness to making them sensitive to JWT id token claims?
(Thanks to @benkehoe for the nice introduction to this feature.)
https://aws.amazon.com/about-aws/whats-new/2022/07/aws-identity-access-management-iam-roles-anywhere-workloads-outside-aws/ may be a good choice for AWS users, particularly if the Jenkins server is not Internet-facing (and it is impractical to mirror the public key to something that is). Document the considerations here and compare to use of web identity federation.
Currently it seems the Roles Anywhere private key is as much of a risk for leakage as a traditional static key, unless you have some form of trusted infrastructure generating temporary credentials and passing them on to builds. It also seems harder to rotate the CA (though you can use CRLs), whereas with OIDC you merely start publishing a new key set without needing to explicitly notify AWS.
It seems you can make policies be sensitive to specific X.509 subjects; is this comparable in expressiveness to making them sensitive to JWT id token claims?
(Thanks to @benkehoe for the nice introduction to this feature.)