Admission Control

CloudGuard Admission Control monitors your clusters and enforces a security baseline across a namespace or cluster. It can detect if your clusters do not comply with standard practices like having good labels, annotations, resource limits, or other settings. If you configure the Admission Control in the Prevention mode, not only does it detect a breach, but it stops the unwanted action.

CloudGuard Workload Protection - Kubernetes Admission Control

Before you can use Admission Control, your Kubernetes Kubernetes, often abbreviated as “K8s”, orchestrates containerized applications to run on a cluster of hosts. cluster must be onboarded to CloudGuard. See Onboarding Kubernetes Clusters.

How it Works

When you make a change in an existing workload, Kubernetes must update the workload configuration in etcd. The API request to the Kubernetes API server goes through the admission stages as in the diagram below before it is recorded (persisted) in etcd. CloudGuard's Admission Control utilizes the validating admission webhook to enforce your policies created in the CloudGuard portal or through the CloudGuard API.

When you enable Admission Control, CloudGuard installs or upgrades Kubernetes agents with these resources:

• Policy Agent - One replica Deployment responsible for retrieving configuration and policies (configured by the user) from the CloudGuard backend.

• Enforcer Agent - A Deployment with a replica count of two that establishes the admission webhook receives the API calls and validates them based on the enforced policy.

• Custom Resource Definitions (CRD) - Kubernetes custom resources (CR) that contain Detection and Prevention rules for each supported object type. The Policy Agent has permission to change the CRs. The Policy and Enforcer Agents have permissions to read the CRs.

  Access to the CRDs (together with read permissions like get and list) must be restricted as they contain information on the cluster hardening.

Kubernetes deploys and registers the Enforcer Agent as the Admission Control validation webhook on the supported resources.

The Enforcer Agent does this:

1. Stops every create, update, delete, or connect operation triggered on the supported resources by the API calls to the API server.

2. Validates these changes against the Admission Control rules.

If an API call violates the rule, CloudGuard sends an alert (go to Events (Posture Findings and Security Events) and filter by Source > Kubernetes Admission Control) based on the notification in the policy. Based on your selection of the mode, CloudGuard:

• Blocks the operation for policies in the Prevention Mode.

• Allows the operation of policies in the Detection Mode.

Admission Control blocks or detects violations on API calls only; it does not delete or block running workloads.

Note - Admission Control monitors (blocks or detects) all operations initiated by users. It ignores system components operated by the Kubernetes control plane.

Alert Recurrence

CloudGuard Admission Control issues only one alert for each unique incident.

An issue is unique when it meets all these conditions:

• All occurrences violate the same rule, in the same ruleset and policy.

• The same entity (Username or Service Account) relates to all occurrences.

• The target is the same in all occurrences, that is, it has the same entity or the same root owner of the entity, for example, the same deployment for different pods.

Alerts Severity

• Determined by the severity configured on the use case or rule.

• When the Kubernetes server-side dry-run option calls the API, Admission Control stops this event as all other events. If the applicable event is a Kubernetes dry-run, the severity level of the alert is Informational.

Kubernetes Definitions

Some Kubernetes resources have an owner resourced:

• Owner resource - The parent resource that created a resource.

• Root Owner resource - The first resource that led to the creation of a resource.

For example:

• A pod The smallest and simplest Kubernetes object. A pod represents a set of running containers on your cluster. A pod is typically set up to run a single primary container. It can also run optional sidecar containers that add supplementary features like logging. Pods are commonly managed by a Deployment. can be created directly or indirectly by a ReplicaSet; in the latter case, the ReplicaSet is the owner of the pod.

• A resource can have a chain of owner resources, for example, a deployment can create a ReplicaSet which can create pods.

Admission Control Default Policy Configuration

Container Admission Control is a CloudGuard-Managed ruleset that contains the best practice rules for Kubernetes Admission Control. You can find this ruleset if you navigate to Workload Protection > Admission Control Rulesets and filter on the CloudGuard-Managed Type.

The default Admission Control policy uses this ruleset. CloudGuard attaches the default detection mode policy to all new and existing clusters, where you enable Admission Control. The default Admission Control ruleset constantly undergoes updates.

When you onboard a new cluster to CloudGuard (or enable the Admission Control feature) and associate it with an Organizational Unit, the cluster obtains the Admission Control policy configured for this Organizational Unit. If no such policy exists, a new policy is created to associate the new cluster with the default ruleset.

Best Practice - For Prevention policies, clone the default ruleset and use it in your policy.

To provide the security solution, it is sometimes necessary to give CloudGuard agents elevated permissions that must be restricted for most workloads. To address this requirement, the default policy has preconfigured exclusions to streamline the CloudGuard solution.

Configuring Admission Control in CloudGuard

Follow these steps to configure a GSL policy on the cluster:

1. Create an Admission Control Ruleset.

2. Add rules to the Ruleset.

3. Create an Admission Control Policy that binds the Ruleset to the cluster.

For more, see Getting Started with Admission Control Policy.

Exclusions

Admission Control exclusions are almost the same as the regular CloudGuard exclusions, see Exclusions.

Enter these fields when you create a new Admission Control exclusion.

More Links

• Kubernetes Containers

• Image Assurance

• Exclusions

• Kubernetes documentation:

  • Guide to Kubernetes Admission Controllers

  • Using Admission Controllers