Add IAM Auth Method#12583
Conversation
|
Probably good to in the PR somewhere and likely also in a comment in one of the packages indicating which version/sha of various vault libraries the various AWS bits were lifted from. That way there's a paper trail to figure out which possible future patches on the vault side need to be re-replicated here. |
| creds = sess.Config.Credentials | ||
| } | ||
|
|
||
| loginData, err := iamauth.GenerateLoginData(&iamauth.LoginInput{ |
There was a problem hiding this comment.
Vault calls into a GenerateLoginData function, which I didn't end up re-using because (1) it doesn't support encoding the "get entity" request (GetRole or GetUser) in the login data, which is unique to the Consul implementation, and (2) there's a hardcoded vault server id header name, which is also why there are a bunch of header names passed into GenerateLoginData here, so that we're using X-Consul* header names.
| ) | ||
| } else { | ||
| // Session loads creds from standard sources (env vars, file, EC2 metadata, ...) | ||
| sess, err := session.NewSessionWithOptions(session.Options{Config: cfg}) |
There was a problem hiding this comment.
This relies the AWS SDK's standard credential chain, whereas Vault credential discovery calls into GenerateCredentialChain, which does some custom things. I haven't deeply compared these. Probably, there's a good reason for what Vault does, and we should adopt their implementation, which I can do now or in a follow up.
There was a problem hiding this comment.
It might be worth figuring out what value GenerateCredentialChain is bringing and erring on the side of using it over not.
There was a problem hiding this comment.
I've dug through the credential loading a good bit in the past couple days. I time boxed this, but there's nothing I've found that Vault supports in its custom credential chain that the SDK doesn't also support out of the box.
Users have also noticed differences between Vault's credential chain and the SDK, and Vault has generally moved toward matching the SDK behavior where possible (such as: hashicorp/vault#7738 and hashicorp/vault#13807).
So I think we should rely on the SDK's credential discovery in favor of being more standardized.
| return identityDetails, nil | ||
| } | ||
|
|
||
| // https://github.com/hashicorp/vault/blob/ba533d006f2244103648785ebfe8a9a9763d2b6e/builtin/credential/aws/path_login.go#L1321-L1361 |
There was a problem hiding this comment.
I referenced the corresponding Vault code, but this is simpler since it doesn't support the unique role/user id check.
Note: I kept the links to Vault code for comparison during this initial code review, but I'm planning on removing those from the source code. I'll add permalinks to the Vault source in the README for this internal module instead.
| // For backwards compatibility, even if you request a region other than us-east-1, it'll still sign for us-east-1. | ||
| // See, e.g., https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html#id_credentials_temp_enable-regions_writing_code | ||
| // So we have to shim in this EndpointResolver to force it to sign for the right region | ||
| func stsSigningResolver(service, region string, optFns ...func(*endpoints.Options)) (endpoints.ResolvedEndpoint, error) { |
There was a problem hiding this comment.
TODO: Figure out if the STSRegionalEndpoint config option takes care of this for us.
|
|
||
| // ServerIDHeaderValue adds a X-Consul-IAM-ServerID header to each AWS API request. | ||
| // This helps protect against replay attacks. | ||
| ServerIDHeaderValue string `json:",omitempty"` |
There was a problem hiding this comment.
Might want to carry more detail over from the vault equivalent field, or do so on the website pages describing this field: https://www.vaultproject.io/api-docs/auth/aws#iam_server_id_header_value
There was a problem hiding this comment.
Yeah, I'll detail this in the docs on consul.io.
c6febdc to
495d3b6
Compare
Co-authored-by: R.B. Boyer <4903+rboyer@users.noreply.github.com>
|
Created the following couple of issues to follow up on before 1.12 GA: |
|
🍒 If backport labels were added before merging, cherry-picking will start automatically. To retroactively trigger a backport after merging, add backport labels and re-run https://circleci.com/gh/hashicorp/consul/619124. |
This adds an IAM auth method to Consul to support logging in with AWS IAM identities.
Overview
This PR uses a similar approach as the Vault IAM auth method. Vault's login token format is used here, but with a unique change to avoid the need for config the auth method with AWS credentials.
The "bearer token" contains one or two signed AWS API requests, which are JSON encoded.
consul login -aws-auto-bearer-token ....EnableIAMEntityDetails=falseconsul login -aws-auto-bearer-token -aws-include-entity ...EnableIAMEntityDetails=trueBecause the requests are signed with the client credentials, the IAM auth method does not need to be configured with its own AWS credentials.
Code
command/login/*- updatesconsul loginwith additional flags to support logging into the AWS auth methodGenerateLoginData()in the internaliamauthpackage to do the work of generating the bearer tokenagent/consul/authmethod/awsauth/*- implements the auth methodValidateLogin()in the internaliamauthpackage to do the work of validating the identity of a client attempting to logininternal/iamauth/*- an internal package which implements the core logic. This is a mix of new code and code borrowed/modified from the Vault IAM auth methodAuthenticator.ValidateLogin()validates a client's identity to determine if they are permitted to loginBearerTokentype parses the login token and does some validation of the tokenGenerateLoginDatafunction is used to generate the login data that forms the bearer token, which involves formatting signed AWS API requestsUsage
Configuring the auth method (example):
Login