An admission controller is a piece of code inside the Kubernetes API server that looks at a request after it has been authorized and before the object is saved.

The Short Definition

Kubernetes keeps all of its state, such as Pods, Services, Deployments, and Secrets, in a database called etcd. The only front door to that database is the API server. Whenever you run a command, apply a manifest, or a tool like a CI pipeline talks to your cluster, the request arrives at the API server. An admission controller is a plugin in that front door which gets a chance to inspect, modify, or reject the request before it is written to etcd.

Two words matter here: “inspect” and “modify”. Some admission controllers only look and then say yes or no. Others actually change the object, for example by filling in a missing default value. Both kinds exist, and we will separate them clearly in a later chapter.

Why Do We Need It?

Authentication answers “who are you?” and authorization answers “are you allowed to do this kind of action?” Neither one looks deeply at the thing you are asking for. Authorization might say “Maya can create Pods in the payments namespace,” but it cannot say “Maya may create Pods only if they do not run as the root user and only if they pull images from our company registry.” Rules about the content of an object need a different layer, and admission control is that layer.

Without it, every team would need to remember every rule by heart, and one forgotten setting could expose the whole cluster. With it, the rules live in one central place and are applied to everyone automatically, whether the request comes from a human, a script, or another controller.

What It Does Not Do

It is just as important to know the limits. Admission controllers do not run on read requests, so they cannot hide or filter what people see. They also do not watch objects that already exist in the cluster; they only see requests as those requests arrive. If you create a bad object before a rule exists, the rule will not remove it later. It will only react the next time someone tries to update that object. Keep this in mind, because it explains many surprises in real clusters.

The “connect” operation deserves a short note. It covers actions like opening a shell inside a running container or forwarding a port. These are not changes to stored objects, but they are sensitive, so admission can still examine them.

To understand admission, it helps to follow a single request from the moment it leaves your laptop until it is stored.

The Journey of One Request

Suppose you ask Kubernetes to create a Deployment. Your request is sent over a secure connection to the API server. From that moment it passes through a fixed series of stages, always in the same order. The diagram below shows the full path.

flowchart LR
    A["Client request"] --> B["Authentication"]
    B --> C["Authorization"]
    C --> D["Mutating admission"]
    D --> E["Schema validation"]
    E --> F["Validating admission"]
    F --> G["Saved to etcd"]
    B -. "rejected" .-> X["Error returned"]
    C -. "rejected" .-> X
    D -. "rejected" .-> X
    E -. "rejected" .-> X
    F -. "rejected" .-> X
        

Why the Order Matters

The order is not an accident. Changing the object comes before the final validation so that the validators judge the object that will actually be stored, not an early draft. If validation came first, a mutating step could silently break a rule that had just been checked. By putting every mutation before every validation, Kubernetes gives validators the last word.

Another consequence is that rejection is final and early. If any admission step says no, the request fails immediately and the user receives an error message explaining why. Nothing is stored, and no later stage runs.

Admission controllers come in two roles, and understanding the difference is the single most useful idea in this whole topic.

Mutating Controllers

A mutating controller is allowed to modify the incoming object. Typical jobs include adding a default storage class to a volume claim, setting a default service account on a Pod, attaching standard labels, or injecting an extra container next to your application container. Mutation is about convenience and consistency: the user does not have to remember each detail because the cluster fills it in.

Because one mutation can affect the next, mutating controllers run one after another in a defined order. Each one sees the result of the previous one.

Validating Controllers

A validating controller can only say yes or no. It receives the final version of the object and decides whether it follows the rules. Since it cannot change anything, there is no risk of one validator interfering with another, so validating controllers can be evaluated independently of each other, and the request is accepted only if every single one approves.

Some Plugins Do Both

Several built-in plugins are both mutating and validating. They simply take part in both phases: first they may adjust the object, and later they check it. The Kubernetes documentation marks which plugins act in which phase, so it is worth checking when you rely on a particular one.

