Are your applications secure? Can you find it out without complex rules?

The modernization of infrastructure and applications is driving the rapid growth of containers, and as companies scale the adoption of Kubernetes, it’s critical to incorporate security and compliance.

The challenge? Compliance and security is a journey, not a state in time, and application security in Kubernetes has a large surface area.

This challenge increases exponentially as you run more applications, onboard more developers, add more environments, add new pipelines, and more.

Most solutions are focused on the Kubernetes infrastructure and will require you to write complex rules to handle the scenario above. This approach imposes challenges because:

• As mentioned above, security and compliance requirements will keep evolving and changing as you scale your environment.
• It creates dependency and bottlenecks as teams will need to rely on members who can write and maintain these rules, rather than enabling members from the security team to quickly make changes and see how these reflect on their running applications.
• Upgrading clusters can affect the rules your write.
• Its time consuming to write, maintain and evolve those.

The steps below will help you set up policy frameworks that you can connect to your clusters and, in just a few minutes, see how your applications comply or violate the policy frameworks you define.

Architecture

Here is what we have:

• Two clusters across different providers. I have used Google GKE and Oracle OKE, but you can use whatever provider you want or self-hosted clusters.
• A Magento application is installed on each cluster.
  • It doesn’t matter if you used Helm, Kustomize, Argo, TF, or whatever way to install these apps. As long as the application is running, this will work.
• A Shipa Cloud account (sign up here)

Getting Started

Shipa uses the concept of Frameworks to define the policies, connect to your cluster, and discover the applications. 

Frameworks are dynamic, so once you create one and connect to your cluster, you can change framework policies, and Shipa will automatically reflect the changes.
Click on Frameworks and then Create to get started:

To start with a simple scenario, choose the Discover existing applications options and click on Next

Here you can enter:

• The Framework name. While I will use this to separate between Magento in Production and Development, you can use it to isolate application information from different clusters, environments, projects, teams, or others.
• The resource limit plan you want to use and compare with what’s currently configured in your applications. You can create different plans here.
• The Kubernetes namespace where the Magento application is deployed. This should match the namespace’s name in the cluster we will connect this framework to shortly.
• The team you want to give access to the application and security information discovered by Shipa. You can create additional teams and invite users here.

Click on Next

For Shipa to discover the applications within the namespace defined in the previous step, you need to enter a label used when the application was deployed. You can find a label by using the command below:

kubectl describe pod podname -n namespace-name

Since I will have two Magento applications, I’m adding the suffix here, so I can easily distinguish the applications later.

Click on Create

Head over to Clusters to connect the framework you just created to the first cluster. Click on Create

The framework you created should be pre-selected. Although I am connecting a single framework to the cluster, you can create multiple frameworks and connect them to the same cluster simultaneously. Each framework will connect to a different namespace.

Enter your cluster API address and click on Generate Command.

Shipa will generate a kubectl command that you can run from your terminal. Before running it, ensure you set your context to the correct cluster.

Once you run it, Shipa will install its agent in your cluster, connect to the namespace defined in the framework, discover the applications, and start sending data back to your Shipa dashboard. This process should take only a couple of minutes.

Once Shipa starts discovering the applications, you can see them available on the Applications page:

Here you can immediately see 2 things:

• The complete application information discovered by Shipa
• A policy report with violations is found based on your framework’s minimum definition.

If I repeat the process above and connect my Oracle OKE cluster, I will now see centralized information of my development and production environments.

Fine Tuning Policies

Now that you have information about both applications centralized on Shipa, you can fine-tune the framework policies so Shipa can return the violations based on the desired state of your policies or compliance requirements.

Click on Frameworks and choose the Update option for one of your frameworks. I’m choosing the production one:

This will open a module with the different policy controls you can adjust:

Let’s make some quick adjustments and see how Shipa flags those new violations.

Click on the Registry Control step. Here you can limit the registries that should be used by applications deployed using the magento-prod namespace:

Let’s now define Ingress and Egress. By clicking on the Ingress and Egress Configuration steps, I can set both to deny-all. This will say that my production Magento application should not receive and send data:

The last example we can set up is the security scan. Click on the Security Scans step and uncheck the Disable app scans box.

For example, I’m entering 3 components that should be considered exceptions. Anything other than those found by Shipa should be highlighted as a vulnerability:

Click on Update & Close

Shipa will now update our production application’s framework policies and policy violations in a few seconds.

Heading over to the Applications page will show us the updated violations:

You can expand on each of those violations and get additional details:

As you have seen, framework policies are dynamic, and you can keep adjusting each framework over time to ensure it reflects the most up-to-date policy or compliance rules your teams need to enforce.

Insight and Alerts

While the Applications page will give the application owner details about their applications, if you have an Ops or security profile, you want to see centralized information about all discovered applications from all clusters and namespaces.

You can find this by clicking on the Insights option:

Insights will give you a broad overview of everything across your clusters, how teams use it, metrics about application images, response time, and more.

Focusing strictly on the security aspect, by clicking on the See All for Policy Violations, you will see centralized violation information across all applications:

I also guess that you, or your security team, won’t spend the whole time looking at this screen and refreshing it for new violations. You can take advantage of the capability of setting up alerts.

By clicking on Manage Alerts, you can choose the framework you want to set alerts for and set what level of alerts you want to monitor and to which provider you want to send that information, such as Slack, Teams, PagerDuty, or others:

Conclusion

In just a few minutes, you discovered and centralized application information and defined a scalable policy and compliance model that different teams across your organization can use and evolve—all without writing complex code or rules and keeping it dynamic.