Deployment - Container Security

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
>> Now that we've covered the various components of
00:00
CloudGuard workload protection that
00:00
can be deployed to help protect containers,
00:00
let's roll up our sleeves and start deploying.
00:00
Deploying CloudGuard container security
00:00
is rather straightforward.
00:00
We will synchronize CloudGuard and
00:00
the Kubernetes cluster by deploying
00:00
a CloudGuard agent unto the cluster,
00:00
which reports information back to CloudGuard.
00:00
On top of that we will have to configure
00:00
the admission controller component from
00:00
scratch to create default access rules.
00:00
For the sake of this session,
00:00
we're assuming you already have a Kubernetes cluster
00:00
set up as this is out of this program's scope.
00:00
To begin, we log into
00:00
the Infinity Portal and
00:00
navigate to the Assets section under CloudGuard.
00:00
Here, we need to connect CloudGuard
00:00
and the Kubernetes cluster we wish to protect.
00:00
We start by adding a new
00:00
>> Kubernetes cluster environment.
00:00
>> If this is the first time we're adding an asset,
00:00
we'll get this Get Started screen.
00:00
Otherwise, we'll add
00:00
a new environment into the
00:00
>> existing list of environments.
00:00
>> We fill in a meaningful unique name which will be used
00:00
to identify the Kubernetes cluster within CloudGuard.
00:00
Next, we create a new service account,
00:00
which will generate the account API key ID and secret.
00:00
These will be used to identify the API calls from
00:00
CloudGuard's implanted agent in
00:00
the cluster, the CloudGuard.
00:00
It is important to keep a record of
00:00
these details for future reference.
00:00
Note that you can also use an existing service account.
00:00
In such a case, you'll be using
00:00
the API key ID and secret on record.
00:00
Next, we fill in the Kubernetes
00:00
namespace as defined in our target cluster.
00:00
We make sure to mark the desired features
00:00
we'd like to make available.
00:00
Now, we choose
00:00
the relevant organizational unit
00:00
to associate with a Cloud account.
00:00
Organizational units help us view and
00:00
maintain onboarded accounts
00:00
according to logical groupings,
00:00
such as business units or geographical regions.
00:00
Next, we open an SSH connection to
00:00
the designated Kubernetes cluster
00:00
and paste the Helm commands from
00:00
the instructions summary in the SSH connection.
00:00
These commands deploy the
00:00
CloudGuard agent within the cluster.
00:00
Once done executing, the status will be deployed.
00:00
Clicking the next button will verify that
00:00
both systems are synchronized.
00:00
This synchronization means
00:00
CloudGuard accesses the cluster
00:00
through the agent to obtain
00:00
>> information about the assets.
00:00
>> To finalize, we hit the "Finish" button.
00:00
This completes the deployment.
00:00
We now have our CloudGuard workload protection
00:00
deployed and synced with our Kubernetes cluster.
00:00
Let's look at what we have here.
00:00
Under Protected Assets,
00:00
we can view the onboarded accounts assets.
00:00
CloudGuard fetches information about these assets from
00:00
the onboarded Cloud platform
00:00
and presents it in a console view.
00:00
CloudGuard monitors the
00:00
>> security posture of these assets.
00:00
>> Drilling down into a workload asset,
00:00
we can view its protected processes,
00:00
define exclusions to
00:00
the default runtime protection rules and find
00:00
any special security findings
00:00
and events related to the asset.
00:00
Conversely, we can access
00:00
the protected components through workload protection.
00:00
Here, we can view and drill down into
00:00
all containers being protected across the board.
00:00
Under Image Assurance,
00:00
we can locate the images being protected,
00:00
view any detected vulnerabilities and
00:00
examine and modify the default policy and rules.
00:00
Here we can view and drill down
00:00
>> into all the pod groups
00:00
>> runtime protection is applied to across the board.
00:00
Under Admission Control,
00:00
we need to create a first-time rule set
00:00
as the deployment does not create a default policy.
00:00
This process consists of three steps.
00:00
Adding an admission control rule set,
00:00
adding rules to the rule set,
00:00
and adding an admission control policy
00:00
that binds the rule set to the cluster.
00:00
Let's add an admission control rule to
00:00
prevent services from being publicly exposed.
00:00
Naturally, your use cases can differ
00:00
depending on your architecture and business needs.
00:00
We start by adding a rule set and naming it.
00:00
Now, we add a new rule into it.
00:00
When we click inside the GSL box,
00:00
the GSL Editor opens up.
00:00
CloudGuard GSL, which stands
00:00
for Governance Specification Language,
00:00
is a simple yet expressive syntax to define rules
00:00
which can be included in rule sets
00:00
in the CloudGuard compliance engine.
00:00
The use case option covers
00:00
the most popular scenarios for
00:00
the admission control rule set creation.
00:00
In this case, we add this pre-built rule.
00:00
You can see the GSL syntax change
00:00
as we further configure the rule.
00:00
Finally, we verify the rule
00:00
against the relevant environment and save.
00:00
Now we need to bind the rule set
00:00
>> to the relevant cluster.
00:00
>> We head out to the policies in either associated
00:00
with an existing policy or with a new policy.
00:00
In our case, we'll create a new policy.
00:00
After defining which entities it applies to,
00:00
we need to choose one or two actions to take when
00:00
the rule or rules within the policy are violated.
00:00
Either detection with a policy
00:00
does not block events on the cluster,
00:00
but sends an alert notification
00:00
or prevention where the policy blocks an event that
00:00
violates it on the cluster
00:00
and sends an alert notification.
00:00
It's best practice to
00:00
first use detection with new policies.
00:00
If needed, you can configure multiple policies on
00:00
the same cluster with a different action configuration.
00:00
Finally, we define one or more notifications
00:00
to receive when the policy is violated.
Up Next