Cloud Native Computing Foundation Kubernetes Community Days (KCD) Chennai 2022, 30 Jul 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Kubernetes Security and Governance made easy using Otomi by Abhimanyu Selvan & Jehoszafat Zimnowoda

Description

Otomi is an open-source, cloud-agnostic, Kubernetes application configuration and automation platform. Under the hood, Otomi leverages several OSS and CNCF projects like Calico, OPA Gatekeeper, Istio, Harbor to enhance security. Security is an ever-growing concern for organizations. Gartner predicts that 99% of all security incidents by 2025 will be due to misconfigurations. This talk will demonstrate, how teams can use Otomi to manage container and network security policies with sane defaults on Kubernetes through an intuitive web interface, thereby avoiding the need to write any YAML configurations that are prone to errors. A recorded video/demo is used to showcase a couple of use-cases using the integrated security best practices in Otomi to reduce the attack surface when running applications on Kubernetes.

A

The next session is going to be kubernetes. Security and governance made easy using utomi, and uh this is being hosted by um um two of our friends here: abhimanyo and zafad zim novoda, so I'll give a brief introduction about every monument aviva salvan is the developer advocate at redcubes he's a software generalist who has worked in industries such as aerospace, robotics, e-health and has landed in the cloud native realm.

A

His focus lies in the intersection of maximizing developer productivity and enhancing business values, he's an open source enthusiast and is currently leading the developer experience program of the autonomy core project outside of work he enjoys enduring.

B

Endurance running.

A

And cycling uh thanks everyone you to be part of this program thanks a lot yehozawa novada is an engineering manager at red cubes. He aims to empower devops teams by listening to them and providing the autonomous environment that they need. He specially specialized in building software, for different engineering teams, from system platforms for telecom equipment to pass on top of kubernetes.

A

He has a strong computer network background which helps him design interconnected and distributed systems currently he's a maintainer of the atomic core project, great team player, who loves working with others after working hours. You can find him hiking in the mountains or biking on the road cool. That's a great introduction! Isn't it okay about this session?

A

Yeah thanks thanks! uh Yes, thanks to like uh for being with us and um about this session, autome is an open source cloud. Diagnostic kubernetes application, configuration and automation platform under the hood automatically leverages several oss and cncf projects like calico opa, gatekeeper, istio harbor, to enhance security security is an ever growing concern for organizations.

A

Gartner predicts that 99 of all security incidents by 2025 will be due to misconfigurations. This talk will demonstrate how teams can use auto me to manage container and network security policies with same defaults on kubernetes through an intuitive web interface, thereby avoiding the need to write any amol configurations that are prone to errors. A recorded video demo is used to showcase a couple of use cases using the integrated security best practices in automate to reduce the attack surfacing surface when running applications on kubernetes.

A

Cool, so um the session will start in a couple of minutes and thanks after then abby when you for being around- and um we are all excited to go through this session yeah it can. It will go there in a couple of minutes thanks.

C

On kubernetes, security and governance made easy using autome. This talk will demonstrate how teams can use autome or open source project to enforce container and network security policies with same defaults on the cluster through an intuitive web interface, thereby avoiding the need to write yaml configurations that are prone to errors. We will also see how leveraging automation and git ops can mitigate the misconfiguration errors.

C

Hi, I'm abhimanyu selvan. You can call me abhi, I'm the developer advocate at redcubes, I'm a software generalist exploring the cloud native realm and my interest lies in improving the developer, experience and productivity.

B

Hi, my name is jim novada and you can call me yejo. I am the engineering manager at red cubes and, together with my colleagues, we are maintaining the autumny core project.

C

Here is the agenda for the talk, we'll give you a general introduction about our open source project automay and then go hands-on demo demonstrating container security policies, egress control, using istio network policies and then key takeaways from this talk. Finally, how you all can contribute to our open source project and community.

B

Otomy is a self-hosted platform as a service for kubernetes that aims to lower the burden on operation and make developers self-serving. It is an open source project. It can be installed on any kubernetes cluster automate integrates more than 20 open source projects and brings multi-tenant experience. So each devops team has its own self-sufficient environment to work with.

C

We can enforce container security policies and network policies in autome without having the need to write any ml configurations. Everything through a single intuitive web user interface automay can be easily installed using health chart. But for the sake of this demo, we'll only focus on the security and the network policy enforcement aspect of autonomy. Welcome to the demo on container security policies.

C

This demo will demonstrate how easy it is to gain access to the host file system by deploying a rogue pod, and we will also showcase how simple it is as a platform admin to prevent such an attack from happening by enabling the security policies via the automate console without the need to write any ammo configurations.

C

So, let's go ahead and deploy this robot part that has privileged container running with host volume mounted and the whole security flag set. True.

C

And note that I can easily gain access to the host file system and the possibilities to create havoc is endless. We can easily prevent something like this from happening by enabling the bot security policies from the automate console. Let's check it out so now we'll be logged into the autome console as a team admin.

A

We will now enable.

C

The settings for the team kcd chennai, what you see.

A

In the bottom is.

C

The list of core applications that automate comes pre-configured with by default and the applications on top can be easily enabled by dragging and dropping them in.

A

C

