2 ms·
There have been several comments regarding authentication but what I see as the glaring issue is the lack of authorization. Without some sort of RBAC implemente
by tssva 10y ago
There have been several comments regarding authentication but what I see as the glaring issue is the lack of authorization. Without some sort of RBAC implemented within Teleport and/or integration with external authorization solutions the use cases for Teleport are going to be limited to very simple scenarios. The suggestion mentioned within a couple of github issues of using os logins as roles is a non-starter in a large number of environments due to security and audit considerations.
I understand that trusted clusters were originally intended as a means to allow Teleport to work through restrictive firewalls but the same type of environments which are going to necessitate the use of trusted clusters are also likely to require more restrictions regarding which users are allowed to access the cluster from a trusted cluster. The current solution of specifying individual allowed users is too limited and doesn't scale.
Gravity, which Teleport is ripped from, is a system to support SaaS providers in deploying and managing onsite implementations within enterprise networks. Maybe these issues are addressed at a different level within Gravity but if not I would be hesitant to allow a SaaS provider to deploy within my network using Gravity.
- old-gregg 10y agotssva, great points. Gravity is basically Kubernetes-on-Teleport, and our distribution of k8s has additional security measures built-in, where Teleport (in a library form) is acting more or less on a lowest "root" level which the infrastructure owner can optionally turn on/off for pieces of their infrastructure, we'll be gradually publishing more documentation on Gravity soon, but you're right: RBAC lives one level higher.