Onboarding Kubernetes Clusters

1. In the CloudGuard portal, open Assets > Environments.

2. For first-time onboarding, click Kubernetes. The first window of the wizard to onboard a Kubernetes cluster opens.

   Or, from the top menu, select Add > Kubernetes / OpenShift / Tanzu.

3. Enter a name for the cluster. This is the name that appears in CloudGuard.

4. Follow the on-screen instructions to complete these steps:

   • Configure a Service Account by one of these methods:

     • Select an existing Service Account with its corresponding API Key.

     • Enter a Service Account manually.

     • Click Add Service Account to create a new account.

   • Enter a name for the Kubernetes namespace in which the agent is to be deployed or keep the default name - checkpoint.

   • Select what type of monitoring and security checks are necessary for your Kubernetes cluster by default. You can add each of these features later. Read more about each feature on a dedicated page:

     • Posture Management - for details, see Cloud Security Posture Management (CSPM) (mandatory feature)

     • Image Assurance - for details, see Image Assurance

     • Admission Control - for details, see Admission Control

     • Runtime Protection - for details, see Kubernetes Runtime Protection

     • Threat Intelligence - for details, see Intelligence for Kubernetes Containers

5. Click Next to continue to the next step.

1. Select the Organizational Units with which the onboarded cluster will be associated. If no Org Unit is selected, the root (top-level) unit is used.

2. Click Next.

1. Follow the on-screen instructions and apply Helm A Kubernetes deployment tool for automating creation, packaging, configuration, and deployment of applications and services to Kubernetes clusters.. As an alternative, you can follow the Non-Helm instructions to deploy the agents. This generates a YAML file for deployment with kubectl commands.

   For more installation options, see Installing the Agent.

2. Click Next.

1. Verify the deployment status. The status is dynamically updated as the agents come online.

CloudGuard informs you that:

• Your Kubernetes cluster has been successfully created.

• It is waiting for the agent to start communication.

• You can skip the validation if you click the Finish button.

2. Wait for the deployment completion based on the Cluster and Agent Status or click Finish to skip the process.

After the agent is deployed, CloudGuard accesses the cluster through the agent to get information about the assets and synchronize with it. This takes several minutes based on the time needed to download the images to the cluster and the number of assets in the cluster.

The Onboarding Summary page is updated automatically with the change of the cluster status.

Cluster Status

Available options of the cluster status:

• Pending - CloudGuard has not received communication from the agents.

• Initializing - CloudGuard is receiving communication from some of the agents. The progress bar shows how many agents are up and ready.

  Note - During this state, if the number of running pods does not change for 10 minutes, the indicator pauses and the status changes to TIME OUT. In this case, verify the agents status on the cluster to make sure they do not have issues. For example, agents can be stuck because of missing resources (memory or CPU). After you resolve the issue, you can continue the validation or skip the validation process entirely.

• Error - There are agents in the Error state. Click Finish to complete the process. You can go to the cluster page to see which agents have the Error state and browse their Kubernetes logs for issues.

When all the agents are running, the cluster status changes to SUCCESS, and the onboarding process finishes successfully.

Agent Status

On the cluster page, for each feature, you can see the status of its agents:

• Pending - The agent has never communicated with CloudGuard.

  Note - There is a limitation for DaemonSet agents. During the cluster status calculation, tolerations settings are not considered. Agents from excluded nodes are considered Pending which can cause a false error state for the cluster.

• Initializing - Status of an agent that comes online and initiates communication with the CloudGuard portal. The agent has a small period to report a successful self-test. If the agent does not report it back on time, the status is changed to Error because of a timeout.

• Warning - Status of an agent that successfully finished its initialization, while it is based on an old image. See Upgrading the Agent for how to resolve this issue.

• Error – Status of agents that

  • failed their self-test

  • sent an error message

  • suffered a loss of connectivity for a minimum of one hour

  • have the version below the minimal version

• Pending cleanup - Disabled features that still have an agent that sends data to appear with the Pending cleanup status.

This values file with clusterId and credentials (userId, secretKey) enables the imageScan and flowLogs features on the cluster and requests a custom configuration of compute resources for the daemon.

## Check Point CloudGuard  cluster ID
## Example: "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
clusterID: clusterId

## CloudGuard datacenter: usea1 [default], euwe1, apso1 etc.
datacenter: usea1

## Check Point CloudGuard Credentials
## Example
## API Secret: "abcdefghijklmnopqrstvuwxyz"
## API ID: "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
credentials:
  secret: secretKey
  user: userId
  
addons:
  imageScan:
    enabled: true
  flowLogs:
    enabled: true
    daemon:
      resources:
        requests:
          cpu: 200m
          memory: 60Mi
        limits:
          cpu: 400m
          memory: 200Mi
  admissionControl:
    enabled: false
  runtimeProtection:
    enabled: false 

Run this command:

This values file enables the flowLogs feature and sets two different configurations for daemons based on the values of the nodeSizeKey custom label on the nodes.

addons:
  flowLogs:
    enabled: true
    daemonConfigurationOverrides:
      exampleConfigOneSmall:
        nodeSelector:
          nodeSizeKey: small
        resources:
          requests:
            cpu: 100m
            memory: 30Mi
          limits:
            cpu: 200m
            memory: 100Mi
      exampleConfigOneLarge:
        nodeSelector:
          nodeSizeKey: large
        resources:
          requests:
            cpu: 200m
            memory: 60Mi
          limits:
            cpu: 400m
            memory: 200Mi