Hacker News new | past | comments | ask | show | jobs | submit login
Gatekeeper – Policy Controller for Kubernetes (github.com)
73 points by alexellisuk 9 months ago | hide | past | favorite | 16 comments

There was an article here yesterday where the comments were almost nothing but complaints about administering Kubernetes.

Tools like this and KNative make me feel like Kubernetes is the next UNIX: it’s a platform. You don’t use it to run a set of server processes. You use it to leverage an entire distributed platform.

One way to look at Kubernetes is to say that it consists of a database of arbitrary objects and controller programs that take actions when those objects change.

This is a good system to control software deployment (i.e. controllers react to objects that represent the desired state of a set of containers and a way to access them) but it can be a lot more generic than that.

Kubernetes isn't like other systems where the core is locked down and users can add plugins that have limited privileges but aren't really the same as the built-in stuff -- examples include browser extensions, or maybe Lua plugins for Nginx.

In Kubernetes you can create objects and controllers that are first-class citizens just like the ones it comes with out of the box. They go in the same database as the built-in objects. You can remove or replace parts of the core system if you want to. This is what makes it a platform.

Yep this is exactly the way I think about it. It’s a kernel for a distributed operating system.

Wait until you see how much RAM that needs. Take a look at a lightweight alternative like OpenFaaS, but yes: the Internet is your computer.


Gatekeeper is an easy way to deploy and manage admission policies in Kubernetes. Kubernetes admission policies allow you to set custom rules on what can and cannot be deployed in Kubernetes.

Gatekeeper is a CRD (Custom resource definition). This means that you can write policies as Kubernetes objects and deploy them to the cluster the same way you'd deploy any other object to cluster.

Gatekeeper policies are rego (created by OpenPolicyAgent), which is based on Datalog, and allows you to create these policies using a very rich and powerful language.

Ah, I think I get it now. So you could reject deployments for oversubscribing resources or using unsupported docker repos, as some contrived examples.

Yeah exactly. Kubernetes has some good built in tools for resource checking (and pods in general imo). I've found this most useful for asserting rules on ingress and services to control exposing of services to the public.

The nice thing is that you don't need to write custom admission controllers for each of your policies. You just need to write the policies and give them to Gatekeeper.

Rego is inspired by Datalog, but the syntax is very different.

Yes, very true. The rego syntax is not Datalog, but the language was inspired by Datalog

More specifically, Gatekeeper is (unless I’m mistaken) an “Operator,” which is a Kubernetes-native app that extends Kubernetes itself.

I would say it's a controller, because it is integrated with the Kubernetes system and reacts to changes to objects.

An operator generally creates Kubernetes objects as part of implementing a complex workflow that is normally taken care of by a human "operator". An example of this is the Cassandra operator, where you save a single object describing a Cassandra cluster at a fairly high level and the operator takes care of creating the pods and volumes and services and configuring the databases (and tearing it all down when you don't want it anymore).

Controller is usually reserved as the implementation that satisfies an API, regardless of what it does. Operators hide operational complexity via judicious use of APIs - if using it in the broadest sense the ingress API + a particular controller implementation (nginx which is a deployed object vs an ALB which might just be programmed) is an “operator”.

A Postgres operator could manage Postgres instances in pods, or it could program AWS RDS. Having a deployable entity isn’t really required. The thing reading the API and updating those objects is definitely a controller.

Although an ingress operator could be even higher level and ensure one or more ingress controllers were actually deployed (if you had an IngressController resource that made it easy to deploy them)

I wouldn't call this an operator since it isn't operating other applications.

It's a controller which is configured by Kubernetes Custom Resources that extends Kubernetes as you say.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact