Support Center > Search Results > SecureKnowledge Details
Troubleshoot the onboarding of Kubernetes clusters to CloudGuard Technical Level
Solution
Use these troubleshooting hints to resolve problems in deploying the agent.


Check that the pod was created

kubectl -n [namespace] get pods

If the pod was not created correctly (e.g. it exists but is not ready), get pod details:

kubectl describe -n [namespace] pod [pod_name]


Check the Kubernetes logs

Use this command to get the logs:

kubectl -n [namespace] logs [pod_name]

Check if there are any errors in the logs.


Check the connectivity from the pod 

The pod must have HTTPS (port 443) connectivity to CloudGuard (https://api-cpx.dome9.com

Check these entities for possible configuration issues that prevent connectivity to the agent:  Proxy, Network Policy, Security Groups, and Firewall rules.

You can install another pod that has curl (such as an Ubuntu pod for example) in the same namespace, with the same labels, exec into it and check connectivity to CloudGuard using curl.

curl -k https://api-cpx.dome9.com/podsecuritypolicies -X POST

If there is connectivity with the agent, the response will be {"message":"Unauthorized"}.


Connectivity to Image Registry

The node needs HTTPS (port 443) connectivity to the Quay registry. If you see an image pull error,  check the connectivity to https://quay.io/checkpoint/.


Kubernetes behind a gateway

If your cluster is located behind a gateway performing HTTPS inspection, try to create a bypass rule for https://api-cpx.dome9.com and https://quay.io/checkpoint/*, and retest. If the bypass rule resolves the issue, it indicates that the CA certificate  to pods of the flow-logs daemonset should be mounted. The path should be /ca_custom/custom_ca.cer , where the custom_ca.cer file contains the Base64-encoded CA certificate.

Also, if there is a gateway, add a firewall or SG rule to allow access from the agent to the two URLs above (CloudGuard and Quay). Docker may also have to be configured with the proxy to allow image downloads from Quay.

If your cluster is behind a proxy you can use the '--proxy' flag when you install the solution using Helm.

helm install my-release checkpoint/cp-resource-management --set-string credentials.user=[CloudGuard API Key] --set-string credentials.secret=[CloudGuard API Secret] --set-string clusterID=[Cluster ID] --set-string proxy=$HTTPS_PROXY --namespace=[Namespace] --create-namespace

$HTTPS_PROXY is the Linux Environmental variable, it is possible to use Proxy URL directly.
For example: --set-string proxy=https://my-proxy.com:8080


In case of onboarding misconfiguration

Each cluster should be onboarded using its own Cluster ID. If you have encountered a cluster status message or an event log indicating that more than one Kubernetes cluster was onboarded using the same environment ID, you may resolve the issue by offboarding clusters which share the same ID, so that only one remains onboarded.

First, offboard superfluous clusters. you can offboard a cluster by running the following command:
helm uninstall asset-mgmt --namespace <namespace>

Once superfluous clusters are offboarded, use the following API to indicate that the issue had been resolved:
POST https://api.dome9.com/v2/kubernetes/account/resolveMultipleOnboarding/{Cluster ID}


Enable debugging

Edit the deployment, and set the debug level:

kubectl -n [namespace] set env deployment [deployment] LOG_LEVEL=debug

Then, recheck the logs.


How to collect CloudGuard container release info for further troubleshooting?

Download the cloudguard-container-info-collect.sh shell script.

Script pre-requisites:
  1. User should have kubectl and helm installed on the machine where this script is running and kubeconfig context set to the relevant cluster.

  2. User should have proper permissions to execute helm and kubectl commands for the relevant cluster.

  3. Following common Linux commands should be available: rm, tar, mkdir.

Default assumptions: helm release name is asset-mgmt and solution installed in Check Point NameSpace.

Usage example 1:
Release name: asset-mgmt, namespace: checkpoint, the script will collect CloudGuard CRD’s
./cloudguard-container-info-collect.sh

Usage example 2:
Custom release name and namespace, the script will not collect CloudGuard CRD’s ant will save debug archive with custom name.

./cloudguard-container-info-collect.sh -r cp-asset -n cp -c no -o cp-debug.tar.gz

Detailed syntax:

 ./cloudguard-container-info-collect.sh [-r|n|c|o|d|h]"

Options:
-r/--release <Helm release name>
-n/--namespace <Namespace>
-c/--crd <yes/no>
                Specifies if collect CloudGuard CRD's. Default value: yes.
-o <file_name> Specifies custom name for output tarball file
-d/--debug Enables debug
-m/--metrics Default: disabled
                Specifies if collect Cloudguard agents containers metrics. If metrics collection is enabled, 'kubectl exec' will run on fluentbit containers.
-h/--help Display a brief usage message and then exit.
This solution has been verified for the specific scenario, described by the combination of Product, Version and Symptoms. It may not work in other scenarios.

Give us Feedback
Please rate this document
[1=Worst,5=Best]
Comment