How Zero-Code works

Learn how Zero-Code puts sign-in and access rules in front of services on Kubernetes without changing them, and the three steps every workload goes through.

Zero-Code puts sign-in and access rules in front of services that run on Kubernetes. It does on the node what a sign-in library would do inside your application, so your services need no code for it.

You install Zero-Code once on a cluster. The install is an operator and a node agent, one copy of which runs on every node. Nothing is added to your pods, and your services are not rebuilt or restarted.

This page explains the model. To put it on a cluster, see Install Zero-Code on a cluster.

What Zero-Code does

Zero-Code makes four kinds of decision in front of a service.

The first three are decided on each request, before it reaches your service. The fourth is decided as a workload opens a connection. How enforcement works describes where each decision is made.

The three steps

Every workload goes through the same three steps in the AuthFI console: Observe, Classify and Protect. You find a cluster's workloads under Zero-Code > Kubernetes, on the cluster's Workloads tab.

Observe

Observe shows you what a workload does. Once the node agent is installed, the cluster's services, workloads and kernel programs are discovered, never typed by hand.

A workload is watched for 24 hours before it can be protected. This gives a dependency that has not shown up yet time to appear, so that protecting the workload does not cut it.

Classify

In Classify you say what the workload is and what it serves. The class decides how AuthFI treats it.

For an App, you also answer What does it serve? with two switches.

• Pages: people sign in with your project before a page opens. See Protect a web app.
• API: every call carries an access token your project issued. The API gets its own audience, the name a token must be issued for, and a token issued for one API is denied at another. See Protect an API.

Protect

In Protect you decide who may reach the workload, then turn protection on. Requirements are chosen from your project's own permissions, roles and groups. AuthFI drafts rules from the traffic it saw, and you change anything before you save.

A saved draft is in monitor mode: the rules are recorded, and each request they would deny is recorded, but nothing is denied. Turn on protection… puts the rules in enforce mode. They apply on the nodes running the workload in about 30 seconds.

Where a workload stands

Each workload carries one status in the console: To classify, To protect, Observing, Partly protected, Protected or System. The Workloads tab filters by status.

Protected means that every rule enforces and every path to the workload is verified closed. System marks a workload classified as System.

What a caller sees

Once a workload is protected, a caller that does not meet the rules gets one of these answers.

Every denial is written to the audit record with the layer that denied it.

Defaults that keep a cluster safe to change

Four behaviours hold for every cluster and every workload.

• Monitor mode is the default at every level. Nothing is denied until you turn protection on.
• Open connections are left alone. A connection already open when you turn protection on is untouched until it closes.
• Some paths are always let through. These are health checks, sign-in callbacks and a short fixed list of common public paths. The list is in Paths that are always let through.
• The cluster owner holds the brake. The cluster owner can turn enforcement off on a node, and AuthFI cannot override that. See The brake.

Requirements

The versions each one needs are in Before you begin on the install page.

Next steps