The DevOps Guide to Kuberenetes, Cloud-Native Apps, and Microservices Security

eBook:

Introduction

Cloud-native apps are becoming more popular thanks in part to orchestrators such as the market dominator, Kubernetes. But these applications, and Kubernetes itself, have some important security issues. This eBook provides a deeper understanding of the security challenges and solutions for them.

Index

Setting the Scene: Cloud-Native Apps, Containers, and Kubernetes 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A Closer Look at Microservices 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Challenges 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Microservices and DevOps: Better Together 5. . . . . . . . . . . . . . . . .

Kubernetes Security and DevOps 8. . . . . . . . . . . . . . . . . . . . . . . . . . .

The CI/CD Pipeline and Its Security Needs 10. . . . . . . . . . . . . . . . . . .

Cloud-Native Application Security and Why it Matters 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Portshi�: Securing your infrastructure from CI/CD to run time 11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Setting the Scene: Cloud-Native Apps, Containers, and Kubernetes

Cloud-native apps continue to rise in popularity as their accessibility for users and agility for so�ware developers become increasingly mainstream. Cloud-native apps are typically comprised of many microservices that are usually packaged in containers which are managed and deployed by orchestration so�ware. There are a number of orchestrators in the market but Kubernetes dominates the field due to its agility and scalability for continuous deployment and framework for managing applications both in the cloud and on-prem.

However, popularity and agility come at a cost of weaker security due to the multiple front and back doors le� unintentionally open to malicious threat actors. Kubernetes, containers and third-party applications pose significant security issues for DevOps and DevSecOps teams because they do not have security measures baked into the CI/CD pipeline. They can be compromised in the earliest stages of development due to their exposure and reliance on (additional) multiple 3rd party tools and platforms. What’s more, any change to an application or microservice is very likely to be propagated into future versions.

When a potential threat or vulnerability is detected in a running container, DevSecOps must be able to not only kill that container and replace it with a non-compromised version, but also integrate that information into the CI/CD pipeline to protect future build and deployment cycles.

1

Crypto mining gained attention thanks to the infamous Tesla breach, but other malicious processes can also be executed from a compromised container, such as network port scanning to look for open paths to attractive resources.

Traditionally, security considerations were addressed a�er development was completed or well-underway. Because code was not exposed to 3rd parties, there was little need for developers to worry about security. However, in cloud-native environments, DevOps must be aware of security considerations from the beginning, as any code inside a container can bepropagated further, regardless of who wrote it. This means that code must be secured from conception and throughout its runtime.

2

A Closer Look at Microservices

The microservices methodology opposes the monolithic approach in which an application is written as a single unit of code and supports faster development and deployment. In a traditional monolith approach, where a single application consists of multiple functions, a problem with one function can delay deployment significantly. The microservice approach allows for independent implementation and deployment, enabling each microservice to be monitored and scaled on its own. As a result, progress or setbacks in one microservice does not impact another.

3

Challenges

As Mathias Biilmann, CEO and co-founder of Netlify, cautions, a microservices environment can become “a very fragmented system where developers need to spend a lot of time and effort on gluing together services and tools, and where there’s a lack of common patterns and platforms that makes working across projects viable.” Resolving this issue may require either the hiring of additional developers or reassigning those qualified.

In addition to fragmentation, there is also a security issue with microservices applications, especially those running to scale as they use a large number of APIs simultaneously communicating with ports. This creates an exponential increase in attack surface.

4

Microservices and DevOps: Better Together

Microservice architecture emerged from DevOps ideologies and practices at Amazon, Netflix, Facebook, Google and several other companies. These companies were pioneers in cloud-based services and using the CI/CD pipeline to build, test, deploy and manage services. The recent switch from monolithic services has allowed the following powerful synergy between microservices architecture and DevOps, in addition to the other benefits of microservices already mentioned:

Deployability: Microservices offer shorter building, testing, and deployment cycles.

Availability: Releasing a new version of a particular microservice requires very little downtime, whereas rolling out a new version of a service in the monolithic application normally requires a full restart of the entire monolith.

Scalability: Microservices can be scaled independently using pools, clusters, and grids.

Modifiability: Microservices offer the flexibility to consume new frameworks, libraries, data sources and other resources. Management: Microservices can leverage the DevOps methodology, especially in agile development frameworks, where the application development effort is divided across teams that are smaller and work more independently

>

>

>

>

>

5

For companies switching to this approach, here are a few tips to make the best microservices-DevOps synergy:

Automate everything: The number of microservices contained in a cloud-native application and the necessity of consistency when working with these microservices makes automation a requirement.

Make your motto: “You build it, you run it.” (Werner Vogel, Amazon CTO): “Development” and “operations” should be combined operationally, not just theoretically.

Create unified development and deployment policies and procedures. Without some standardization, “gluing” microservices together is going to be difficult.

Use common tools for both development and operations. This establishes common terminology, as well as processes for requirements, dependencies and problems.

1

2

3

4

6

Cloud-Native Application Security and Why it Matters

