Скачать с ютуб Enforcing Container Policies with Admission Controller в хорошем качестве

Enforcing Container Policies with Admission Controller

CloudGuard Container Protection includes an Admission Controller Module, which provides users a way to enforce policies in their Kubernetes cluster. Define rules for Kubernetes Admission Control and effectively set security policies and guardrails for cluster operations. If you are not familiar with kubernetes admission controller, it is a piece of code that intercepts requests to the kubernetes API server before changes are applied to the cluster current status, but after the request is authenticated and authorized here we have an EKS kubernetes cluster with three nodes where we have already deployed CloudGuard agent. We create a namespace named checkpoint where our agent pods are located. These pods will validate and allow a request to reach the API server based on user-defined rules. The admission policy pod is the one in charge of communicating with CloudGuard backend to synchronize the rules and policies within the cluster. Let's configure our admission controller rules in CloudGuard: We log into the CloudGuard portal and verify that our cluster is already onboarded and the various modules are up and running. Click into the Workload Protection section and navigate to admission control rule sets. As you can see, some rule sets with best practices are already provided by Check Point, but you can also create your own rules. To add my own rule, I'll use the GSL Builder: this intuitive tool will auto present options to me as I build it out, making it fairly easy to build complex rules. The use case for my rule is to prevent the creation of pods that contain images which don't comply with certain version. In my production namespace, I have applied different tags to the same container image, only the 0.01 is compliant with the rule set and will be allowed by the admission controller; so let's apply this rule to my environment within the policies section: click on “add policy filter” in the environment from the list, then select the rule set you want to apply. You can apply more than one ruleset, as well as apply the same rule set to multiple environments, then select the admission controller behavior. We suggest starting first in Detection Mode, this will not block your requests to the kubernetes API server, but it will create alerts in CloudGuard portal whenever a rule violation is detected. Once you're confident with the rule sets and your environment compliance, you can select Prevention Mode to block those requests to kubernetes. That would change the cluster state in a way that is not compliant with your policies. Finally, let's configure notifications for violations in the policy: in this case, let's configure an email notification. The policy now is applied in the cluster thanks to the Admission Policy pod. Let's try to create the pod that is not compliant with the policy, this pod will have a container image with an associated tag that is not compliant with the rules that we define beforehand. Before the request reaches the kubernetes API server, CloudGuard admission controller blocks it and we can see the message that it reports the reason why our pod was not created. So let's change the container image and use a compliant tag. As you can see now, it creates the pod and no issues are reported back in the CloudGuard portal. You can filter the alerts to see those associated with the kubernetes admission controller and that will show when incidents occurred, what rules were broken, and in which environment with the CloudGuard admission controller you can define rules for kubernetes and mission control, giving the ability to effectively set security policies and guardrails for cluster operations. For more information on container security, visit https://www.checkpoint.com/cloudguard... What is cloud workload security? https://www.checkpoint.com/cyber-hub/... What is container security? https://www.checkpoint.com/cyber-hub/...