Support Center > Search Results > SecureKnowledge Details
Troubleshoot the onboarding of Kubernetes clusters to CloudGuard Dome9 Technical Level
Solution

Troubleshooting

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 Dome9 (https://api-cpx.dome9.com

Check these entities for possible configuration issues that prevent connectivity to the agent:  Proxy, Network Policy, Security Groups, and FW 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 Dome9 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 (Dome9, 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

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 cloudguard-container-info-collect.sh shell script here.

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

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