Jeremy- Going back to your original example of the tree below. If DS baz is assigned to tenantId 2, then tenantIds 2.1, 2.1.1, 2.2 cannot modify baz, right?
If a CAG is created also with tenantId2, then I would expect the same behavior- only John as part of the 2 tenant can modify that CAG. Similarly, this CAG could only contain DS’ that belong to our are children of tenant 2. This seems to match existing behavior more closely? —Eric > On May 16, 2019, at 10:43 AM, Jeremy Mitchell <[email protected]> wrote: > > no, capabilities are very different than tenancy. > > capabilities dictate what you "can do" - i.e. you can modify CAG's if you > have the cacheassignmentgroup-write capability > tenancy dictates what you "can do it to". in this case, if CAG's have a > tenantId and you have the cacheassignmentgroup-write capability, then you > can ONLY modify CAG's that fall in your tenancy scope. > > although different, capabilities and tenancy work hand in hand to limit > what a user can do (permissions) and what they can do that to (scope). > > because CAG's have an embedded tenantable resource (delivery services), > this makes it a bit trickier. not only should tenancy dictate which CAG's > can be modified by the user, it should also dictate how those CAG's should > be modified (i.e. which delivery services can be impacted by a modification) > > jeremy > > > > On Wed, May 15, 2019 at 3:13 PM Eric Friedrich -X (efriedri - TRITON UK > BIDCO LIMITED c/o Alter Domus (UK) Limited -OBO at Cisco) > <[email protected]> wrote: > >> >> >>> 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] >>>>>>> >>>>>>> >>>> >>>> >> >>
