search

openshift / aws-efs-operator

Operator to manage AWS EFS on OpenShift
Apache License 2.0
3 stars 23 forks source link

Handling PVCs directly rather than using SharedVolume #34

Closed nastacio closed 3 years ago

nastacio commented 3 years ago

Many applications create PVC objects directly, but the AWS EFS operator seem to exclusively create them indirectly, via SharedVolume 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 the SharedVolume has a name generated as a function of the name of the SharedVolume, so that applications not only cannot create a PVC directly against the efs-sc storage class, they cannot make assumptions about the name of the PVC 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 the efs-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?

2uasimojo commented 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?

nastacio commented 3 years ago

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.