Along those lines, there are currently no constraints in the db to
enforce that everything has an assigned tenant. I'd like to change that.
Currently, it's possible to have tenancy turned on but still have NULL
tenant_id on a user, deliveryservice, or origin. That leads to ambiguous
situations that can be painful to handle in code. Here's what I'd like to
suggest:
If the use_tenancy parameter is OFF (0), set the tenant to ROOT for any
item without an assigned tenant. If ON, create a new tenant
("unassigned"?) and assign any NULL tenant ids to that instead -- this
allows the admin to easily find the stray ones and assign them
appropriately. Once all those are assigned, we can add the constraints
to the db to enforce tenancy. Then, we can do away with the code that
supports the use_tenancy flag and simplify the Traffic Ops code.
Thoughts?
-dan
On Thu, Jun 21, 2018 at 8:04 AM Dewayne Richardson <dewr...@apache.org>
wrote:
> +1 I think giving reasonable defaults and making the role/capabilities
> feature available makes for it's awareness as well.
>
>
> -Dew
>
> On Sat, Jun 16, 2018 at 9:18 PM Dave Neuman <neu...@apache.org> wrote:
>
> > I'll admit I am not super close to this problem so I don't understand it
> > well but, from what I have read, I tend to agree with Jeremy. If we are
> > going to have roles/capabilities we need to just incorporate them into
> the
> > system and be done with it. We should have able to provide reasonable
> > defaults and reasonable ways for people to do things that makes it
> tenable.
> >
> > On Fri, Jun 15, 2018 at 9:45 AM Jeremy Mitchell <mitchell...@gmail.com>
> > wrote:
> >
> > > regarding tenancy:
> > >
> > > @Nir is right. If you don't feel like using tenancy, then you give all
> > your
> > > users tenant=root. so tenancy is easy to sidestep if you're not
> > interested
> > > in using it.
> > >
> > > regarding roles:
> > >
> > > here are our current roles:
> > >
> > > admin (priv level=30)
> > > operations (20)
> > > portal (15) <-- terrible name for a role btw. probably my fault
> > > federation (15)
> > > steering (15)
> > > ort (11)
> > > read-only (10)
> > > disallowed (0)
> > >
> > > ^^ in this world, it is your role's priv level that determines what you
> > > can/cannot access
> > >
> > > when roles/capabilities are introduced our roles will look like this:
> > >
> > > admin (all capabilities)
> > > operations (the capabilities required to at a minimum to reproduce
> > current
> > > access level of priv level=20. capabilities yet to be determined)
> > > portal (the capabilities required to at a minimum to reproduce current
> > > access level of priv level=15. capabilities yet to be determined)
> > > federation (the capabilities required to at a minimum to reproduce
> > current
> > > access level of priv level=15. capabilities yet to be determined)
> > > steering (the capabilities required to at a minimum to reproduce
> current
> > > access level of priv level=15. capabilities yet to be determined)
> > > ort (the capabilities required to at a minimum to reproduce current
> > access
> > > level of priv level=11. capabilities yet to be determined)
> > > read-only (the capabilities required to at a minimum to reproduce
> current
> > > access level of priv level=10. capabilities yet to be determined)
> > > disallowed (no capabilities)
> > >
> > > ^^ in this world, it is your role's capabilities that determine what
> you
> > > can/cannot access. if you're not interested in a "complex permissions
> > > framework" as @Rob calls it :) , you really have to do nothing and the
> > > access level of your users should not change (assuming we define the
> > proper
> > > capabilities for each role).
> > >
> > > sooo...if in TC 3.0, we make both (tenancy and roles/capabilities) an
> > > integral part of the system we can, like rob said, simplify a bunch of
> > > code. it's hard enough to explain access control/permissions to people.
> > > having to explain 2 ways is almost impossible imo :)
> > >
> > > and yes, @Rob shims could be added to TP and/or the TO API to handle
> both
> > > ways but again, more complexity=more bugs, etc. IMO we just need to
> move
> > > forward towards the new approach and leave the old behind...
> > >
> > > Jeremy
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Thu, Jun 14, 2018 at 11:39 PM, Nir Sopher <n...@qwilt.com> wrote:
> > >
> > > > Hi,
> > > > I'm with Jeremy on that.
> > > > The "use_tenancy" flag came to allow simple transition to the
> tenanted
> > > > world:
> > > > On the transition, the TC owner should adjust all tenancies, most
> > > > importantly create a "root tenant" admin, and only then put the
> > > use_tenancy
> > > > flag on.
> > > >
> > > > For 3.0 I believe that tenancy should become mandatory - transition
> > > period
> > > > done.
> > > > A TC that does not need tenants, should just put all elements under
> the
> > > > root tenant. No need to maintain two pathes in the code....
> > > >
> > > > We can do the same for "role/capability" - adding a global knob just
> > for
> > > > the transition.
> > > >
> > > > Nir
> > > >
> > > > On Thu, Jun 14, 2018 at 9:38 PM, Robert Butts <r...@apache.org>
> wrote:
> > > >
> > > > > >will the self-service stuff rob butts is working on be affected in
> > any
> > > > > way? Will self-service truly be turned off via a parameter?
> > > > >
> > > > > What I'm working on, change integrity, shouldn't be affected by
> > turning
> > > > off
> > > > > tenancy/roles/capabilities.
> > > > >
> > > > > And we shouldn't turn off the API-visible parts of what I'll be
> > doing:
> > > DS
> > > > > snapshots, server snapshots, etc.
> > > > >
> > > > > We should be able to turn off the complex permissions system for
> > > > > self-service, while still retaining safe change integrity via the
> > > > timestamp
> > > > > system.
> > > > >
> > > > > >it would be nice if TC 3.0 made tenancy / roles & capabilities a
> > > > > requirement
> > > > >
> > > > > Requiring tenancy/roles/capabilities would certainly make the code
> > > nicer,
> > > > > but I'm afraid it'll make the software much more difficult to use,
> > for
> > > > > users who want an internal CDN, and have no need for a complex
> > > > permissions
> > > > > framework.
> > > > >
> > > > > @mitchell852 Is it possible to add GUI shims in Traffic Portal,
> > and/or
> > > > API
> > > > > helpers, to make the interface pretend like
> > tenancy/roles/capabilities
> > > > > don't exist? E.g. to grant all permissions and the root tenant to
> all
> > > > users
> > > > > on user-creation, if the "use_self_service" config flag is set? So
> > all
> > > > the
> > > > > code can keep working the same way, but people who don't need
> > > > > tenancy/roles/capabilities can still have the existing simpler
> > > interface?
> > > > > How difficult would that be?
> > > > >
> > > > >
> > > > > On Thu, Jun 14, 2018 at 12:18 PM, Jeremy Mitchell <
> > > mitchell...@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > I like the idea but what will it really mean to turn off
> > > > > use_self_service.
> > > > > > I know it will mean tenancy will be disabled and API permissions
> > > won't
> > > > be
> > > > > > checked against a user's capabilities, but will the self-service
> > > stuff
> > > > > rob
> > > > > > butts is working on be affected in any way? Will self-service
> truly
> > > be
> > > > > > turned off via a parameter?
> > > > > >
> > > > > > IMO it would be nice if TC 3.0 made tenancy / roles &
> capabilities
> > a
> > > > > > requirement. No more turning it on and off. The scope of what you
> > see
> > > > is
> > > > > > dictated by your tenancy and the api's that you have access to
> are
> > > > > dictated
> > > > > > by your capabilities.
> > > > > >
> > > > > > Jeremy
> > > > > >
> > > > > > On Thu, Jun 14, 2018 at 11:49 AM, Volz, Dylan <
> > > dylan_v...@comcast.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi Traffic Controllers,
> > > > > > >
> > > > > > > I am working on enforcing the roles->capabilities system as a
> > > > > replacement
> > > > > > > for the soon-to-be legacy priv level system. Like tenancy this
> > is a
> > > > > > feature
> > > > > > > moving us towards self-service; so to minimize our
> code/behavior
> > > > paths
> > > > > > > I would like to propose renaming the use_tenancy parameter to
> > > > > > > use_self_service, so that if it is turned on both tenancy and
> > > > > > capabilities
> > > > > > > are applied. This prevents some hairy cases arising when
> > > capabilities
> > > > > are
> > > > > > > on and tenancy is off or vice versa. Let me know if you have
> any
> > > > > > questions,
> > > > > > > concerns, or suggestions.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Dylan
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