As discussed, cloud-native applications are applications typically composed of many small microservices rather than one large indivisible application developed from scratch. This allows DevOps teams to create and manage each microservice independently of the others. The microservices are linked by “glue,” appearing to users as a single application. By breaking an application into microservices, it is possible to continuously build and debug new features without downtime; working microservices are continually replaced by more fully developed ones. The application can function even if one or more microservices fails; a problematic microservice can be replaced without causing downtime.

But cloud-native apps have several security issues: First, as mentioned above, when cloud native apps run to scale, they use a large number of APIs simultaneously communicating with ports, exposing code segments and services to an attack. Additionally, any vulnerabilities that enter a microservice may go undetected. Unfortunately, the security tools and methods used in monolithic environments are not designed for use with microservices.

To reduce these risks, we recommend these best practices:

Start early: Implement security during the CI/CD to run-time

Automate: The number of microservices in an application and rapid pace of change in development require automated security.

Repeat: Repetition throughout development reduces the chances of vulnerabilities creeping in.

1

2

3

7

Kubernetes Security and DevOps

Kubernetes has become the microservices and container orchestrator of choice for many companies, including Google, IBM, Spotify, Goldman Sachs, and other industry leaders. By default, anything developed in Kubernetes is visible to anyone online, or at least anyone who knows how to look for it.

To give one example, it’s widely known that Kubernetes uses etcd as its cluster database, listening via port 2379/TCP. The port scanning tool Shodan can be used to locate Kubernetes clusters. Therefore, malicious agents can steal and/or alter code or data contained in these clusters.

Moreover, because Kubernetes is an orchestrator, it is agnostic to the underlying system. Kubernetes host and scale different sets of application containers, therefore, you might find your cluster to contain critical applications that have a high value to the organization running alongside less important applications. This scenario calls for better security controls and microsegmen-tation; separating the critical and non-critical applications into different microsegments would allow you to apply different authorization rules to each.

Another security and control issue is that Kubernetes clusters use Ingress controllers to route external network traffic to services in the cluster. Although Istio supports defining rules, they are low-level, applying to each hop between pods in the path to a destination. You cannot easily define a single rule in Istio between an external source and a destination pod. This increases the problem of defining network rules to regulate traffic.

8

In addition, Kubernetes has two API-related issues. First, by default, the Kubernetes API service is exposed to make management easier. Most deployments support applying authentication policies to the port involved, but it’s important to ensure this is done. Tesla found out about this the hard way when it exposed the dashboard that forms part of it main Kubernetes API service to the Internet without authentication.

Second, the Kubelet API, which is popular for managing containers on nodes and some clusters, is available in a version that does not require authentication, allowing hackers access to one’s code.

Once malicious code is entered into a container, it is quite likely to be propagated into every build through deployment. Worse, if a DevOps team does not apply access management rights, such as Role-Based Access Control to containers, an attacker can easily control a cluster a�er breaching one container.

These problems have a basic solution: DevOps must insist on security measures that either block access from outside or require authentication for changes. DevSecOps should have the current information and a list of available tools needed to implement security measures in all stages of development. We also strongly recommend consulting the Center for Internet Security’s CIS Benchmark for Kubernetes.

9

The CI/CD Pipeline and Its Security Needs

Cloud-native development uses the Continuous Integration/Continuous Deployment (CI/CD) pipeline methodology. This means that DevOps teams merge code changes multiple times a day into a common build housed in a central repository (CI), which is automatically deployed (CD), usually daily. In a cloud-native environment, the CI/CD pipeline comprises of containers and microservices, using an orchestrator such as Kubernetes and a deployment tool such as Jenkins. It is therefore essential to use the techniques described in this eBook along with scanning tools to ensure that all code is clean and kept secure.

It’s especially important that open-source so�ware is automatically scanned because as Sonatype’s Derek Weeks notes, it composes 80-90% of actual application code.

10

Portshi�: Securing your infrastructure from CI/CD to run time

Kubernetes environments have no mechanism to ensure pod security, leaving CI/CD pipelines vulnerable. This challenge demands a new type of security solution that will be automated and implemented by DevOps teams early on the development cycle and applied continuously.

Portshi� offers a Zero-Trust architecture with its identity based cloud workload protection solution. First, it assigns a unique, signed digital identity to every workload early in the CI and CD pipeline process. It then uses these identities to enforce run-time security policies on clusters, preventing unauthorized workloads from communicating with legitimate ones. Seamlessly integrated with Kubernetes and service mesh, Portshi�’s solution enables automating run-time protection and mapping all identifications and communications. It simplifies cloud-native app security and improves enforcement of policies for every workload as well as environment.

By assigning each workload a unique digital identity, Portshi� solves the run-time visibility challenge by ensuring that all processes, containers, and their connections, are identified at run-time with signed identities. Only applications with signed identity are able to access the infrastructure.

11

The Portshi� platform provides full security throughout the entire production and development cycles of cloud-native applications, making it easier for DevOps to keep their code safe from malicious actors and to prevent unauthorized workloads from communicating with legitimate ones.

Let’s talk about making your cloud-native applications secure from code to run-time. Click here to schedule a demo.

12