Currently, views providing S3 buckets with different Security policies cannot overlap. For example if /share is presented as s3://vast.example.org/share-bucket from a View that has the NFS permissions model, I cannot then create a separate bucket underneath /share at /share/identity-policy-bucket that uses identity policies as the permissions model. This causes issues when we create an anonymous bucket over the entire extant share (as requested), but then we need to carve off a bucket somewhere under there that has more stringent requirements.
1 Like
Great feedback @carlilek !
I’ve pinged the product team to get them to chime in.
1 Like
Hi @carlilek, thanks for this feedback. Sounds like an interesting case of nested Views. If I generalize your use case, it’s about a setup where a top-level View has one security flavor, and underneath there is a lower-level View that has another security flavor.
Correct understanding?
1 Like
Yup, that’s correct! While we offer anonymous read-only access to internal buckets (which can be placed over the entire share), we require that buckets that are presented via a proxy server in our DMZ use access keys for the same read-only access.
It would be helpful to have that nested bucket available internally as anonymous if someone were to enter through the higher level bucket URL, but as I think about that, it seems kind of impossible. 