Kubernetes ships with a long list of admission plugins that are compiled directly into the API server. Many are switched on by default, and you probably rely on several of them without knowing.

How They Are Switched On and Off

The API server has settings that enable additional plugins and disable default ones. A cluster administrator who controls the control plane can tune these. Be aware that on most managed Kubernetes services, the provider decides the plugin list, and you may not be allowed to change it. This is one reason the webhook and policy approaches in later chapters are so popular: they work on any cluster without touching the API server settings.

A Tour of Important Plugins

The list below is not complete, but it covers the plugins most engineers meet in daily work. Each card explains what the plugin is for in plain words.

Two Plugins That Open the Door to Extension

Among the built-in plugins, three are special because they let you add your own logic without rebuilding the API server. They are the mutating webhook plugin, the validating webhook plugin, and the validating admission policy plugin. They act like sockets: the built-in code is fixed, but what plugs into it is yours to define. Chapters 5 through 9 are about these.

Built-in plugins cover common needs, but every company has its own rules. Admission webhooks let you run those rules in a separate service of your own.

What Is a Webhook?

A webhook is simply a web address that gets called when something happens. In this case, “something happens” means a matching request has reached the admission stage. The API server pauses the request, sends a description of it to your service over a secure connection, waits for your answer, and then continues or stops depending on what you say.

Your service can be anything that speaks the right format: a small program you wrote, a full policy engine, or a vendor product. It usually runs inside the cluster as an ordinary Deployment with a Service in front of it, though it can also live outside the cluster at a public address.

sequenceDiagram
    participant U as User
    participant A as API Server
    participant M as Mutating Webhook
    participant V as Validating Webhook
    participant E as etcd
    U->>A: Create Pod request
    A->>M: Admission review with the object
    M-->>A: Allowed, plus a list of changes
    A->>A: Apply changes and check schema
    A->>V: Admission review with final object
    V-->>A: Allowed or denied with a reason
    A->>E: Store the object
    A-->>U: Success response
        

Registering a Webhook

You do not tell the API server about your service in a command-line flag. Instead, you create a Kubernetes object that describes it. There are two such objects: one for mutating webhooks and one for validating webhooks. Each object lists which requests to send (by resource type, operation, and optionally namespace or labels), where to send them, and how to behave if something goes wrong. We study those settings in Chapter 7.

Security of the Conversation

The API server only talks to webhooks over encrypted connections. Your service needs a valid certificate, and the registration object carries the certificate authority that the API server should trust when it connects. If that certificate expires or the trust information goes stale, the API server can no longer reach your service. Depending on settings, the result is either blocked requests or skipped checks, and both are painful. Many teams automate certificate renewal for exactly this reason.

Webhooks and the API server talk using a small, well-defined message called an AdmissionReview. Knowing what is inside it makes debugging far easier.

The Question the API Server Asks

When the API server calls your webhook, it sends one message called an AdmissionReview. Inside the request part of this message you will find a set of useful facts. Think of it as a form that the API server fills in before handing it to your service.

The Answer Your Webhook Gives

Your service replies with a response that repeats the unique ID and states whether the request is allowed. A denial can include a status with a human-readable message and a code, and that message is shown to the user, so write it clearly. A good denial says which rule was broken and how to fix it, not just “forbidden.”

A mutating webhook can also return a list of changes, written in a standard format called JSON Patch. It is a precise recipe, such as “add this label” or “replace that value,” which the API server applies to the object. A response may also carry warnings: short messages shown to the user even though the request succeeded. Warnings are a gentle way to announce that a rule will soon become strict. There are also audit annotations, small notes added to the audit log entry for the request, which help security teams trace decisions later.

Versions of the Message

The message format is versioned, and the registration object lists which versions your service understands. The API server picks one that both sides support. Always support the current stable version, because older formats are removed in newer clusters.

