Closed nastacio closed 3 years ago
Hi Denilson. You're right, and this concern has been brought up by others.
There's an effort underway to support AWS EFS natively in OCP using a methodology much closer to what you suggest. As such, development in this repository is likely to be very limited. That said, I would be happy to review changes if you wish to propose them.
The main problem I see with this approach is RBAC. Because the operator needs to create PVs (usually a privileged operation), it would be potentially unsafe to trigger that via creation of PVCs (usually allowed by default by a regular user who owns the namespace). Particularly since the PVs are necessarily attaching to already-existing EFS access points.
(On that note, be aware of the security scope of the existing code: anyone you allow to create SharedVolumes
can attach to any access point -- there's no separation.)
I believe the native design intends to support creation of PVs -- so that's inherently privileged by default -- and then allow users to attach PVCs to those PVs as they would any other.
In the meantime, I can perhaps address a small part of your issue:
they cannot make assumptions about the name of the
PVC
The naming convention for the PVs and PVCs is predictable and very strict -- the code relies upon it for reconciling. Granted it's not the "usual" convention -- but maybe this helps?
The clarification is very helpful. For now we are using OCS and can wait for the the upcoming native AWS EFS support.
The naming convention for the PVs and PVCs is predictable and very strict -- the code relies upon it for reconciling. Granted it's not the "usual" convention -- but maybe this helps?
It is not our software, they have hardcoded names for the PVCs, allowing only the selection of the Storage Class.
Many applications create
PVC
objects directly, but the AWS EFS operator seem to exclusively create them indirectly, viaSharedVolume
objects.This design approach precludes the usage of the AWS EFS operator with a significant set of applications. As an added complication, the
PVC
indirectly created in association with theSharedVolume
has a name generated as a function of the name of theSharedVolume
, so that applications not only cannot create aPVC
directly against theefs-sc
storage class, they cannot make assumptions about the name of thePVC
either, further limiting the range of use cases possible with the operator.Would it be possible to get the operator to process
PVC
objects directly when they reference theefs-sc
storage class, thus allowing a much wider range of scenarios where an application's configuration only has room for the name of the storage class and creates PVCs directly against that storage class?