AWS Auth Login Metadata

[jlestrada]

Is your feature request related to a problem? Please describe.
Yes, the proposed feature request is related to a problem with the audit trail when using AWS Auth Engine.

The scenario is that the AWS Auth engine is enabled and configured and the use of an AWS Auth Role is binded to an IAM Role as the principal entity. With the IAM Role bounded to a Vault Role, an IAM User is then capable of assuming this role to log into the Vault server. This authorization flow works well and allows for Vault access to be controlled through IAM access to assume the role. Multiple IAM Users are capable of assuming this role.

The issue specifically is the lack of observability on the audit trail. With the Vault server audit logs enabled, the following metadata format is supplied.

"metadata": {
	"client_user_id": <unique_id>,
	"role_id": <role_id>,
	"auth_type": "iam",
	"canonical_arn": "arn:aws:iam::<aws_account>:role/<iam-role-name>,
	"account_id": <aws_account>,
	"client_arn": "arn:aws:sts::<aws_account>:assumed-role/<iam-role-name>/vaultSession"
}

The extra metadata fields are configured via the iam_metadata endpoint.

None of these fields are unique to the IAM User who is assuming the role. This lack of observability as a result does not allow for specific actions to be traced back to a user during an audit.

Describe the solution you'd like
The request here is to develop a way in which a clear owner can be pinned to specific Vault actions with the use of IAM Roles. An AWS metadata field such as the AWS::IAM::AccessKey can be used to determine a unique individual based on cloudtrail lookups.

Describe alternatives you've considered
The alternative at the moment is to bind the IAM User arn explicitly to the Vault Role. This direct binding will explicitly use the ARN of the IAM User. The drawback to this method is the need to consistently update the Vault AWS Auth Role for changes to who should and shouldn't have access. Being able to control this from outside of Vault would be helpful from an operational toil perspective.

Explain any additional use-cases
The additional/extended use case here is the combined use of the Vault DB Engine configuration. The DB Engine is configured such that it is creating temporary and unique roles for users of this Vault Role binded to the IAM Role. This feature of credentials creation is useful as it allows a user to access the Database in a scoped manner with short lived credentials.

It should additionally be useful such that the DB Engine username template can be updated to use unique Vault Role names or IDs that can be easily traced back to a User.

Additional context
Here is where the metadata for the AWS Auth Login is being configured. This is where additional logic may be made to update the fields such that a unique field value can be used.

I would like to argue that use of IAM Roles that are assumed could be dangerous to users who may not be able to audit specific actions. This might be worth calling out in the mean time within the documentation for visibility.

[jlestrada]

I just discovered that there is an ability of enforcement from AWS when executing the IAM action AssumeRole such that the RoleSessionName can be enforced to a username. The following AWS article describes this process here. If we assume this enforcement as a requirement then I believe there is a path forward for the scenario I described above.

With the parameter iam_alias set to unique_id we would be capable of seeing the full ARN of the role, which contains the RoleSessionName within the metadata block. This parameter is described here. This would then allow for an easy way to traceback which IAM User executed specific Vault actions. This I think technically removes the block.

Despite the audit traceback process being unblocked there is still a request of a feature specifically with regards to use of the Database engine. The engine relies on a username templating process for generating dynamic and unique username credentials. The engine relies only on two field names DisplayName and RoleName, please reference documentation here. The field RoleName to the best of my knowledge is specific to the Vault Role and NOT the IAM assumed role. The DisplayName however does refer to the respective Auth engines configuration of the DisplayName field. This is where the request now comes.

It is being requested that the AWS Auth engine can be configured or modified in such a way that the DisplayName is capable of being set to include the IAM RoleSessionName.

At the moment it showcases the name of the IAM Role but not the set RoleSessionName. This is referenced as the entity.FriendlyName attribute here. It is of my opinion that the attribute FriendlyName should include the RoleSessionName when IAM assume role process is used. The FriendlyName field is parsed in such a way that it extracts the RoleSessionName within the application logic here. If this field were updated to include the RoleSessionName then we would be capable of generating dynamic and unique credentials that match an IAM user. This however does change the behavior of what the field showcases. I may be oblivious to how this field can be used by multiple users but I think it would be minimal impact.

As an alternative and in my opinion a harder path to implement, an update can be made to the Postgres Engine such that a new field name can be used during username templating. I consider this to be a more challenging path because users of the engine may rely on different Auth types that do not contain the same fields. This is why I assume only DisplayName and RoleName are supported.

I will go ahead and submit a PR to remove the extraction of the RoleSessionName from the attribute FriendlyName. I don't know how it will go but willing to give it a shot.

cc @stevendpclark

[calvn]

Thanks for the thorough investigation and explanation on this! I'm still trying to understand this a bit more, but will be taking a closer look at the PR shortly.

[jlestrada]

Thanks for the thorough investigation and explanation on this! I'm still trying to understand this a bit more, but will be taking a closer look at the PR shortly.

Yeah totally feel free to ask questions or let me know if the behavior is not intended. From how i understand it and view it I don't see why adding the RoleSessionName is harmful but i could very well be missing something.

FWIW I am still working through making some updates to the test cases to get this to pass.

[calvn]

We will go ahead and close this issue now that the PR has been merged and slated for 1.11 release. Feel free to re-open if you encounter any issues around this thereafter.