Enabling Process Communication with Kube API Through Service Accounts

Humans are not the only ones who rely on a cluster. Processes in containers often need to invoke Kube API as well. When using RBAC for authentication, we need to decide which users will have permissions to perform specific actions. The same holds true for the processes running inside containers.

When we (humans) try to access a Kubernetes cluster with RBAC enabled, we are authenticated as users. Our username provides an identity that API server uses to decide whether we are allowed to perform intended actions. Similarly processes running inside containers might also need to access the API. In such cases, they are authenticated as a specific ServiceAccount.

ServiceAccounts provide a mechanism to grant permissions to processes running inside containers. In many ways, ServiceAccounts are very similar to RBAC users or groups. With humans, we use RoleBindings and ClusterRoleBindings to relate users and groups to Roles and ClusterRoles. When working with processes, the main difference is in the name and the scope. Instead of users or groups, we create ServiceAccounts which we bind to roles. However, unlike users that can be global, ServiceAccounts are tied to specific Namespaces.

This chapter assumes that you are already familiar with Namespaces, Ingress, Deployments, Roles, ClusterRoles, RoleBindings, ClusterRoleBindings, Users, and Groups. If you're not, please refer to The DevOps 2.3 Toolkit: Kubernetes (https://amzn.to/2GvzDjy) for more info.

We won't go into any more theory. Instead, we'll try to learn different aspects of ServiceAccounts through hands-on examples.

Table of Contents for Enabling Process Communication with Kube API Through Service Accounts

Create new playlist

Sign In

Sign Up

Table of Contents for
Enabling Process Communication with Kube API Through Service Accounts