Update cross account mount example with specs and add missing setup step #488
Conversation
k8s-ci-robot
added
the
cncf-cla: yes
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: kbasv 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:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
approved
|
with the proliferation of IAM policies and stuff I think we need to provide examples for each, I am having trouble keeping track myself :( currently we only provide an example policy for the controller https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/docs/iam-policy-example.json |
Let me add an example iam policy for node daemonset's IRSA |
k8s-ci-robot
added
size/L
| 2. Create an IAM role, say `EFSCrossAccountAccessRole` in Account `B` which has a [trust relationship](./iam-policy-examples/trust-relationship-example.json) with Account `A` and add an inline EFS policy with [permissions](./iam-policy-examples/describe-mount-target-example.json) to call `DescribeMountTargets`. This role will be used by CSI-Driver's Controller service running on EKS cluster in account `A` to determine the mount targets for your file system in account `B`. | ||
| 3. In aws account `A`, attach an inline policy to IAM role of efs-csi-driver's controller service account with necessary [permissions](./iam-policy-examples/cross-account-assume-policy-example.json) to perform `sts assume role` on the IAM role created in step 2. | ||
| 4. Create a kubernetes secret with `awsRoleArn` as the key and the role from step 2 as the value. For example, `kubectl create secret generic x-account --namespace=default --from-literal=awsRoleArn='arn:aws:iam::123456789012:role/EFSCrossAccountAccessRole'`. | ||
| 5. Create an IAM role for service accounts for EKS cluster in account `A` with required [permissions](./iam-policy-examples/node-deamonset-iam-policy-example.json) for EFS client mount. Alternatively, you can find this policy under AWS managed policy as `AmazonElasticFileSystemClientFullAccess`. |
There was a problem hiding this comment.
typo deamonset daemonset but actually the file is named deamonset
There was a problem hiding this comment.
I'll fix the typos in a follow up PR
| "elasticfilesystem:ClientMount", | ||
| "elasticfilesystem:ClientRootAccess", | ||
| "elasticfilesystem:ClientWrite", | ||
| "elasticfilesystem:DescribeMountTargets" |
There was a problem hiding this comment.
why does node need permission to DescribeMountTArgets again? the controller will do it at CreateVolume time so that node just gets an IP right. (i can check the code but I got lost again, sorry.)
There was a problem hiding this comment.
efs-utils independently tries to resolve mount target as a fail over in case the az passed in as mount option is no longer available.
|
/lgtm there's one typo and one question about whether node needs DescribeMountTargets permission (does efs-utils use it somehow?) |
k8s-ci-robot
added
the
lgtm
Is this a bug fix or adding new feature?
What is this PR about? / Why do we need it?
Update cross account mount documentation
What testing is done?