Kubernetes Control Plane Extension Points

Kubernetes Control Plane Extension Points is the complete, specific inventory of every distinct hook the control plane exposes for external code to participate in its behavior, spanning authentication, authorization, admission, scheduling, the API surface itself, and audit logging, each a formally separate mechanism with its own registration object, protocol, and position in the control plane's processing pipeline.

Authentication Extension: Webhook Token Authentication

Hook Position

Registered via --authentication-token-webhook-config-file, this extension point formally allows an external service to resolve identity from an otherwise unrecognized bearer token, invoked as one authenticator among the configured chain, at the very earliest stage of request processing.

kube-apiserver --authentication-token-webhook-config-file=/etc/kubernetes/webhook-authn.yaml

Authorization Extension: Webhook Authorization

Hook Position

Registered via --authorization-webhook-config-file, this extension point formally allows an external service to render allow, deny, or no-opinion decisions as a module within the authorization chain, positioned immediately after authentication and before admission.

kube-apiserver --authorization-mode=Node,RBAC,Webhook --authorization-webhook-config-file=/etc/kubernetes/webhook-authz.yaml

Admission Extensions: Mutating and Validating Webhooks

Two Distinct Registration Objects

MutatingWebhookConfiguration and ValidatingWebhookConfiguration formally register two separate extension points within the admission pipeline, invoked at their respective mutating and validating sub-chain positions, each matched against requests by API group, resource, and operation.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: codartium-policy
webhooks:
  - name: check.codartium.io
    rules:
      - apiGroups: [""]
        resources: ["pods"]
        operations: ["CREATE"]

ValidatingAdmissionPolicy as an In-Process Alternative

ValidatingAdmissionPolicy formally provides an extension point evaluated entirely within the API server process using CEL expressions, occupying the same validating admission position without requiring an external network call.

API Extension: Aggregated API Servers

Registering an Additional API Group

An APIService object formally registers an entirely separate API server process to serve a specific API group, with the primary API server proxying matching requests to it transparently, extending the API surface itself rather than intercepting requests to existing resources.

apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  name: v1beta1.metrics.k8s.io
spec:
  service:
    name: metrics-server
    namespace: kube-system
  group: metrics.k8s.io
  groupPriorityMinimum: 100
  versionPriority: 100

CustomResourceDefinitions as a Lighter-Weight API Extension

CustomResourceDefinition formally provides a second, more common API extension point, registering a new kind served directly by the existing API server's own built-in storage rather than requiring a separate aggregated server process.

Scheduling Extensions: Framework Plugins and Extenders

In-Process Plugins

The scheduling framework formally exposes named extension points, Filter, Score, Reserve, Permit, and others, compiled directly into the scheduler binary or a custom scheduler build, offering the deepest level of scheduling customization.

Out-of-Tree Extenders

Scheduler extenders formally provide a webhook-style extension point for filtering and prioritizing without requiring a custom scheduler binary, configured via a scheduler policy referencing external HTTP endpoints consulted at specific points in the scheduling cycle.

extenders:
  - urlPrefix: "http://codartium-extender.kube-system.svc:8080"
    filterVerb: filter
    weight: 1

Cloud Provider Extension: cloud-controller-manager Interface

A Defined Go Interface, Not a Network Protocol

Unlike the webhook-based extension points above, cloud provider integration formally extends the control plane through a compiled Go interface implemented by a provider-specific binary, covering node lifecycle, route management, and load balancer provisioning, linked into a distinct cloud-controller-manager process rather than called over the network at runtime.

cloud-controller-manager --cloud-provider=codartium-cloud

Credential Extension: Exec and Image Credential Providers

client-go Exec Plugins

kubeconfig files formally support an exec credential plugin extension point, invoking an external binary to dynamically obtain client credentials at connection time, used for integrating with external identity systems that issue short-lived tokens.

users:
  - name: codartium-user
    user:
      exec:
        command: codartium-auth-plugin
        apiVersion: client.authentication.k8s.io/v1

Kubelet Image Credential Providers

Separately, the kubelet formally supports image credential provider plugins, external binaries invoked to obtain registry authentication dynamically when pulling container images, an extension point distinct from and unrelated to API server client authentication.

Observability Extension: Audit Backends

Webhook Audit Backend

Beyond log-file audit output, the API server formally supports a webhook audit backend, streaming structured audit events to an external HTTPS service in real time, an extension point for feeding audit data into external SIEM or compliance systems.

kube-apiserver --audit-webhook-config-file=/etc/kubernetes/audit-webhook.yaml

kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations
kubectl get apiservices
kubectl get crds

Why These Extension Points Remain Formally Distinct

Each of these extension points, authentication, authorization, admission, scheduling, API surface, cloud integration, credentials, audit, is registered, invoked, and scoped independently because each corresponds to a genuinely distinct stage of control plane processing; consolidating them into a single, general-purpose extension mechanism would require every extension author to understand and filter for concerns irrelevant to their specific use case, rather than plugging into precisely the narrow point in the pipeline their extension actually needs to influence.