Authentication and Authorization
Authentication is the process establishing the identity and authorization is the process of establishing the permissions for that identity. The identity is usually federated from an identity database like Active Directory into the cloud providers IAM or setup in IAM directly. For big organizations, federation is a common setup.
To control what permissions an identity has inside the cluster Kubernetes has support for role based access control (RBAC). RBAC allows to define roles with rules that allow access by resource, api group and verb. Apart from defining custom roles, Kubernetes also has a set of built-in roles.
Access control that does not get in the way
Traditionally, access is commonly controlled per environment with privileged access for operations and limited or no access for engineering. To ensure your team can move fast and fix things if they break them a cloud native approach to authorization is required.
Additionally, by using declarative automation for both infrastructure as well as application management, we can replace the need for privileged individuals with transparency, peer reviews and auditable changes applied through CI/CD.
Similar to how rethinkinking our approach to clusters and environments enabled us to work on both infrastructure and applications at the same time without one blocking the other, it also allows us to foster a culture of shared responsibility and trust between team members by rethinkinking our approach to authorization.
Small teams and big organizations
Smaller teams often have no clearly defined roles. In that case each team member, to be able to pick up any task might have cluster-wide admin access.
In bigger organizations it is more likely that there is some form of shared responsibility between a team responsible for infrastructure and clusters and a team building and running an application on the clusters. In this case, cluster-wide admin access would be limited to the infrastructure team but the application team should still have admin access to the application's namespaces.
When getting started, even in big organizations, it's a viable option to start with the small team approach and transition into the big organization approach as adoption through the organization increases.
Unprivileged day-to-day with escalation
A proven approach is also to work with an unprivileged, e.g. a read-only, account during your day to day work but having the ability to switch to a privileged account or role. Similar to how you work with a regular user but can easily prepend sudo if you need to run a command as root.
How to implement this depends on the identity database being used and how authentication between that database and Kubernetes is setup. But a general approach can be to have two contexts defined in the kubeconfig file and depending on the context's user section RBAC assigns a different role inside the cluster.
Repository, pipeline and testability
To ensure testability of your RBAC configuration the recommended appraoch is to apply it through the infrastructure repository and pipeline. This way you can safely try changes without risking affecting your team mates.