Case we want to enable the policies, so let's go ahead and enable opa gatekeeper to enforce these policies and, let's see what happens now see that gatekeeper is part of the enabled apps. We need to deploy these changes, but before we do so, let's enable some settings of gatekeeper via the console.

C

The automate console provides high level abstraction of these spot security policies that can be.

A

Easily enabled.

C

From the console.

C

Autonomy comes pre-configured with projects such as kitty and drone.

A

C

Enable automation, when you fill the form and click deploy changes automay automatically generates the configuration as code commits the changes to a pre-configured automatic values, git repository, which triggers a drone.

A

C

That will validate the changes and apply the changes to the cluster automatically.

C

But let's head back to the terminal.

A

C

If we are able to deploy the rockport, we can see that the admission controller has denied the request to create the pod with the non-compliant configuration. This confirms.

A

C

Fact that the pod security policies have taken effect.

B

Has just shown the importance of having container security policies which can limit a vast majority of attacks. The next level of enhancing security is by controlling the network traffic, which may play a key role in highly distributed and interconnected environments like ports in kubernetes cluster.

B

In this demo, I will talk about controlling network traffic from a pod to the internet network. A very common attack is so-called remote command execution, which allows an adversary to run an arbitrary shell command. It often results in leveraging a curl command, fetching malicious software and executing it in memory. Since package manager is available, the attacker installs the occur binary, which mimics downloading a malicious software to the pot. Then http request is performed to the endpoint outside the cluster.

B

Let's head back to the automa console and prevent any traffic going outside the cluster, I'm going to update the theme settings of kcd chennai and enable egress control feature.

B

We are back to the terminal as a result of enabling egress policy in automi console the default. Estio sitecar resource has been deployed by autome.

B

I try again downloading an application from the internet.

B

It's not possible anymore, because istio blocks traffic going outside this service mesh.

B

We are going to inspect the side car configuration, so there is a default sidecar configuration deployed for a team, kcd 10i automation, forces, external egress control by a setting, outbound traffic policy to registry. Only for this particular team, which means that the pod cannot access any endpoint outside the service mesh.

C

Yahoo just talked about controlling the external egress traffic, but what about the interpod communication? For the sake of this demo, we will deploy a guestbook application that consists of three micro services, the front end, the redis leader and the redis follower in the team case, cd chennai namespace.

C

We will also deploy a snooper pod that will be able to communicate with the redis service. This demo will be split into three parts, as shown in the figure. First, we will allow all the traffic to flow through, so the services will be talking to one another. The snooper pod will also be able to ping the redis leader. Then we will log into the automay console and enable the network policies which, by default, will deny all the incoming traffic. And finally, we selectively allow the traffic to flow through the microservices by whitelisting.

C

The applications on the autome console.

B

In the terminal, we deploy gas application, which consists of three kubernetes services.

B

In the atomic console, we have already exposed the front-end service with the public url that we are going to access now. This is the guestbook application and we will leave few entries by submitting them. The front-end connects with ready service where the data is stored.

B

Let's get back to the terminal, I'm going to deploy a snooper pod, which sends a ping message to the redis leader service communication is allowed because no network policy is enforced, as you can see in the terminal on the bottom right corner.

B

We move to the second scenario where the default network policy blocks all incoming traffic to the port in the team namespace. I just visit automatic console and enable the network policy feature by editing team, kcd, chennai settings.

B

After enabling network policies, the front-end service is not able to communicate with the redis service anymore. We head back to the terminal where we inspect kubernetes resources that otome has deployed. For us. There are two network policies: the first one blocks all incoming traffic to any pod in the team, kcd chennai namespace.

B

The second one allows control plane, traffic from core services like prometheus, istio or k native.

B

One more time I deploy the snooper pot and check if it can communicate with the redis leader service.

B

The deny all network policy prevents snooper bot communication, but I need to allow incoming traffic from the front end to the ready service in anatomy, console I'm going to register two more services, so I can enable network policies for their reports.

B

Next, we define the network policies also for the redis follower. Again we want that the front-end service is able to communicate with the redis follower.

B

We are back at the guestbook application now, it's possible to add more entries. The communication has been restored.

B

Let's check network policies that otome has created after registering new services, there are two new resources that target ready spots and selectively allow incoming drive. With this, we have concluded demo about network policies.

C

Kubernetes is complex: implementing security across dynamic environments of organization takes a toll on the engineers enabling a security driven mindset to build secure applications is paramount. In today's world, as open source enthusiasts and contributors, we have built autome by honoring several open source projects and integrating them into one platform. Autome was built ground up from a developer's point of view where we have abstracted away the complexity of implementing security across the platform by providing high-level security principles that are easily consumable.

C

This approach not only enables organizations to build fast, secure environments, but also enables team and engineers within the organization to develop a secure mindset from the inception of the application building process.

C

The most important part of this talk is the open source community, as mentioned earlier, autumny is 100 open source, so feel free to check out our repository redcube automecore and do give us a star if you enjoy it. We also have quick start repositories to help you quickly install autome on your favorite cloud provider. We can also run autome on mini cube.

C

We also have some workshops repository where you can try out different labs and experience. The true potential of autome for docs you can visit autome.io and to join the community or slack channel. You can visit redcubes.com community and subscribe to our events and slack channel from there. We look forward to hearing back from you all. Thank you very much.