A webhook is only as safe as its registration. A handful of settings decide whether your cluster stays healthy when something goes wrong.

Choosing What Gets Sent

Not every request needs to reach your webhook. Sending everything wastes time and increases risk. The registration lets you narrow things down in several ways. Rules pick the API groups, resource types, and operations. A namespace selector includes or excludes whole namespaces by their labels. An object selector filters by the labels on the object itself. Newer clusters also support match conditions, small expressions written in CEL, a safe expression language we meet in the next chapter, which let the API server skip the call entirely when a condition is not met. Filtering before the network call is the cheapest optimization available.

Failure Policy: The Most Important Choice

What should happen if your webhook is down, slow, or broken? The failure policy answers that question, and it has two options.

There is no universal answer. A webhook that blocks privileged containers should usually fail closed, because skipping it would defeat its purpose. A webhook that adds optional labels can usually fail open. What matters is that you make the choice on purpose, write it down, and test what really happens when the service disappears.

Timeouts, Side Effects, and Re-invocation

Running a separate service just to say “no” to a few bad configurations is a lot of machinery. Kubernetes now lets you write such rules as plain objects, evaluated inside the API server itself.

The Problem with Webhooks

Webhooks are powerful, but they come with costs. You must build and maintain a service, keep certificates fresh, make it highly available, and accept the extra network hop on every matching request. For simple rules, this is like hiring a security company to check whether a form has a signature.

What CEL Is

CEL, short for Common Expression Language, is a small, safe language for writing conditions. It cannot loop forever, cannot access files, and cannot call the network. Because it is so limited, the API server can run it directly with predictable cost. A CEL rule looks at the incoming object and returns true or false. For example, a rule can express “every container must have a memory limit” or “replica count must not exceed ten.”

The Two Objects

The feature uses two cooperating objects. The first is the policy, which describes which resources it applies to, optional variables, and one or more validation rules with their messages. The second is the binding, which connects a policy to a scope, such as particular namespaces, and decides what happens on a violation. Splitting the two means one policy can be reused with different scopes and different strictness.

Parameters Make Policies Reusable

A policy can point to a separate parameter object, for example a small configuration holding the maximum allowed replica count. Different bindings can supply different parameter objects, so the same rule can be strict in production and relaxed in development without copying the policy.

The same idea that replaced simple validating webhooks is being extended to mutation, so common defaults can also be declared without running your own service.

The Idea

A mutating admission policy follows the same model as its validating cousin. You describe the resources it applies to and express the change you want using CEL, and the API server applies it. Typical examples include adding a default label, setting a safe default value, or adding a standard annotation. As there is no webhook service, there is no network call, no certificate, and no outage risk from a missing service.

When Webhooks Are Still the Better Tool

Policies are intentionally limited. If your mutation needs complex logic, needs to generate a lot of content such as a full sidecar definition based on external templates, or needs to talk to another system, a webhook remains the right answer. Think of policies as the everyday tool and webhooks as the specialist tool.

Writing and maintaining raw webhooks for every rule does not scale. Policy engines package the webhook, the certificates, and a friendly rule language into a ready-made product.

What a Policy Engine Does

A policy engine is a program you install in the cluster that registers its own admission webhooks. You then write rules in the engine’s own format, and the engine decides how each incoming request should be handled. It also usually adds extras: reports on existing objects that already violate a rule, tools to test policies before release, and exception handling for teams that need a rare bypass.

How to Choose

If your team wants to stay inside Kubernetes-style configuration and values quick adoption, an engine built around Kubernetes resources is attractive. If your organization already uses the same policy language for other systems such as pipelines or cloud access, a general-purpose engine gives you one language everywhere. Many engines also support the native policy objects from the previous chapters, so the choice is not as final as it once was.

One built-in admission plugin deserves its own chapter because almost every cluster uses it: the one that stops dangerous Pods.

From PodSecurityPolicy to Pod Security Admission

