Admission Control

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or

Already have an account? Sign In »

Time
1 hour 13 minutes
Difficulty
Beginner
CEU/CPE
1
Video Transcription
00:00
>> But what about the API calls to the Kubernetes cluster?
00:00
Understandably, some calls may either be
00:00
malicious in nature
00:00
>> or come from an unauthorized source.
00:00
>> Cloud guards admission controller stops
00:00
malicious or inadequate requests to
00:00
the Kubernetes API server
00:00
>> before they become persistent.
00:00
>> Based on the controllers decision,
00:00
the request can be immediately
00:00
rejected and an error is returned to the end user.
00:00
The Cloud guard admission controller
00:00
utilizes a Kubernetes validating
00:00
admission web hook to enforce the policies
00:00
created by the users in the Cloud guard native portal,
00:00
or via Cloud guard APIs.
00:00
The admission controller consists of
00:00
the following resources, the policy agent,
00:00
which is responsible for retrieving configuration and
00:00
policies configured by the user
00:00
from the Cloud guard backend.
00:00
The enforcer agent, which
00:00
establishes the admission web hook,
00:00
receives the API calls,
00:00
and validates them based on the enforced policy.
00:00
Finally, the CRDs,
00:00
which consists in this case of
00:00
detection and prevention rules for each
00:00
supported Kubernetes object type such as
00:00
pods, jobs, roles, etc.
00:00
Access to these CRDs,
00:00
including read permissions such as Get and List should be
00:00
restricted as they contain
00:00
information on the cluster security.
00:00
Once deployed, the flow looks like this.
00:00
The policy agent retrieves
00:00
user-defined admission criteria based on
00:00
configurations and policies from
00:00
the Cloud guard backend
00:00
>> and updates the CRDs accordingly.
00:00
>> Once any API requests to
00:00
the Kubernetes Cluster API server comes in,
00:00
it is intercepted by the enforcer agent.
00:00
With the enforcer agent evaluates the API call,
00:00
making sure it is not
00:00
malicious based on the CRD definitions.
00:00
Depending on the settings,
00:00
if the call is malicious,
00:00
it can either be just detected and
00:00
reported or detected and blocked.
00:00
For instance, only DevOps has permission to
00:00
connect via SSH to a pod protected by cloud guard.
00:00
The API call will be permitted to pass
00:00
by the enforcer agent to the API server.
00:00
API calls from all other sources in this case,
00:00
will be dropped before the API call is completed.
00:00
Unlike the previously discussed components
00:00
for admission controller to function,
00:00
it requires proactively adding a policy rule set.
00:00
Later on when we get to this part of the deployment,
00:00
we'll look at how we can add such a rule set.
Up Next