@mitchell852 Actual PostgreSQL users. So, Traffic Ops users would _be_ PostgreSQL users. There wouldn't be a single "trafficops" Postgres user, every TO user would have their own user in Postgres itself.
PostgreSQL has row-level security, which makes such a thing possible. You can configure a user to only have access to certain rows, for example, only their Delivery Service in the `deliveryservice` table. It's definitely worth considering. But we should be aware it's not trivial. It would require a significant amount of configuration, and code to do that configuration, to make it possible to create users and assign them the complex permissions required. Also worth noting, we would have to move to PostgreSQL users for https://github.com/begriffs/postgrest if we ever transition the TO API to PostgREST (Which I support, it means drastically less code we have to maintain). It's also possible to set up LDAP with Postgres: https://www.postgresql.org/docs/9.4/static/auth-methods.html#AUTH-LDAP On Thu, Jun 1, 2017 at 9:41 AM, Jeremy Mitchell <[email protected]> wrote: > > I also wonder if we shouldn't try to leverage transitioning our user > management to Postgres. > > I don't understand what that means. We do use Postgres for user > management...there is a tm_user table in Postgres and a user has a role > (which will soon have capabilities). That is how users are managed and it > would be a pretty big shift to move away from that... > > I think I'm fine with Rob's PR - > https://github.com/apache/incubator-trafficcontrol/pull/627 > > which will basically break everything if you are depending on LDAP only. > For example, if my LDAP username/pass is jeremy/password but there is no > user in the tm_user table with username=jeremy, then my authentication will > work but I will not have a pleasant experience in Traffic Ops as pretty > much every route will now result in a 404. > > ..but the workaround is to create a user with username=jeremy and assign me > a role.. > > and that's rob's intent..if you are ldap only, nothing really > works...(except a few routes) > > Jeremy > > On Thu, Jun 1, 2017 at 9:10 AM, Dewayne Richardson <[email protected]> > wrote: > > > I have a question in a similar vein, how often do we really use LDAP? My > > understanding is we created LDAP access to allow external users in to see > > our TO Graphs. Now that graphs are in Graphana is the need for LDAP > still > > needed? If we require anyone using TO or the TO API to be in the > database > > it would alleviate this LDAP security issue entirely. > > > > I also wonder if we shouldn't try to leverage transitioning our user > > management to Postgres. Postgres has many options for authentication > (as I > > mentioned at the Summit), which would allow for more flexibility at TO > > installations. > > > > -Dewayne > > > > On Wed, May 31, 2017 at 9:24 AM, Robert Butts <[email protected]> > > wrote: > > > > > We have a PR https://github.com/apache/incubator-trafficcontrol/pull/ > 627 > > > to > > > change Traffic Ops to only allow LDAP users _not_ in the Traffic Ops > > > database to view non-sensitive information, like graphs and total CDN > > > bandwidth. > > > > > > To be clear, users will still be able to authenticate with LDAP, as > long > > as > > > their user name is in the database. This only prevents access for LDAP > > > users whose name is not in the database. > > > > > > If you have LDAP-only users who need access, you can simply add their > > user > > > name to the Traffic Ops database to allow continued access. They don't > > even > > > need a password, simply inserting the username is sufficient. > > > > > > LDAP is a security risk, especially for large organizations. Allowing > all > > > non-CDN personnel in the organization full information access, even > > > read-only, means an attacker has only to compromise a single account in > > the > > > organization, and they can see the full list of CDN server IPs and > FDQNs, > > > as well as the specific ATS and CentOS versions, in order to take > > advantage > > > of known exploits against those versions. > > > > > > Does anyone have any issues with that? Is anyone using LDAP without > > > usernames in the database, who needs continued access? We just want to > > make > > > sure we're not breaking anyone before we merge this, and figure out a > > > solution if we are. Thanks, > > > > > >
