Managing shell tooling to edit ps1 for this is a bad idea, because there are already many other much longer established mutations people use that for (like git branch or activated Python environment), kubernetes can’t come along decades later and suggest to use the tool effectively one has to break those long standing workflows.

It’s always an available option for people who want it, but many many use cases are poorly served by it.

The RBAC thing is different. I am 100% for those RBAC limitation as long as I have total authority to make a devops admin do what I need them to do right when I need them to do it.

If my team is going to get alerted on build failures or service errors that require kubernetes mutation actions or exec to debug or resolve (99% of the time they do), then my team needs full admin access.

If rbac prevents access, then you better route the alerts to someone else or give us authority to compel instant triage responses.

In the 3 different companies I’ve worked in that use large kubernetes clusters, rbac has been a miserable problem across the board, because SREs don’t want to be responsible for triaging or resolving application team issues, and application teams will not honor alerts that are not actionable because of poorly conceived permissions issues where people mistakenly think they are setting useful access control policy but really they aren’t.