Integration with EFS access point

[leakingtapan]

Is your feature request related to a problem? Please describe.
EFS launched access point: https://aws.amazon.com/about-aws/whats-new/2020/01/amazon-elastic-file-system-introduces-efs-access-points/. This provides fine granular access of efs mount point using IAM roles. We need to integrate this with the driver.

[adammw]

I believe this is just the mount.efs helper installed in the docker image is too old and needs to be updated.

[leakingtapan]

Several things needed for this to happen:

• upgrade to the latest efs mount helper (as @adammw mentioned)
• add new field for access point ID in storageclass
• pass the access point ID to node service for efs volume mount
• efs csi node service needs to assume the role of container that is consuming the volume (this is the challenging part). Several things needs to happen here:
  • csi node service needs to read the role arn of the container that is consuming the volume
  • csi node service needs to assume the above using assume role with the driver IAM identity

[adammw]

pass the access point ID to node service for efs volume mount

This currently works (with an updated mount helper) with mountOptions, although from a user-interface point-of-view, is not obvious.

efs csi node service needs to assume the role of container that is consuming the volume

If using the instance profile rather than container-dedicated IAM roles (less secure, but possible) I don't believe any extra logic is required as the mount helper will get the credentials from the instance metadata endpoint.

[nithu0115]

/kind feature

[MrNorm]

Hello! I was just wondering where this issue got to? I'd love to be able to use IAM for our EFS volumes. Thanks

[leakingtapan]

@MrNorm could u add more details about ur use cases?

[MrNorm]

@leakingtapan Sure thing - I'm looking to shift a number of web assets over to our EKS stack. Each web asset could have replicated pods and they all need access to a shared filesystem.

EFS + IAM at container/pod level, combined with access point mount options seemed a really good fit for this, as we can mount various EFS 'access points' and ensure the policy only allows access to containers/pods that fit the policy attached to that role and service worker.

Thanks!

[asadullahrao]

Can anyone share the access policy with access endpoint, which i will add in my efs file policy. which ultimately accessible to my tasks.

[wongma7]

Can anyone share the access policy with access endpoint, which i will add in my efs file policy. which ultimately accessible to my tasks.

You should only need to give the driver ClientMount permissions to your access point https://docs.aws.amazon.com/efs/latest/ug/iam-access-control-nfs-efs.html. As noted above if your driver doesn't have its own aws identity it will inherit the instance profile of the node it's running on

RE: IAM policy of the driver:

I think we should keep the current behavior of the driver where it implicitly expects to have permission to ClientMount things access points, whether via instance policy+role or a dedicated policy+role (and document it with examples). It's a bit more secure than having the driver assume applications' roles because presumably the application has additional permissions like ClientWrite that the driver doesn't need and shouldn't receive.

Unless users trust the driver to have ClientMount for wildcard access points, they would have to maintain a policy that lets it ClientMount their various access points. But either way I think it's preferable to having to maintain a policy that lets the driver AssumeRole their various applications' roles.

RE: having a dedicated field vs a mountOption.

This currently works (with an updated mount helper) with mountOptions, although from a user-interface point-of-view, is not obvious.

I don't like that it's non-obvious/discoverable but I would prefer to continue respecting mountOptions versus adding a dedicated field and dealing with potential conflicts...it's kind of like how "encryption in transit" means add option tls but an encryptionInTransit bool field would be much nicer.

[wongma7]

The best option which I didn't see earlier would be to respect node publish secrets #127 and assume the role in the secret only at mount time

[leakingtapan]

The best option which I didn't see earlier would be to respect node publish secrets #127 and assume the role in the secret only at mount time

How is it going to work as the driver needs to handle multiple volumes, and each volume requires a different permission to be mounted? And also how about is secret rotation if secret object is used? What if customer need to use IAM for SA, would it cause any conflict?

[robwithhair]

Really looking forward to this functionality as my cluster is currently failing Pen Test due to lack of Access Point usage.