Console is running in a Kubernetes cluster, and Defenders need to be deployed on nodes within this cluster.
How should the Defenders in Kubernetes be deployed using the default Console service name?
A.
From the deployment page in Console, choose "twistlock-console" for Console identifier, generate DaemonSet file, and apply DaemonSet to the twistlock namespace.
B.
From the deployment page, configure the cloud credential in Console and allow cloud discovery to auto-protect the Kubernetes nodes.
C.
From the deployment page in Console, choose "twistlock-console" for Console identifier and run the "curl | bash" script on the master Kubernetes node.
D.
From the deployment page in Console, choose "pod name" for Console identifier, generate DaemonSet file, and apply the DaemonSet to twistlock namespace.
In Kubernetes environments, deploying Defenders to protect nodes involves leveraging DaemonSets, which ensure that every node in the cluster runs a copy of a specific pod. When the Console is running within a Kubernetes cluster, it's essential to correctly reference the Console service to ensure seamless communication between Defenders and the Console. Option A is the most straightforward and Kubernetes-native method for deploying Defenders. By choosing "twistlock-console" as the Console identifier on the deployment page within the Console, users can generate a DaemonSet configuration file tailored for the Twistlock namespace. This approach ensures that the Defenders are correctly configured to communicate with the Console, providing comprehensive security coverage across the Kubernetes nodes. This method aligns with best practices for deploying security agents in Kubernetes and is supported by Prisma Cloud (formerly Twistlock) documentation, which provides step-by-step instructions for deploying Defenders using DaemonSets.
Contribute your Thoughts:
Chosen Answer:
This is a voting comment (?). You can switch to a simple comment. It is better to Upvote an existing comment if you don't have anything to add.
Submit