Wednesday, October 28, 2026
HomeCloud ComputingCisco Cloud Native Safety - Half 4: Safety Analytics and Risk Detection

Cisco Cloud Native Safety – Half 4: Safety Analytics and Risk Detection

[ad_1]

On this weblog submit we are going to talk about how one can add visibility, risk detection, safety analytics, and alerting inside your Kubernetes cluster utilizing Cisco Safe Cloud Analytics (previously often known as Stealthwatch Cloud). That is the fourth weblog submit in a sequence. In case you’ve gotten missed the primary three elements, you’ll be able to test them out right here:

On the backside of this weblog submit, now we have a demo video that walks via the whole lot mentioned on this weblog submit. As at all times, take a look at the DevNet Safety Dev Middle for different cool demo movies and use circumstances! Additionally, now we have a devoted web page for Safe Cloud Analytics, which you undoubtedly need to checkout…

Let’s stroll via the steps that we are going to take on this part

Keep in mind, we even have a video walkthrough on the backside of this web page. First, we are going to deploy a cloud native utility named Yelb, which is a 3 tier demo app with a Redis caching service. Yelb permits customers to vote on a set of options (eating places) and dynamically updates pie charts primarily based on variety of votes obtained.  Subsequent, we are going to use the Kubernetes CLI (kubectl) to validate the cluster is up and operating with an energetic employee node. Then we are going to use kubectl to deploy the cloud native Yelb app to the cluster. As soon as the app is up and operating, we are going to deploy Cisco Safe Cloud Analytics into the Kubernetes cluster utilizing Terraform. Lastly, we are going to generate site visitors to our utility utilizing Locust, which is an open supply, simple to make use of, scriptable and scalable efficiency testing device. Additionally, we are going to use netshoot, which is a  used for debugging which we are going to use to run Nmap scans (assume insider risk).

Constructing apps could or is probably not your factor however having demo apps accessible on the push of a button is at all times good to have. Within the subsequent weblog submit, we are going to undergo constructing our personal apps and APIs simply so we are able to expose some vulnerabilities to safe, however for now we’re going to use the ability of automation and orchestration to deploy our apps instantaneously utilizing a Kubernetes Manifest file.

Earlier on this weblog submit sequence, we discovered how one can deploy our cloud sources utilizing Infrastructure as Code and GitOps. We deployed an AWS VPC, EKS Cluster, and two EC2 situations utilizing Terraform. One occasion is internet hosting the Cisco Safe Firewall and the opposite occasion internet hosting the EKS employee node. We then used Ansible to configure the Cisco Safe Firewall entry management insurance policies. We verified that the whole lot was deployed appropriately by going to the AWS Dashboard and Firepower Machine Supervisor.

Earlier than we get into the step-by-step clarification of how one can do all the above, let’s elaborate a bit extra on what Cisco Safe Cloud Analytics brings to the desk. Safe Cloud Analytics supplies complete visibility and high-precision alerts with low noise, with out using brokers. Organizations may also monitor their cloud safety posture to make sure configuration greatest practices and adherence to inside insurance policies, thereby limiting potential threat and publicity of their cloud infrastructure. Safe Cloud Analytics is a cloud-based, Software program-as-a-Service (SaaS)-delivered answer. It detects ransomware and different malware, knowledge exfiltration, community vulnerabilities, system, occasion and configuration threat, and function modifications that point out compromise.

As at all times, you’ve gotten a alternative now… You may watch the demo video, or learn via the detailed directions beneath. (You may also do each!)

Detailed Directions

If you’re studying this, it means you have an interest to be taught the small print of this arrange. Let’s bounce proper in! First, let’s be sure that the Kubernetes cluster is prepared through the use of CLI instruments such because the AWS CLI and KUBECTL. Keep in mind the Terraform output from Jenkins, we are going to use the outputs to entry our EKS atmosphere.

Security part 4_1

First, we have to set our Kubernetes context by operating aws eks –area us-east-2 update-kubeconfig –title <cluster-name>:

