I think this is all still accurate and describes the differences between capabilities and tenancy and also how they work together to limit access : https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=68715910
(keep in mind capabilities are not currently implemented but hopefully will be shorty. for now, you probably just want to assign your new endpoints to the PrivLevelOperations role) On Thu, May 16, 2019 at 8:43 AM Fieck, Brennan <[email protected]> wrote: > Sure, but the question is if those permissions permeate their parents. > Suppose a DS exists assigned to tenant a. Tenant a has one child tenant: b. > If a user in tenant b has 'cacheassignmentgroup-write' capability, they can > certainly edit cache assignment groups within tenant b, but should they > be able to edit cache assignment groups for delivery services assigned to > tenant a? Because essentially that'll propagate to the root tenant. > Maybe that's not a problem, but I personally think it is. So assuming that > *is* a problem, then you're going to need to check the delivery service's > tenancy anyway, so really having separate tenancy on this assignment > doesn't actually do anything. > > IMO tenancy should only exist on objects, not relationships. To change > relationships between things, you should check the tenancy on the > objects being related, and then move forward if the user has the required > capabilities. Relationships as first-class objects introduces a lot of > complexities like what I described above. > ________________________________________ > From: Eric Friedrich -X (efriedri - TRITON UK BIDCO LIMITED c/o Alter > Domus (UK) Limited -OBO at Cisco) <[email protected]> > Sent: Wednesday, May 15, 2019 3:04 PM > To: [email protected] > Subject: Re: [EXTERNAL] [PROPOSAL] Cache Assignment Group REST API > > > On May 15, 2019, at 4:16 PM, Fieck, Brennan <[email protected]> > wrote: > > > > You could just set tenant permissions based on the owning tenant of the > Delivery Service. > > Should the child of a tenant be able to modify cache assignments of said > tenant's Delivery Services? > > I wouldn't think so. > EF> Isn’t this what the capabilities are for? If a user has > “cacheassignmentgroup-write” capability, then they can modify the > assignments for any delivery services in that tenant > > > ________________________________________ > > From: Jeremy Mitchell <[email protected]> > > Sent: Wednesday, May 15, 2019 1:22 PM > > To: [email protected] > > Subject: [EXTERNAL] Re: [PROPOSAL] Cache Assignment Group REST API > > > > example tenant tree: > > > > root > > - 1 (foo) > > -- 1.1 (bar) > > - 2 (baz) > > -- 2.1 (bee) > > --- 2.1.1 (bang) > > -- 2.2 (bop) > > > > the foo ds belongs to tenant 1, bar ds belongs to tenant 1.1, etc. > > > > a CGA is created with tenantId=2 which means it can only have the baz, > bee, > > bang and bop ds's in it. John belongs to the 2 tenant and adds all 4 > (baz, > > bee, bang, bop). > > > > Sally belongs to the 2.1 tenant, and only sees [bee, bang] in the CGA and > > does an update with [], so it blows away bee (the ds in her tenant) and > > bang (plus any child tenant ds's) > > > > Linda belongs to the 2.1.1 tenant, and sees [] in the CGA (because sally > > blew them all away) and does an update with [goo]. now the CAG has baz > and > > goo ds's. > > > > so basically, a user can only modify the ds's that they can see based on > > their tenant (and subtenants). and a CAG can only have certain ds's in it > > based on it's tenant... > > > > I "think" that would work....sounds a bit complicated but i really feel > > like tenancy probably belongs on a CAG because of its relationship with > > ds's. plus, then it would be nice to create CAG's for tenants. for > example, > > create a trial tenant and some trial ds's and some trial users and they > > have no choice but to use the trial CAG that has 2 caches in it or > > something. > > > > jeremy > > > > On Wed, May 15, 2019 at 1:01 PM Eric Friedrich -X (efriedri - TRITON UK > > BIDCO LIMITED c/o Alter Domus (UK) Limited -OBO at Cisco) > > <[email protected]> wrote: > > > >> What if the tenantId on the cacheassignmentgroup does not match the > >> tenantID on one of the included delivery services? > >> > >> On May 15, 2019, at 2:55 PM, Jeremy Mitchell <[email protected]> > >> wrote: > >>> > >>> I got an idea. If you made a cachegroupassignment a "tenantable" > >> resource, > >>> you could avoid the problem i mentioned above (having ds's hidden for > >>> tenancy reasons). so this instead: > >>> > >>> {"id": 1, > >>> "name": "name1", > >>> "description": "description1", > >>> tenantId: 2, > >>> "cdnId": 1, > >>> "servers": [1,2,...n], > >>> "deliveryServices": [10, 20, 30, 35] > >>> "lastUpdated": "", > >>> } > >>> > >>> this has a nice benefit as well. i.e. certain tenants (content > providers) > >>> have access to certain cachegroupassignment configurations. > >>> > >>> jeremy > >>> > >>> > >>> > >>> > >>> On Wed, May 15, 2019 at 12:43 PM Jeremy Mitchell < > [email protected]> > >>> wrote: > >>> > >>>> Just be careful that a GET /api/1.4/cacheassignmentgroups?id=4 doesn't > >>>> return a filtered list of delivery services because of tenancy > >>>> > >>>> {"id": 1, > >>>> "name": "name1", > >>>> "description": "description1", > >>>> "cdnId": 1, > >>>> "servers": [1,2,...n], > >>>> "deliveryServices": [10, 20, 30], <-- maybe there are really 5 > delivery > >>>> services but 2 of them (40 and 50) are hidden from you due to tenancy > >>>> "lastUpdated": "", > >>>> } > >>>> > >>>> and a subsequent PUT with the same json (plus a new delivery service > >> that > >>>> is added): > >>>> > >>>> {"id": 1, > >>>> "name": "name1", > >>>> "description": "description1", > >>>> "cdnId": 1, > >>>> "servers": [1,2,...n], > >>>> "deliveryServices": [10, 20, 30, 35] > >>>> "lastUpdated": "", > >>>> } > >>>> > >>>> doesn't wipe out 40 and 50. > >>>> > >>>> if you do this, it begs the question. how do you remove ALL ds > >> assignments > >>>> from a cache assignment group? > >>>> > >>>> also, how about > >>>> > >>>> DELETE /api/1.4/cacheassignmentgroups?id= > >>>> > >>>> instead of > >>>> > >>>> DELETE /api/1.4/cacheassignmentgroups/{id} > >>>> > >>>> jeremy > >>>> > >>>> On Wed, May 15, 2019 at 12:22 PM Eric Friedrich -X (efriedri - TRITON > UK > >>>> BIDCO LIMITED c/o Alter Domus (UK) Limited -OBO at Cisco) > >>>> <[email protected]> wrote: > >>>> > >>>>> Feature description > >>>>> > >>>>> -------------------- > >>>>> > >>>>> Mail Thread: > >>>>> > >> > https://lists.apache.org/thread.html/35ee49f4be1c30ff4a12c71e02897aee0e0d3d2f356640ab69ba247e@%3Cdev.trafficcontrol.apache.org%3E > >>>>> < > >>>>> > >> > https://lists.apache.org/thread.html/35ee49f4be1c30ff4a12c71e02897aee0e0d3d2f356640ab69ba247e@ > >>>>> <dev.trafficcontrol.apache.org>> > >>>>> > >>>>> Github Issue: https://github.com/apache/trafficcontrol/issues/3557 > >>>>> > >>>>> > >>>>> API Proposal > >>>>> > >>>>> ------------ > >>>>> > >>>>> POST,GET /api/1.4/cacheassignmentgroups/ > >>>>> > >>>>> PUT /api/1.4/cacheassignmentgroups/{id} > >>>>> > >>>>> {"id": 1, > >>>>> "name": "name1", > >>>>> "description": "description1", > >>>>> "cdnId": 1, > >>>>> "servers": [1,2,...n], > >>>>> "deliveryServices": [10, 20, 30], > >>>>> "lastUpdated": "", > >>>>> } > >>>>> > >>>>> > >>>>> DELETE /api/1.4/cacheassignmentgroups/{id} > >>>>> > >>>>> -- No request body > >>>>> > >>>>> This API is tenant-aware by delivery service. > >>>>> > >>>>> Query Parameters (all optional) > >>>>> If multiple filter parameters are specified, they are AND'd together > >>>>> - id: Filter for a specific entry > >>>>> - servers: Filter all entries containing this server > >>>>> - deliveryService: Filter all entries containing this DS > >>>>> > >>>>> - limit: Return maximum number of entries (default 20) > >>>>> - page: Return page n, with each page having limit number of entries > >>>>> (default 0) > >>>>> > >>>>> Body Parameters: > >>>>> - id: Numeric identifier, automatically assigned on creation. > >> [Read-Only, > >>>>> not allowed in PUT/POST] > >>>>> - name: Name of the cache assignment group > >>>>> - description Description of the cache assignment group > >>>>> - cdnId: ID of the CDN the cache assignment group belongs to > >>>>> - servers: List of server IDs. > >>>>> - deliveryServices: List of delivery service IDs. All caches in the > >>>>> servers list will be assigned to these delivery services > >>>>> - lastUpdated: Timestamp this cache assignment group was last > updated. > >>>>> [Read-Only, not allowed in PUT/POST] > >>>>> > >>>>> > >> > >> > >