Older clusters used an object called PodSecurityPolicy to control risky Pod settings. It was confusing to use and was removed in Kubernetes 1.25. Its replacement is Pod Security Admission, a built-in plugin that enforces a set of published rules called the Pod Security Standards. It is much simpler: you choose a level for each namespace by adding labels to that namespace.

Three Levels

Three Modes

For each namespace you can choose how a violation is handled, and you can use more than one mode at the same time. Enforce rejects violating Pods. Audit allows them but records the violation in the audit log. Warn allows them but shows a warning to the user. A very effective migration plan is to enforce at baseline while auditing and warning at restricted, so teams see what they must fix before the stricter level is switched on.

So far we have treated admission as one box. Now we open the box and see how the individual plugins are lined up, who calls whom, and why a single user action can trigger several rounds of admission.

A Chain of Small Decisions

Inside the API server, admission is not one big program. It is a chain of small plugins, and each plugin is asked about the request in turn. The built-in plugins are compiled into the server and run first or alongside the extension points. The webhook plugin is itself just another link in the chain: when its turn comes, it looks at all the registered webhooks, filters out the ones that do not match the request, and calls the rest.

The order of the built-in plugins is fixed by the server, and you should not try to depend on it. Likewise, when several mutating webhooks match the same request, you should not write one webhook that silently relies on another having run first. If two mutations really depend on each other, merge them into one component. Code that works only because of an accidental order tends to break during upgrades, when ordering details change.

One Action, Many Requests

A very common surprise is that one human action produces several API requests, and each of them goes through admission separately. When you create a Deployment, the Deployment controller creates a ReplicaSet, and the ReplicaSet controller creates Pods. These controllers are programs inside the cluster, and they talk to the API server just like you do. That means your Deployment is checked once, the ReplicaSet is checked again, and each Pod is checked a third time.

This is why the rule coverage matters so much. A rule that blocks bad Pods will fire even if the bad settings were hidden inside a Deployment template, but the error will appear in the ReplicaSet events rather than in your command output. The Deployment itself may look healthy, with the Pods simply never appearing. Knowing the chain makes this behavior easy to diagnose.

flowchart TD
    U["User creates a Deployment"] --> A1["Admission check 1: Deployment"]
    A1 --> D["Deployment controller"]
    D --> A2["Admission check 2: ReplicaSet"]
    A2 --> R["ReplicaSet controller"]
    R --> A3["Admission check 3: Pod"]
    A3 --> P["Pod stored and scheduled"]
    A3 -. "rejected" .-> E["Event on the ReplicaSet"]
        

What Each Plugin Sees

Each plugin receives a structured description of the request: who is calling, which resource, what operation, and the object itself. Plugins do not see the network connection, the command the user typed, or the tool used. A request from a command-line tool, a pipeline, or a controller looks the same except for the caller identity. This is a feature, not a limitation, because rules apply equally to every path into the cluster.

Creating a new object is the easy case. Most real-world surprises come from the other operations, and from the parts of an object that have their own separate address.

Subresources

Many objects have subresources, which are special sub-addresses for particular actions. A Pod has a status subresource used by node agents to report health, an ephemeral containers subresource used for debugging, and connection subresources used for opening a shell or forwarding a port. A Deployment has a scale subresource that autoscalers use to change the replica count. An eviction subresource is used when draining nodes.

Why does this matter for admission? Because a rule written for a Pod does not automatically cover its subresources. The registration must name the subresource explicitly, or it will not be consulted. If you want to stop engineers from opening shells inside production containers, you must write a rule about the connection subresource, not about the Pod itself. A surprisingly large number of security gaps come from rules that forgot the subresources.

Updates Need Two Versions

An update request carries both the new object and the old one. This is powerful, because a rule can compare them. A rule can say “the storage size may grow but never shrink,” or “the owner label may never change after creation.” Without the old object you could only judge the new state, which cannot express the idea of a forbidden change.

