Fixed Duplicate Client-token issue

[mskanth972]

Is this a bug fix or adding new feature?
Currently the client-token of an EFS Access Point is unique only to region and not to a specific File system. So when using reuseAccessPoint feature there maybe a chance that two different File systems can use the same PVC name with this parameter enabled and which can lead to ErrorCode: "AccessPointAlreadyExists". To overcome this I just added the FS-ID also to the hashed value along with PVC name.

What is this PR about? / Why do we need it?

What testing is done?
Already have the existing test cases around the hash

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mskanth972

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [mskanth972]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle stale
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle rotten
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Reopen this PR with /reopen
• Mark this PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closed this PR.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Reopen this PR with /reopen
• Mark this PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[k8s-ci-robot]

@bittracer: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[bittracer]

Is this no longer required?

[joaocc]

Hi.
We just encountered this issue. In a single EKS cluster, we use several EFS instances which are accessed from different namespaces and with same PVC name (inside the ns). Driver is v1.7.7.
So, for instance

• EFS-01 and EFS-02
• EKS-A with
  • storageClass dyn-sc-to-efs-01 and dyn-sc-to-efs-02, with reuseAccessPoint=true
  • namespaces client-01 and client-02
• each client uses PVC names my-data (in the corresponding NS) of respectively dyn-sc-to-efs-01 and dyn-sc-to-efs-02

Client-1 is created ok, but when adding client-2, we start getting the errors mentioned above.
It seems even thought the target EFS specified by the dyn-sc-to-efs-02 is different (EFS-02 instead of EFS-01) the driver is complaining that the access point already exists in EFS-01.

If this is the intended behaviour, this means that the potential for conflict is huge, as any cluster can "block" any other cluster in same region that uses the reuseAccessPoint=true, but creating a PVC in any other EFS with the same name and settings. Also, if this is intended behaviour, the documentation can be made clearer and be more explicit in explaining the implications (security and operations-wise).

If this was not intended behaviour, could you please let us know when this could be merged?
Thanks

[mskanth972]

Hi @joaocc I can update the doc accordingly for now, you can turn off the parameter if there is no special reason for turning it on.
Parallely, I will work rebasing the PR and updating the README.

[joaocc]

Hi. Thanks. We already removed/disabled the param, as the understanding was incorrect and it is not needed. I tried to bump this so that all the work already done could be submitted and save someone else the headache :) Thanks!

[mskanth972]

/test pull-aws-efs-csi-driver-unit

[mskanth972]

/test pull-aws-efs-csi-driver-unit

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Reopen this PR with /reopen
• Mark this PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closed this PR.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Reopen this PR with /reopen
• Mark this PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.