Improve funtionality of access lists for shares

Registered by Valeriy Ponomaryov

- implement request validation on service side;
- implement proper http codes in responses for valid and invalid requests;
- remove request-replacing from client if request is invalid

Blueprint information

Status:
Complete
Approver:
Ben Swartzlander
Priority:
Medium
Drafter:
Valeriy Ponomaryov
Direction:
Approved
Assignee:
Andrii Ostapenko
Definition:
New
Series goal:
Accepted for icehouse
Implementation:
Implemented
Milestone target:
None
Started by
Valeriy Ponomaryov
Completed by
Valeriy Ponomaryov

Related branches

Sprints

Whiteboard

Am I correct that this is an ACL that control the visibility of a share to a client machine?
If the share is visible then validation of a user with the tenant-specific Authentication Server and normal NFS/CIFS user validation still applies?

--Valeriy Ponomaryov--
Current implementation of access lists handles ipv4 rules (with problems mentioned in blueprint body), which describe who can mount share.

Existing features in Manila:
- If no rules - no one can mount it;
- each rule can be created only for one share at a time;
- no limit for rules amount.

It is also evidently, that there should be another blueprint, which will describe extended ACL functionality with more flexible possibilities to use shares.

-- Caitlin Bestler --
What I'm seeking to clarify is the relationship between Manila ACLs and the existing access controls already enforced by NAS servers.

I believe that Manila ACLs are *pre*-checks that control whether or not you are allowed to
ask the existing NAS server whether you can mount a volume, access a directory, etc.

Your answer almost implies that the Manila ACLs *replace* the existing ACL checking,
which I think would be a mistake.

--Valeriy Ponomaryov--
I see, here is little mess with definitions.

Access-lists in Manila - it is name of functionality, which designed to modify exports file for NFS. This file describes rules who can mount and what.

There are also policy.json, which is used to configure permissions for user roles for different actions (as in Nova, Cinder, etc...).

And last thing - all requests contain tenant_id and Manila returns info only for that tenant, after validating policy from policy.json file.

Hope, I answered your question.

- Caitlin Bestler -

What is still unclear is how a Tenant Administrator controls access to shares on strictly Tenant
internal basis. Can they see *just* their rules? Can they protect their rules from being altered by
Manila? Can they edit them *after* Manila has edited them?

Ideally the Tenant administrators would see *nothing* of what Manila is doing. I understand that
a Manila flattened global name will be visible, but what other impacts are there that are visible
to the Tenant Administrator? They need to be extremely minimal.

--Valeriy Ponomaryov--
Tenant administrator operates ManilaClient and can make changes only by making requests to Manila.
His permissions to do some requests are stricted by policy.json file.
Manila output is the only info, you can get as Tenant Administrator.
Every user, which allowed to perform request, can see request sequence (what do Manila) with --debug flag in request. It is the only way to see some detailed work.

-- Caitlin Bestler --

Requiring Tenant Administrators to work through ManilaClient to change Tenant specific ACLs
is a major change to current operations. This may be acceptable when compared to the VLAN
heavy solution, but we need to clearly enumerate this limitations of the flat model. These should be design limitations noted upfront, not "bugs" discovered later.

Gerrit topic: https://review.openstack.org/#q,topic:bp/improve-acl-functionality,n,z

Addressed by: https://review.openstack.org/62901
    Adds validation of access rules

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.