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 detects a breach but it stops the unwanted action.

Before you can use Admission Control, your KubernetesClosed 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 to retrieve 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 of 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:

Admission Control Default Policy Configuration

ContainerClosed A lightweight and portable executable image that contains software and all of its dependencies. Containers decouple applications from underlying host infrastructure to make deployment easier in different cloud or OS environments, and for easier scaling. 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.

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 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.

Image Admission

With the Image Assurance policy, CloudGuard makes an assessment of a scanned image compliance. While Image Assurance can only detect vulnerabilities in the image, Image Admission can prevent the image deployment in a cluster. The image is allowed if it was scanned in one (minimum) of the related environments (ShiftLeftClosed The ShiftLeft tool scans source code, containers and serverless functions, looking for vulnerabilities including those associated with the Log4j tool. This tool alerts the security and DevOps teams if any vulnerabilities are detected in the pre-build phase, ensuring that vulnerable code is not deployed. or Container RegistryClosed A collection of repositories used to store and access container images.) and found compliant.

For Image Admission, only images scanned in a ShiftLeft or Container Registry environment are considered.

Note - Image Admission is available to customers through the Check Point Early Availability Program. If you want to participate and test the feature, contact the EAP team at ea_support@checkpoint.com.

Image Assurance Policy

The Image Assurance policy can have these two actions, disabled by default:

  • Image Admission Action of Detection or Prevention to enforce non-compliant images based on the scan results.

  • Image Admission UnScanned Action of Detection or Prevention to enforce not scanned images.

To receive the correct results of the image scanning, you must use for the Kubernetes environment the same ruleset that was used for the applicable ShiftLeft or Container Registry environment.

Note - Image Enforcement is done based on the image name. If the image is scanned on a ShiftLeft environment, make sure that the image is correctly tagged before the scan.

You can create the Image Assurance policy with an API call:

POST /v2/kubernetes/imageAssurance/policy

Use these properties:

  • Image Admission Action - admissionControllerAction

  • Image Admission UnScanned Action - admissionControlUnScannedAction

For more information, see the API reference guide.

Enforcement

When your container creates a new workload, all workload images are checked if they are compliant or scanned, based on the selected action. When it updates the workload, CloudGuard checks only changed or added images if they are compliant or scanned (for each selected action).

Prevention

When you enable a Prevention policy, the Image Admission Enforcer agent blocks the deployment of workloads with non-compliant or not scanned images. The Kubernetes user receives this error message in their CLI:

Error from server: error when creating "deployment.yaml": admission webhook "cloudguard-enforcer-webhook.cloudguard.checkpoint.com" denied the request: [CloudGuard] The request has been blocked because the image 'myregistry.domain.com/my-ubuntu:v1' has not passed compliance check.

Exclusions

Use exclusions to allow registries, specific images, usernames, roles, or namespaces. For more information, see Exclusions.

In exclusions, use "%" as a wildcard.

More Links:

Kubernetes Containers

Image Assurance

Exclusions

Kubernetes documentation: