Skip to content

6.10 Kubernetes Authorization Intro

🎯 What is Authorization?

Authentication answers:

"Who are you?"

Authorization answers:

"What are you allowed to do?"

After authentication, Kubernetes evaluates whether the requested action is permitted.

🔐 Why Authorization Matters in Production

In shared clusters:

  • Developers should deploy applications, not modify nodes.
  • CI/CD systems need scoped namespace access.
  • Monitoring tools require read-only permissions.
  • Nodes must report status but not manage cluster configuration.

Warning

Poor authorization design can lead to privilege escalation and full cluster compromise.

🧩 Supported Authorization Mechanisms

Used for kubelets.

  • Allows nodes to read Pods, Services, Endpoints
  • Allows nodes to update Node & Pod status
  • Requires user in system:nodes group
  • Username format: system:node:<node-name>

Attribute-Based Access Control.

  • JSON policy file
  • Direct user → permission mapping
  • Requires API server restart for changes
  • Difficult to scale

Role-Based Access Control.

  • Define Roles (permissions)
  • Bind users/groups via RoleBinding
  • Namespace or cluster scope
  • No API server restart required

Delegates authorization decision to external service (e.g., Open Policy Agent).

  • Used in enterprise environments
  • Centralized policy enforcement

🏗 RBAC Model (Production Standard)

  1. Create a Role (set of verbs + resources)
  2. Bind users/groups via RoleBinding
  3. Apply least privilege principle

Example:

rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "create"]

Success

RBAC is the recommended and default production authorization mechanism.

⚙ Authorization Modes Configuration

Configured in kube-apiserver:

--authorization-mode=Node,RBAC,Webhook

If not specified:

AlwaysAllow

Danger

Never run production clusters with AlwaysAllow.

Available modes:

  • AlwaysAllow
  • AlwaysDeny
  • Node
  • ABAC
  • RBAC
  • Webhook

🔄 Authorization Evaluation Order

When multiple modes are configured:

  1. Request hits first authorizer
  2. If denied → passed to next
  3. If approved → authorization stops

Example:

--authorization-mode=Node,RBAC,Webhook
  • Node checks node requests
  • RBAC evaluates user permissions
  • Webhook handles custom policies

🌐 Webhook Authorization Flow

  1. User request sent to API server
  2. API server calls external webhook (e.g., OPA)
  3. Webhook returns allow/deny
  4. API server enforces decision

Tip

Use webhook authorization for enterprise-grade compliance enforcement.

🛡 Production Best Practices

✅ DO

Success

  • Use Node + RBAC combination
  • Follow least privilege principle
  • Scope permissions to namespaces
  • Enable audit logging
  • Restrict cluster-admin usage
  • Review RoleBindings regularly

❌ DON'T

Danger

  • Do NOT use AlwaysAllow
  • Do NOT grant wildcard verbs (*)
  • Do NOT use ABAC in new deployments
  • Do NOT give cluster-wide access unnecessarily
  • Do NOT disable authorization

🚨 Production Risks

Risk Impact
Over-permissive RBAC Privilege escalation
Excessive cluster-admin Full control takeover
Misconfigured webhook Denial of service
No audit logs Undetected abuse

🔎 Authentication vs Authorization

Authentication Authorization
Validates identity Validates permission
Certificates, Tokens RBAC, Node, Webhook
Who are you? What can you do?

🎯 Summary

  • Authorization controls actions after authentication
  • Node authorizer handles kubelet requests
  • RBAC is the production standard
  • Webhook enables external policy control
  • AlwaysAvoid AlwaysAllow in real clusters

Quote

Authentication grants entry.
Authorization determines capability.