There is a trap, though. Controllers constantly update objects to record their own progress: a status here, a counter there. If your rule is too strict about updates, you can accidentally block the cluster’s own housekeeping. Rules that apply to updates should be as narrow as possible, and they should usually ignore changes that only touch the status subresource.

Deletes Are Admission Events Too

Admission also sees delete requests. Teams use this to build a safety net: for example, a rule that refuses to delete a namespace unless it carries a label saying deletion is approved. Remember that the old object is available for deletes, so the rule can examine what is about to be removed.

An untested admission rule is a risk to the whole cluster. Fortunately, Kubernetes gives you several ways to rehearse a rule before it matters.

Server-side Dry Run

Most clients can send a request in dry-run mode. The API server then does everything it would normally do, including authentication, authorization, every admission step, and validation, but it stops before saving anything. The response tells you what would have happened. This makes dry run the best everyday tool for testing a rule: apply a sample object in dry-run mode and see whether it is accepted, changed, or rejected.

Because dry-run requests pass through webhooks, remember that your webhook must honor the dry-run flag. A webhook that sends an email or writes to an external database on every request would do so even for a rehearsal, which defeats the purpose. That is why the side effects declaration exists.

A Practical Test Plan

Admission controllers sit in one of the most powerful positions in the cluster, which makes them both a strong defense and an attractive target.

The Webhook Is a Powerful Citizen

A mutating webhook can change any object that matches its rules. If an attacker takes control of your webhook service, they can quietly rewrite workloads, for example by changing the image a Pod runs or adding a malicious container. A validating webhook under attacker control could approve anything. That is why the service must be treated as part of the control plane in terms of care, even though it is just a Deployment.

Policies Can Be Bypassed If You Are Not Careful

A rule is only as strong as its coverage. If a rule checks Pods but not Deployments, a user could try to sidestep it by creating the higher-level object in a way that produces a bad Pod later. If a rule is excluded for certain namespaces, anyone who can create objects in those namespaces can ignore it. Review exclusions regularly and keep them as short as possible.

Also remember that admission controllers only see requests, not existing state. A new rule does not fix old objects. Combine admission with periodic scanning, which most policy engines offer, to find existing violations.

Because admission sits in the middle of every matching write, a slow or broken webhook slows or breaks the entire cluster.

Latency Adds Up

Each webhook call happens while a user waits. If three webhooks each take half a second, every matching request becomes one and a half seconds slower. Worse, controllers inside the cluster also write objects constantly, so a slow webhook can create a backlog that affects scaling, rollouts, and recovery. Keep webhook logic small, avoid calling other services during a decision when possible, and cache anything you must look up.

Availability Practices

You cannot manage what you cannot see. Admission control gives you several windows into what is happening.

Metrics from the API Server

The API server publishes metrics that describe admission activity. They include the time spent in each admission step, the time spent calling each webhook, counts of rejected requests, and counts of requests that were let through because a webhook failed while set to fail open. Collect these in your monitoring system and chart them. A sudden rise in webhook duration or in rejections is often the first sign of trouble.

Audit Logs and Annotations

The cluster audit log records requests, and admission decisions can add annotations to those entries. When a policy audits a violation, or a webhook returns audit annotations, the note appears next to the request. This gives security teams a searchable trail of who tried to do what, and which rule reacted.

Logging Inside the Webhook

Your own service should log each decision with the request ID, the resource, the user, and the outcome, while avoiding the logging of sensitive data from Secrets or tokens. When a developer says “my deployment was rejected,” a log search by request ID should answer within a minute.

flowchart TD
    R["Incoming request"] --> A["API server admission step"]
    A --> M["Metrics: duration and rejections"]
    A --> L["Audit log with annotations"]
    A --> W["Webhook service logs"]
    M --> D["Dashboards and alerts"]
    L --> S["Security review"]
    W --> T["Troubleshooting"]
        

Teams that use admission control for years tend to converge on the same good habits, and to repeat the same mistakes.

