aws-efs-csi-driver VS secrets-store-csi-driver-provider-gcp

In the past I was have problems with GID allocator, something related to this problem.

However, the docs (https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/examples/kubernetes/dynamic_provisioning/README.md) are telling me to create EFS Mount Targets in the EKS subnets. Thats fine.

Fargate storage A Pod running on Fargate automatically mounts an Amazon EFS file system. You can't use dynamic persistent volume provisioning with Fargate nodes, but you can use static provisioning. For more information, see Amazon EFS CSI Driver on GitHub.

I guess something like this might go a long way to solve the problem https://github.com/kubernetes-sigs/aws-efs-csi-driver/pull/640 ? Though I see it isn't merged yet

I am currently trying to create an EFS for use within an EKS cluster. I've followed all the instructions, and everything seems to be working for the most part. However, when trying to apply the multiple_pods example deployment from here, the pods cannot succesfully mount the file system. The PV and PVC are both bound and look good, however the pods do not start and yield the following error message:

In each namespace, create a PV/PVC using the same fixed volume path. See "Volume Path in EKS CSI Driver" To make this work however, you MUST pre-create this volume path in your EFS (I usually just have an EC2 instance with it mounted to work on). From the docs above "Note: this feature requires the sub directory to mount precreated on EFS before consuming the volume from"

resource "aws_iam_policy" "eks_efs_csi_driver_policy" { # https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/docs/iam-policy-example.json policy = file("./6.AWSEFSpolicy.json") name = "aws-efs-csi-policy" }

efs - IAM Policy for AWS EFS CSI Driver.

The driver can also sync changes to secrets. The driver currently supports Vault, AWS, Azure, and GCP providers. Secrets Store CSI Driver can also sync provider secrets as Kubernetes secrets; if required, this behavior needs to be explicitly enabled during installation.

GCP SS-CSI driver

That's interesting actually, Google provides their own rpvider for the Secrets Store CSI Driver: https://github.com/GoogleCloudPlatform/secrets-store-csi-driver-provider-gcp

Consider: if you have a tool like terraform managing your infra components including your data layer, you likely want to manage those reaources in a different lifecycle from your application code. Applications may also likely managed using a different toolset (kubectl, helm, scaffold, etc.). In this case, secret Manager acts as the secure configuration bridge between the tools, keeping the secrets out of human hands. As certs and passwords are generated on the infra side, those values can be stored as secrets in SM. Application workloads - backed by service accounts having access to read the secret - can decrypt during launch and use the secret as needed. You can use common patterns in both GKE (via thesecrets store csi driver ) and Cloud Run for consuming secrets in this way.

I prefer https://github.com/GoogleCloudPlatform/secrets-store-csi-driver-provider-gcp