Security part 4_2

This can replace the .kube/config context on the native host so we are able to entry the EKS cluster. On this instance the title of the cluster is SPOT_ON_Prod and the area is US-EAST-2.

Subsequent, let’s take a look at if now we have any employee nodes energetic by doing a kubectl get nodes.

Security part 4_3

We see that one of many EC2 situations is assigned to EKS cluster as a employee node and the standing is exhibiting Prepared.

Nice! We will deploy our Yelb app very simply now by operating kubectl create –f <file.yaml>. The YAML file we can be utilizing to deploy our app is yelb_app.yaml, which will be discovered HERE.

Security part 4_4

Properly, that was tremendous simple and quick. Let’s take a look at what was simply created. Now we have a namespace which is a container for the app, there are 4 pods operating our containers, and 4 providers that entrance finish the pods. Discover the yelb-ui service, which is TYPE = NodePort. This means that service port for this pod can be uncovered on the EKS employee node. The container runs on port 80, however it’s mapped to port 30001 on the employee node. This implies our app can be accessible to the web on port 30001. Usually our apps run behind a community or utility load balancer, however since that is only a demo utilizing one employee node, the node port will work fantastic for now.

Security part 4_5

We will entry the applying utilizing the prod_eks_public_ip from the Terraform output and port 30001, for instance, http://3.128.152.65:30001.

Security part 4_6

The applying is now up and operating and we are able to entry it from the web. Within the earlier weblog we deployed a Cisco Safe Firewall to the sting of the VPC, which supplies us entry management, intrusion prevention, and anti-malware safety for site visitors coming out and in of the VPC. That is little question crucial to have, however what about site visitors inside the EKS cluster? How will we get visibility, analytics, and alerting into the micro-service atmosphere?

Cisco Safe Cloud Analytics (SCA) detects early indicators of compromise throughout the cluster, together with insider risk exercise and malware. SCA consumes telemetry and logs to seek out irregular conduct or indicators of malicious exercise and triggers alerts so you’ll be able to examine shortly.

We deploy SCA into the Kubernetes cluster utilizing a DaemonSet. A DaemonSet ensures that every one (or some) employee nodes run a replica of a pod. As employee nodes are added to the cluster, pods are added to them. As employee nodes are faraway from the cluster, these pods are rubbish collected. We can be deploying our SCA DaemonSet utilizing Terraform inside our Jenkins pipleline.

First, we have to get the service key from the Cisco Safe Cloud Analytics portal. From the dashboard, go to Setting > Sensors.

Security part 4_7

Scroll all the way down to the underside of the web page and duplicate/save the Service key.

Security part 4_8

Let’s return to our code. First, we add new department referred to as secure_cloud_analytics to our repository.

Security part 4_9

We add a brand new module referred to as secure_cloud_analytics. Within the most important.tf file we set the required suppliers wanted for the module.

Security part 4_10

We additionally create a variables.tf file that may reference the Cisco Safe Cloud Analytics Service Key. We are going to go this safe variable from Jenkins.

Security part 4_11

Then now we have the secure_cloud_analytics.tf file which can create the Kubernetes Secret, Service Account, Cluster Function Binding and the SCA DaemonSet.

Security part 4_12

Try the complete file HERE.

Within the root module most important.tf file we add the Safe Cloud Analytics module configuration.

Security part 4_13

Lastly, we add the SCA Service Key to our Jenkinsfile atmosphere variables.

Security part 4_14

Then go the variable to the Terraform Apply within the Jenkinsfile construct stage.

Security part 4_15

Now it’s time to commit our modifications to the secure_cloud_analytics department and create a pull request to the principle department.

Security part 4_16

As soon as the merge has been accomplished it should set off a construct job in Jenkins.

Security part 4_17

If we have a look at the Terraform apply, we see that the SCA sources have been created.

Security part 4_18

Utilizing kubectl, we are able to see the SCA pods and daemonset operating in our Kubernetes Cluster.