Patterns Worth Copying

A condensed checklist of what works, and of the traps that catch even experienced teams.

A Safe Rollout Plan for a New Rule

Admission control is not a theory topic. Several tools you may already use depend on it every day.

When something is rejected or the cluster feels stuck, a calm, step-by-step approach finds the cause quickly.

When a Request Is Rejected

Start with the error message itself. Webhook denials include the name of the webhook and the message it returned. Native policy denials name the policy and the failed rule. If the message is vague, check the policy engine’s logs and the audit log for the request.

When Everything Seems Blocked

If many unrelated requests are failing with errors that mention a webhook call failing, the webhook service is probably unreachable. Check whether its Pods are running, whether its Service has healthy endpoints, and whether its certificate is still valid. Remember that a webhook set to fail closed will block every matching request while it is down.

Admission control is one guardrail among several. Understanding what the others do keeps you from asking admission to solve problems that belong elsewhere.

Each Layer Has Its Own Job

A healthy platform layers its defenses. RBAC answers who may perform which action. Network policies decide which Pods may talk to which other Pods. Admission control checks the content of objects as they enter. Scanning in the delivery pipeline catches problems before a change even reaches the cluster. Runtime security tools watch what containers actually do after they start. No single layer can replace the others, and removing one leaves a gap that the rest cannot fill.

Validation Rules in Custom Resources

Kubernetes also lets authors of custom resource types embed validation rules, written in CEL, directly in the type definition. These rules travel with the type, so every cluster that installs it gets the same checks. They are the right place for rules that describe what a valid object of that type means, such as “the maximum must not be smaller than the minimum.” Admission policies, in contrast, are the right place for rules that describe your organization’s preferences, which can differ between clusters.

Let us put everything together with a story. A platform team runs one cluster used by several product teams and wants safe defaults without slowing anyone down.

The Situation

The platform team supports about a dozen application teams. Incidents keep repeating: a Pod without memory limits crashes a node, an image from an unknown registry is deployed, and nobody knows who owns a mysterious workload. The team decides to use admission control to address the three problems, without becoming a bottleneck.

What They Did Right

Admission rules are not a one-time project. Clusters, tools, and certificates all change, and rules must keep up.

Cluster Upgrades

Kubernetes releases new versions several times per year. Each release can promote features from experimental to stable, deprecate old interfaces, and eventually remove them. Admission is touched by these changes in several ways. A policy feature may become available only after you upgrade. The message format used by webhooks may gain a new stable version while an old one is removed. A built-in plugin may change its default behavior. Reading release notes with admission in mind should be a standard step of every upgrade.

Keeping Rules Healthy

Rules grow stale. Teams change, tools are retired, and exceptions pile up. A rule created for a long-forgotten incident can keep blocking a legitimate new workflow. Assign an owner to every rule and webhook, record why it exists, and review the list on a schedule. Retire rules that no longer protect against a real risk, because every extra rule adds latency, confusion, and potential failure.

Every check has a price. Planning for that price early prevents slow clusters and surprising outages later.

Where the Time Goes

Built-in plugins and native policies run inside the API server and are usually very cheap. Webhooks add a network round trip, the time your service needs to think, and the cost of encrypting the connection. If many matching requests arrive at once, such as during a large rollout or when a node fails and hundreds of Pods are recreated, the webhook sees a burst of traffic that is far higher than its normal level.

Sizing a Webhook Service

With so many options, a simple decision path helps teams pick a tool without a long debate.

flowchart TD
    S["New rule needed"] --> Q1{"Does a built-in plugin already do this?"}
    Q1 -- "Yes" --> B["Enable and configure the built-in plugin"]
    Q1 -- "No" --> Q2{"Does the rule need only the object itself?"}
    Q2 -- "Yes" --> Q3{"Validate or change?"}
    Q3 -- "Validate" --> V["Native validating policy with CEL"]
    Q3 -- "Change" --> M["Mutating policy if available, otherwise webhook"]
    Q2 -- "No" --> Q4{"Is it one of many rules needing exceptions and reports?"}
    Q4 -- "Yes" --> P["Policy engine"]
    Q4 -- "No" --> W["Custom webhook with care"]
        

