Headlamp: a new UI for Kubernetes
If you&#x27;ll forgive a bit of shaking-fist-at-clouds...<p>&gt; Role-aware UI<p>&gt; One problem with many read-write (CRUD) user interfaces is that they are not aware of underlying access controls. For example, displaying the update&#x2F;delete buttons is misleading if the user has actually no permissions to modify the resource. So Headlamp checks Kubernetes RBAC settings and displays only those controls whose actions can be performed. So, if the user does not have permission to edit a resource, the edit button will not be displayed.<p>&gt; This results in a much better UX, because it is obvious to the operator what actions are available based on their permissions at the time.<p>I strongly disagree.  It&#x27;s quite the opposite, in fact.  Hiding UI based on permissions creates an infuriating UX, because there&#x27;s no way for the operator to tell what actions are possible-but-forbidden, and those they simply can&#x27;t find in the interface.<p>Click Edit -&gt; &quot;Access denied&quot; -&gt; Ah, I need to ask my admin for additional permissions<p>No Edit button at all -&gt; Where the f... -&gt; Ah, this software sucks<p>Of course, this is not to say the the underlying idea is bad.  By all means, check the user&#x27;s permissions proactively and <i>disable</i> the buttons (with explanation of why the button is disabled).  And this is very much a case-by-case thing: it would obviously be silly for Amazon product pages to show everyone a disabled edit button.<p>But please, if you&#x27;re designing administrative software for power users, don&#x27;t dumb it down.