Security part 4_19

Return to the Cisco Safe Cloud Analytics portal and choose Settings > Sensor once more. There can be a sensor with the title of the AWS EC2 occasion of our employee node.

Security part 4_20

Now that now we have a micro-services app and Cisco Safe Cloud Analytics is put in and monitoring in our Kubernetes cluster, it’s time to generate some site visitors and present the worth and visibility that SCA supplies in a cloud native atmosphere.

First let’s generate some site visitors utilizing Locust. Locust is a straightforward to make use of, scriptable and scalable efficiency testing device. Within the repo there’s a listing named Locust with a python file named locustfile.py. Locust is written in Python and will be put in by operating pip3 set up locust. Directions will be discovered HERE.

Run Locust domestically out of your IDE or terminal. This program will run on port 8089 in your localhost.

Security part 4_21

Go to http://0.0.0.0:8089 and begin a brand new load check to the general public IP deal with and port of the Yelb App.

Security part 4_22

Go to the net interface of your Yelb app and ensure the votes are incrementing.

Security part 4_23

Here’s a diagram of the Yelb app. We see that the UI is operating on port 80 (mapped to port 30001 on the employee node), the app server on port 4567, the database on port 5432, and cache on port 6379.

Security part 4_24

Let’s have a look at what visibility SCA supplies. From the Cisco Safe Cloud Analytics dashboard let choose Examine > Session Visitors.

Security part 4_25

Within the Session Visitors filter add the ports of all of the Yelb micro-services (4567, 5432, and 6379) and choose Replace. We are going to see all of the site visitors circulate throughout the Yelb app.

Security part 4_26

If we dive slightly deeper into every IP deal with, we are going to see extra details about the Kubernetes Pod resembling pod hostname, previous IP addresses, roles, and the variety of inside and exterior connections.

Security part 4_27 Security part 4_28 Security part 4_29

If we choose the Connections Graph, it should map out the applying and its providers.

Security part 4_30

Now let’s generate some safety alerts. We’re going to use a device referred to as Netshoot to run some inside scans and attempt to transfer laterally throughout the cluster. From our Devbox we run kubectl run tmp-shell –rm -i –tty –picture nicolaka/netshoot — /bin/bash. This can spin up a pod named tmp-shell within the default namespace of the cluster and drop us into an interactive shell. Netshoot comes full of a bunch of troubleshooting instruments, however we’re going to use the NMAP device to generate some irregular conduct.

Security part 4_31

First, we do some recognizance by operating a port scan contained in the cluster (nmap 10.0.1.0/24 -sT). This generates an Inner Port Scanner Alert in Safe Cloud Analytics.

Within the SCA portal, if we go to Monitor > Alerts, we see the alert reveals an outline, subsequent steps, and what MITRE ways and strategies are getting used.

Security part 4_32

There are over 120 alerts enabled out of the field, and you’ll create your individual customized watchlists.

Security part 4_33

For instance, should you go to Settings > Alerts/Watchlists > Inner Connections Watchlist, now we have created a watchlist that may alert us anytime an SSH connection is made to any host contained in the cluster.

Security part 4_34

If we run one other Nmap from the Netshoot pod to SSH to all hosts on the cluster community (nmap 10.0.1.0/24 -p22), we are going to get an Inner Connection Watchlist alert.

Security part 4_35

Security part 4_36

This concludes the detailed directions! Please let me know if in case you have any questions within the feedback part beneath, or through the GitHub points. Within the subsequent episode of this sequence, we are going to talk about Cloud Workload Safety Platform (CWPP) and the way we deploy and use CWPP in our cloud native atmosphere.  Hope to see you then!


We’d love to listen to what you assume. Ask a query or depart a remark beneath.
And keep related with Cisco DevNet on social!

LinkedIn | Twitter @CiscoDevNet | Fb |  Developer Video Channel

 

Share:



[ad_2]

RELATED ARTICLES

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Most Popular

Recent Comments