Reading the Chart in Words

First ask whether Kubernetes already does what you want. Quotas, default limits, default storage classes, and Pod security levels are built in, and using them costs almost nothing. If nothing built in fits, ask whether the rule depends only on the object. If it does, a native CEL policy is the simplest and most reliable choice. Only when you need outside information, complex generated content, or a whole family of managed rules with exceptions and reporting do you move to policy engines or custom webhooks.

A Few Final Checks Before You Ship

No. They apply to create, update, delete, and connect operations only. Reading data is controlled by authorization, not admission.

Authorization decides whether you may perform a kind of action on a kind of resource. Admission examines the specific object in the request and can change it or reject it based on its contents.

No. Admission only sees incoming requests. Existing objects are untouched until someone updates them. Use scanning or reporting features to find existing violations.

Usually not. Cloud providers control the API server settings. This is why webhooks and native policies, which need no API server changes, are so widely used.

Fail closed for controls that protect security or compliance, and fail open for optional conveniences. Whatever you choose, run multiple replicas and test what happens during an outage.

Yes. All mutation completes first, so validation judges the final object that would be stored.

Choose a CEL policy when the rule needs only the object itself, and choose a webhook when you must consult outside data or need complex logic that CEL cannot express.

The Deployment was accepted, but the Pods it tried to create were rejected, often by Pod Security Admission or a policy. Check the events and the status of the related ReplicaSet to see the denial message.

Yes, if it is set to fail closed and its own namespace is not excluded. Always exclude the webhook’s namespace and the system namespaces from its scope.

Yes. That is why webhooks must declare whether they have side effects, and why they must avoid those effects when a request is marked as a dry run.

Yes. Every matching validating rule is consulted, and the request is accepted only if all of them approve. The user may see one or several denial messages, so each message should stand alone and explain its own rule clearly.

Yes. Controllers talk to the API server like any other client, so the ReplicaSets and Pods they create are checked separately from the Deployment you submitted. Rules must therefore tolerate normal controller behavior, including routine status updates.

Nothing. Running Pods keep running exactly as they are. The rule applies the next time something creates or updates a matching object, which is why scanning and reports are needed to find older violations.

Shell access uses a connection subresource of the Pod. A rule written only for the Pod itself does not cover it, so the registration must name the subresource explicitly.

It is the safe default for rules that could block critical components, but exclusions should be kept short and reviewed. Anyone who can create objects in an excluded namespace can bypass the rule there, so control access to those namespaces tightly.

Switch it from deny to warn or audit mode, or remove its binding or registration. Because rules are objects stored in version control, rollback is usually a quick, reviewed change. Keep that procedure documented before you need it.

Usually not. A few well-owned components, native policies, and a shared policy engine are easier to secure, monitor, and keep available than many separate webhooks. Offer teams a simple way to request or propose rules instead.

State which rule was broken, explain in one sentence why the rule exists, and tell the person exactly what to change. A message that names the field, the allowed values, and a link to internal guidance saves a support conversation every time.

A small platform or security team should own the shared rules and the tooling, while application teams propose changes through the normal review process. Clear ownership means someone always answers when a rule blocks a deployment or a certificate is about to expire.

Admission controllers are the cluster’s last checkpoint before an object is stored. They run after authentication and authorization, first changing requests where allowed, then validating the final result. Built-in plugins handle common needs such as defaults, quotas, and Pod security. Webhooks extend the system with your own logic, while CEL-based policies and policy engines make common rules simpler and safer to run. Used thoughtfully, with clear messages, careful failure settings, and good monitoring, admission control turns your cluster rules from a document people forget into behavior the platform guarantees.