This post continues looking at my process of learning more about Kubernetes. I’ve been working through the 50 days of Kubernetes (K8s). Here I continue on with a few videos on secrets, configuration management and RBAC.

Secrets

I am glad that the idea of storing data securely has come to so many applications. Authentication, authorization, privileges, and more are complex and hard to get right. We continually see problems with passwords, certificates, and the link not being managed well.

Kubernetes has the concept of secrets, which can be values or file contents (like a certificates). These can then be sent or mounted to containers for use.

One problem, these are stored in the Kubernetes etcd (keyvalue store) in an unencrypted format. Kubernetes has new concepts to integrate into key management areas, like Azure Key Vault, to protect secrets, though Kubernetes privilege controls are still needed.

A gross simplification, but I learned a little more about what secrets are.

Configuration Management

This is interesting to me, because I like abstracting things away. In Kubernetes, we abstract a configuration object as a separate entity, which can then be applied to a container/pod later. This also works through deployments, allowing configurations to be part of the rolling deployment, which can prevent issues.

If you have good testing/evaluation of what is healthy. This is likely easier than comprehensive unit testing, but still.

A good idea, just not sure if this is too much.

RBAC

I always think of this as row-based, but it’s really role-based, so maybe that should be the way I translate RBAC in my head.

Like most systems that use RBAC, there is, of course, a role. The video wanders a bit in the explanation, but I’ll try to summarize what I learned. There are two facets to roles. First, these are verb/noun pairs that determine what permission is available for what resource. Like get/list for the verb, and pod, volume, service, etc. for the noun. These are setting up the permission side.

However, there is another facet. These roles can be set as cluster roles, similar to server roles for SQL Server, or at the namespace level, more like a database role. In either case, you are scoping permissions. Obviously, be careful with cluster roles.

The other side of this is the user. We can have users or groups used for these roles, similar to what is in SQL Server.

A simple explanation, but at least I have some idea of the concept.