Open jhrv opened 10 months ago
I think it's a good idea to implement the option of restricting developer access to pods.
Not so sure about making it the default. Perhaps we can turn it on for existing namespaces, but leave it disabled by default for new namespaces?
Not so sure about making it the default.
Could you elaborate a bit on why?
The idea of making it secure by default is that we force them to make an active choice to turn it on. It requires that we announce that this is the case, and if they need it - it's only a few mouse clicks away from being turned back on.
I think by doing it like this, we end up with a lot more teams with a secure default than the other way around.
Another feature that might be toggle-able is the ability to view
a secret. create
and delete
is fine
Should we have more roles for members?
viewers
can only list things (get, describe, logs)editors
can make changes (create, apply, delete)
We have some use-cases where teams still process sharp data. Some of these teams wish to remove the possibility for users to
exec
orport-forward
into pods, and gain access both in terms of credentials and network connectivity.Not having this possibility should be the default. This will ensure that the teams that have this possibility today but don't need it has a reduced attack surface. However, we still have use-cases (although a bit fuzzy and unexplored) that require this - so we might not be able to remove it entirely.
One way could be to reduce the default permissions of the
nais-developer
role, and make another role that is applied to the team-group only if the feature has been enabled through teams.