feature request: support aws auth

[heimweh]

Hi! Loving the project so far! 🙌

It seems like the CSI provider supports k8s auth at the moment. Are there plans to support other auth methods in the future?
I managed to implement a PoC with AWS auth, it's not quite ready yet to be submitted but I just wanted to check in here before, if it would be a welcomed addition? 🙂

Thanks in advance 🙂 🙏

cc @joatmon08 (meeting at AWS re:Invent).

[tomhjp]

Hi @heimweh, no concrete plans but this is great to know there's interest. It's not something I've thought a lot about previously, but I'd be interested to discuss the design before getting into any PRs to ensure there's a good chance of it getting merged, so thanks for opening this first.

Currently the only configurability we support for auth is the vaultKubernetesMountPath option. If we started supporting other auth methods, perhaps we would want to support an auth object of some sort at that level instead, with different options for different auth methods.

The slightly trickier issue is identity. It's important to the design of the project that we authenticate using the requesting pod's identity and not the provider pod's identity. That's why we create a service account token for the requesting pod's service account rather than use the pod's own token, and hopefully in the near future we can stop needing to do that and use a CSI token attached in the mount request instead of creating a fresh one - ref.

For that reason, I'm pretty keen to continue using a service account token as the basis for identity, and I'm not sure if that's going to be compatible with using AWS auth? I'm much more familiar with the Vault side of things than AWS - do you know what identity options we have in that context?

[heimweh]

Hey @tomhjp,

thanks for the quick reply 🙏

Great to hear! I saw that the current auth is more or less centered around the Kubernetes auth and yeah I totally agree,
it makes sense to have an auth object that can be used for more auth methods in the future 🙂

I got it to work using the requesting pod's service account but it's a bit involved and requires IRSA:

1. The provider reads the AWS role ARN label (eks.amazonaws.com/role-arn) from the requesting pod's service account
2. The provider then requests a token on behalf of the pod (as usual)
3. The provider then leverages the aws-sdk to authenticate using the token and role ARN above, signs a valid STS GetCallerIdentity request, and hands it over to Vault during Login (leverages https://github.com/hashicorp/go-secure-stdlib/tree/main/awsutil)

Nice! I really like the idea of using the CSI token attached in the mount request 🙌

[tomhjp]

Awesome, that sounds perfect! Thanks for the explainer. Now that you mention it I remember we support IRSA in the Vault Agent injector as well.

I think the design of the auth config is probably the only structural thing left to flesh out in that case. Thinking out loud about some options, it might make sense to just have mutually exclusive xxxAuth blocks at the top-level of parameters instead? e.g.

awsAuth:
  mountPath: "aws"
  role: "my-aws-auth-role"
  ...

I think mountPath and role would be common to all auth methods, but there are probably other options the various cloud auth methods might want to support. Having auth at the top-level instead might look something like this?

auth:
  type: "aws"
  mountPath: "my-aws-mount"
  role: "my-aws-auth-role"
  aws:
    # Optional block for AWS-specific configuration here

WDYT? Lots of other options too of course.

I'd be very happy to review and iterate if you do fancy tidying up your POC to open a PR 🙌

[heimweh]

Yeah that's true, we use it and it works great in our environment 🙏
I definitely like the second design, agree that mountPath and role will be common across all auth methods 🙂

That's awesome! I'll try to clean up the PoC and I'll open a PR, happy to iterate from there 🙂 🙏

[kidbomb]

Hey @heimweh - I'm pretty interested on this feature. Do you have any updates on this?