Cloud-Native Stack Security€¦ · CLOUD-NATIVE STACK SECURITY WITH VMWARE ENTERPRISE PKS 4 Within...

WHITE PAPER - February 2019

CLOUD-NATIVE STACK SECURITY How VMware Enterprise PKS Secures Containers and Kubernetes

VMware, Inc. 3401 Hillview Avenue Palo Alto CA 94304 USA Tel 877-486-9273 Fax 650-427-5001 www.vmware.comCopyright © 2018 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. and its subsidiaries in the United States and other jurisdictions. All other marks and names mentioned herein maybe trademarks of their respective companies.

CLOUD-NATIVE STACK SECURITY WITH VMWARE ENTERPRISE PKS

Table of Contents

Introduction: Security Risks and Threats Pervade the Stack 3

Layers Requiring Security 3

Toward Fully Integrated Security 4

NIST Security Concerns with Containers and Orchestration Systems 4

Containers Alone Are Inadequate Security Boundaries 4

Risks of Misconfiguration on a Physical Host 6

Securing the Orchestration System 6

Multi-Layer Security Model of VMware Enterprise PKS 7

Infrastructure Layer 7

Securing Network Infrastructure with VMware NSX 8

Preventing Intrusions from Spreading with Auto-Segmented Clusters 8

Full-Stack Visibility 9

Container Management Layer 10

Secure Private Image Registry 11

Flexible Multitenancy 11

Vulnerability Scanning 12

Content Trust 13

Micro-Segmentation with NSX 14

Application Layer 16

Monitoring Containers and Kubernetes Clusters with Wavefront 16

Gaining Visibility with vRealize Operations 17

Logging Events with vRealize Log Insight 17

Platform Layer: Identity and Access Management 17

VMware Enterprise PKS API for UAA 18

Controlling Access to Kubernetes Clusters 19

Conclusion 19



3

Introduction: Security Risks and Threats Pervade the Stack

Containerized applications demand full-stack security. Threats and security risks abound throughout an unsecured cloud-native stack, and containers, like any other computer technology, are subject to various attack vectors.

Without isolating containers on virtual machines, for instance, containers running on the same physical host can potentially connect to one another, which can allow an intrusion to escape from a container and spread laterally across a host.

Container images present similar security challenges: Images can be built by layering other images, which can contain vulnerabilities, and those vulnerabilities can find their way into production systems. Developers can also freely pull images from remote repositories of unknown trustworthiness. To make matters worse, container images can be spoofed.

Orchestration systems without adequate protection add an additional layer of risk—risk that is embedded in complex, rapidly evolving technology. Multitenancy and microservices, meanwhile, complicate authentication and access control. In this context, microservices and various networking layers can be difficult to isolate, secure, and monitor. Tracing access, events, and interactions throughout the stack poses a unique problem.

Layers Requiring Security

A full cloud-native stack can be divided into the following layers, each of which must be secured:

• Application layer• Container management layer• Platform layer• Infrastructure layer

Figure 1: The layers in a cloud-native stack.

VMWARE ENTERPRISE PKS AT-A-GLANCE

VMware Enterprise PKS provides a highly available, production-grade Kubernetes platform equipped with advanced networking from VMware NSX, a secure image registry, and lifecycle management with BOSH. The solution radically simplifies the deployment and operation of Kubernetes clusters so you can run, orchestrate, secure, and maintain containers at scale on VMware vSphere.

KEY BENEFITS

• Quickly provision Kubernetes clusters on demand

• Deliver high availability for Kubernetes components with rolling upgrades, health checks, and auto-healing

• Use advanced container networking with micro-segmentation, load balancing, and security policies

• Secure container images with vulnerability scanning, image signing, and access control

• Improve operational efficiency with monitoring, logging, and analytics



4

Within these layers, container images are created, deployed, managed, orchestrated, and replaced. As part of their lifecycle, containers rely on a collection of systems and constructs embedded in these layers—systems and constructs such as image registries, networking, persistent storage disks, APIs, multitenancy, identity management, and access control.

Toward Fully Integrated Security

Without being able to integrate containers and an orchestration system with your existing security systems and your data center, the security requirements of containerized applications can lead you to build custom components or integrations at great risk and expense.

This paper describes how VMware® Enterprise PKS secures containers and the orchestration system throughout the stack by doing the following:

• Providing container-specific security controls• Integrating with existing authentication and access control systems• Extending the established security controls of a VMware software-

defined data center to containers• Integrating with monitoring and logging tools• Addressing the container security guidelines of the National Institute

of Standards and Technology.

NIST Security Concerns with Containers and Orchestration

In September 2017, the National Institute of Standards and Technology published its Application Container Security Guide, also known as NIST Special Publication 800-190. It explains the security concerns with containers and recommends how to address them. The guide exposes several fundamental areas of concern with containers:

• Degree of isolation• Operating system management and configuration• Orchestration systems without adequate protection

Containers Alone Are Inadequate Security Boundaries

Containers are not miniature VMs, and containers do not establish security boundaries as VMs do. An important implication of the Application Container Security Guide is to run containerized applications on virtual machines. “While containers provide a strong degree of isolation, they do not offer as clear and concrete of a security boundary as a VM. Because



5

containers share the same kernel and can be run with varying capabilities and privileges on a host, the degree of segmentation between them is far less than that provided to VMs by a hypervisor.”1

Deploying containers with VMs encases an application with two layers of isolation, an approach that is well-suited to cloud-style environments with multitenancy and multiple workloads. “Docker containers pair well with virtualization technologies by protecting the virtual machine itself and providing defense in-depth for the host,” a Docker white paper on security says.2

The major cloud providers, such as Google and AWS, isolate the container workloads of tenants by using separate VMs. Because containers are inadequate security boundaries, only highly trusted code should be run in containers on the same VM or physical host. Microservices add another dimension to container security. According to a Docker white paper on security, “Deploying Docker containers in conjunction with VMs allows an entire group of services to be isolated from each other and then grouped inside of a virtual machine host.”3

The same holds true for pods in Kubernetes. “Ultimately, in the case of applications running in both VMs and containers, the VM provides the final security barrier. Just like you wouldn’t run programs with mixed security levels on the same VM, you shouldn’t run pods with mixed security levels on the same node due to the lack of guaranteed security boundaries between pods,” writes Jianing Guo on the Google Cloud Platform Blog.4

The Application Container Security Guide suggests that “it may be an unnecessary risk to run apps of different sensitivity levels together on the same host OS. Segmenting containers by purpose, sensitivity, and threat posture provides additional defense in depth. By grouping containers in this manner, organizations make it more difficult for an attacker who compromises one of the groups to expand that compromise to other groups.”

NIST ON COMBINING CONTAINERS AND VIRTUAL MACHINES

“Although containers are sometimes thought of as the next phase of virtualization, surpassing hardware virtualization, the reality for most organizations is less about revolution than evolution. Containers and hardware virtualization not only can, but very frequently do, coexist well and actually enhance each other’s capabilities. VMs provide many benefits, such as strong isolation, OS automation, and a wide and deep ecosystem of solutions. Organizations do not need to make a choice between containers and VMs. Instead, organizations can continue to use VMs to deploy, partition, and manage their hardware, while using containers to package their apps and utilize each VM more efficiently.”

APPLICATION CONTAINER SECURITY GUIDE, NIST SPECIAL PUBLICATION 800-190.

1 NIST Special Publication 800-190, Application Container Security Guide, by Murugiah Souppaya, Computer Security Division Information Technology Laboratory; John Morello, Twistlock, Baton Rouge, Louisiana; Karen Scarfone, Scarfone Cybersecurity, Clifton, Virginia. September 2017. This publication is available free of charge from https://doi.org/10.6028/NIST.SP.800-190

2 Introduction to Container Security, Docker white paper, Docker.com.

3 Introduction to Container Security, Docker white paper, Docker.com.

4 “Demystifying container vs VM-based security: Security in plaintext,” The Google Cloud Platform Blog, by Jianing Guo, August 9, 2017. See https://cloudplatform.googleblog.com/2017/08/demystifying-container-vs-VM-basedsecurity-security-in-plaintext.html



6

Risks of Misconfiguration on a Physical Host

Containers or the operating system of a physical host can easily be misconfigured, increasing the attack surface and the level of risk, the NIST Application Container Security Guide says. “Carelessly configured environments can result in containers having the ability to interact with each other and the host far more easily and directly than multiple VMs on the same host.”5 Examples of carelessly configured environments include running containers in privileged mode, packaging the SSH daemon with containers, and letting containers mount sensitive directories on the host.

In contrast, the abstraction, automation, and isolation of an operating system running on a VM in a hypervisor reduces the attack surface and decreases the risk of a security breach.

Securing the Orchestration System

Another concern of the Application Container Security Guide is recommending countermeasures to secure the orchestration system managing containers. The suggested countermeasures in the NIST guide include the following:

• The use of enterprise-grade authentication services using strong credentials and directory services.

• Granular access control for administrative actions based on hosts, containers, and images.

• Isolating containers to separate hosts based on the sensitivity level of the applications running in them.

Another NIST document, Security Assurance Requirements for Linux Application Container Deployments, sets forth security requirements and countermeasures to help meet the recommendations of the Application Container Security Guide when containerized applications are deployed in production environments. The orchestration system or its components and tools should have the following capabilities:

• Logging and monitoring of resource consumption of containers to ensure availability of critical resources.

• The orchestration system must work with many container hosts, not just one, to be able to provide a global summary of resource usage for all running containers.

5 NIST Special Publication 800-190, Application Container Security Guide, by Murugiah Souppaya, Computer Security Division Information Technology Laboratory; John Morello, Twistlock, Baton Rouge, Louisiana; Karen Scarfone, Scarfone Cybersecurity, Clifton, Virginia. September 2017. This publication is available free of charge from https://doi.org/10.6028/NIST.SP.800-190



7

Running containers on physical hardware and managing the containers with an orchestration system would require you to connect each physical machine to an authentication and access control system.

To isolate containers by sensitivity level, you would have to use an inefficient number of physical machines. As a result, resource utilization would suffer while management overhead increased—a situation made worse by a NIST requirement to use many types of container hosts.

Multi-Layer Security Model of VMware Enterprise PKS

VMware Enterprise PKS, which integrates with VMware vSphere and Google Cloud Platform, helps secure containerized applications across the entire stack, from the infrastructure and platform layers to the container management and application layers.

The following sections describe how the multilayer security model of VMware Enterprise PKS addresses security and NIST requirements across the four main layers of a container technology stack:

• Application layer• Container management layer• Platform layer• Infrastructure layer

Identity and access management as well as monitoring traverse all the layers to provide a unified, full-stack approach to authentication, access control, and auditing.

Infrastructure Layer

One of the layers in the multilayer VMware Enterprise PKS security model is infrastructure. At the layer of the infrastructure, several security or compliance problems exist:

• Running containers on bare metal does not provide adequate isolation and security boundaries

• Intrusions can spread laterally• Networking layers for containers and apps can proliferate and be hard

and complex to secure and monitor• Tracing events and interactions is difficult

This section addresses the security of the infrastructure on which VMware Enterprise PKS runs and how VMware Enterprise PKS solves these problems. The infrastructure that VMware Enterprise PKS uses is typically VMware vSphere, but it could also be Google Cloud Platform. A core part of the VMware Enterprise PKS security model for vSphere infrastructure is VMware NSX.



8

Securing Network Infrastructure with VMware NSX

VMware NSX provides network virtualization for an SDDC, abstracting such networking functions as switching, firewalling, and routing on top of your existing physical network. NSX embeds the networking and security functionality typically handled by hardware directly in what can be thought of as a network hypervisor that is distributed throughout the data center.

This abstraction, in turn, enables levels of security and efficiency for containerized workloads that were previously infeasible. IT can, for example, apply micro-segmentation with distributed stateful firewalling and dynamic security policies attached directly to individual container workloads in Kubernetes clusters. NSX Transformers furnishes the complete set of Layer 2 through Layer 7 networking services that is needed for pod-level networking in Kubernetes so that you can quickly deploy networks with micro-segmentation and on-demand network virtualization for containers and pods.

The integration of NSX-T with VMware Enterprise PKS delivers an immediate, far reaching impact on security for cloud-native applications:

• Policies for micro-segmentation that go beyond the standard security policies of Kubernetes; these policies are explored further in the section on micro-segmentation below.

• Network polices that help secure traffic across Kubernetes namespaces and within pods in the same namespace.

• Operational tools and troubleshooting utilities that can debug inter-pod communication for visibility and auditing.

• A unified policy layer for VMs and Kubernetes pods.

In VMware Enterprise PKS, NSX-T automates container networking in Kubernetes. An app running in the Kubernetes cluster can use the virtual network to communicate with the outside world. Incoming traffic makes use of the load balancer, which NSX automatically provisioned for the Kubernetes cluster.

Preventing Intrusions from Spreading with Auto-Segmented Clusters

VMware NSX is integrated with VMware Enterprise PKS to automatically segment clusters with virtual routers, which isolate compute environments to prevent an intrusion from spreading.



9

With an NSX network, a single top-tier Tier-0 logical router connects the external network to internal Tier-1 virtual routers, each of which can segment and handle routing for a Kubernetes cluster.

Multiple Tier-1 logical routers provide L3 connectivity; each Tier-1 router can contain multiple subnets. A virtual switch is created for each subnet to provide L2 connectivity, and the VMs running Kubernetes worker nodes belong to the same subnet attached to a virtual switch. The result is controlled, automated segmentation for Kubernetes clusters to isolate compute environments and to prevent an intrusion from spreading.

Full-Stack Visibility

NSX integration with VMware Enterprise PKS gives you visibility across the infrastructure, the virtual overlay networks, and the container network on Kubernetes. With operational tools and troubleshooting utilities like the following, you can trace packets from containers to physical networks and monitor traffic:

• Traceflow• Port mirroring• Port connection tool• Spoofguard• Syslog• Port counters• IPFIX

Figure 2: VMware NSX automatically segments Kubernetes clusters with virtual routers to prevent an intrusion from spreading laterally.



10

Tools such as Traceflow help fulfill the requirements of production-level networking for containerized applications so you can, for example, debug communication between pods and the microservices components of your containerized applications.

As for security, several of these tools enhance monitoring, auditing, and compliance by giving you visibility into the interactions of components in a microservices architecture.

Container Management Layer

At the layer of container management, these problems can be present:

• A container image can easily be built by layering container images of unknown provenance from the Internet

• Vulnerabilities can flow with the image into production environments• Container images can be pulled from remote repositories with unknown

levels of trustworthiness• Container images can be spoofed

Figure 3: With VMware NSX and VMware Enterprise PKS, you can use Traceflow to observe virtual network traffic across containers, pods, the cluster host, and an SDDC.



11

For organizations, additional problems can affect container technology: • Organizations, for example, can demand varying levels of isolation

and multitenancy.• Various development teams need full access to Kubernetes services

and various levels of access to container images.

Secure Private Image Registry

Some of the container management security solutions in VMware Enterprise PKS are provided by Harbor, which is an open source private image registry that scans, secures, and signs container images. Harbor scans images for Common Vulnerabilities and Exposures (CVEs) with Clair to prevent container images with vulnerabilities from running in your data center.

Harbor also integrates with Active Directory or LDAP to provide role-based access control so that you can securely store images behind your firewall. Harbor furnishes project-level content trust and Notary services to sign container images as trusted. Harbor is discussed further in later sections.

Flexible Multitenancy

To isolate workloads and ensure privacy, VMware Enterprise PKS supports multitenancy for multiple lines of business within an enterprise. Different users or different lines of business are able to use their own Kubernetes clusters. Additionally, with NSX-T micro-segmentation, Kubernetes namespaces can be secured for multiple teams using a shared cluster.The flexibility multitenancy of VMware Enterprise PKS can provide individual users with their own Kubernetes clusters on isolated networks. In such a

Figure 4: The flexible multitenancy of VMware Enterprise PKS.



12

multitenancy context, VMware Enterprise PKS can isolate workloads among tenants.

Vulnerability Scanning

Containers often use base images of operating systems like Ubuntu and CentOS from a public image repository, such as DockerHub. The packages of an operating system and the applications on it, however, can contain vulnerabilities. Traditionally, IT operations would patch operating systems on a regular basis, but with cloud-native work streams, IT operations does not manage base images and other packages. Instead, developers select them on demand as they build or extend an application.

Vulnerability scanning helps prevent the exploitation of known vulnerabilities and reduces the risk of security breaches. Identifying a vulnerability of an image and keeping the vulnerability from going into production reduces the attack surface of a containerized application.

In VMware Enterprise PKS, the Harbor image registry scans images with Clair to help prevent images with known vulnerabilities from running in your data center. With Harbor, you can automate the scanning of images or scan them manually.

Clair is an open source project that statically analyzes containers to render vulnerabilities transparent. Clair works by continuously importing metadata about vulnerabilities from various sources, including Common Vulnerabilities and Exposures (CVEs), and storing the metadata in a database. When Harbor scans an image, Harbor checks the database through the Clair API and produces a list of vulnerabilities.

Figure 5: In VMware Enterprise PKS, scans prevent vulnerable container images from finding their way into production.



13

As a cloud administrator, you can control the vulnerability level of images you deploy. Vulnerabilities are classified as high, medium, low, and unknown. Harbor also identifies the severity levels of vulnerabilities. You can also restrict the images deployed to an endpoint to only ones that have been signed by the Notary in Harbor.

Content Trust

Because images are the building blocks of a containerized application, a security best practice is to use signed container images from a trusted registry. In VMware Enterprise PKS, Harbor establishes trust by letting publishers sign images when they push them into the repository and by preventing unsigned images from being pulled from the repository. The Notary services of the Harbor private registry can furnish project-level content trust to container images to ensure that only trusted images are used as developers create their own layered images, automate the building of an container, or select images for use as the building blocks of an application.

Figure 6: Harbor identifies and lists vulnerabilities in a container image.



14

Micro-Segmentation with NSX

Micro-segmentation uses network virtualization to divide a data center and its workloads into logical segments, each of which contain a single workload. You can then apply security controls to each segment, restricting an attacker’s ability to move to another segment or workload.6

From this basic definition, you can see that for a data center, micro-segmentation reduces the risk of attack, limits the damage from an attack, and improves security. According to VMware NSX Micro-segmentation Day 1, the micro-segmentation capabilities of VMware NSX can implement the following security controls:7

• Distributed stateful firewalling, which can protect each application running in the data center with application-level gateways that are applied on a per-workload basis.

• Topology agnostic segmentation, which protects each application with a firewall independent of the underlying network topology.

• Centralized ubiquitous policy control of distributed services, which controls access with a centralized management plane.

• Granular unit-level controls implemented by high-level policy objects, which can create a security perimeter for each application without relying on VLANs.

Figure 7: Signing container images as trusted with Notary prevents the use of spoofed images as well as those of dubious origin.

6 For more information about what micro-segmentation is and what is isn’t, see Micro-segmentation for Dummies, by Lawrence Miller and Joshua Soto, published by John Wiley & Sons, Inc. 2015.

7 VMware NSX Micro-segmentation Day 1, by Wade Holmes, published by VMware Press, 2017.



15

• Network-based isolation, which implements logical network overlays through virtualization.

• Policy-driven unit-level service insertion and traffic steering, which can help monitor network traffic.

NIST Special Publication 800-125B, Secure Virtual Network Configuration for Virtual Machine (VM) Protection, sets forth recommendations for securing virtualized workloads. The micro-segmentation capabilities of NSX satisfy the security recommendations made by NIST for protecting virtual machine workloads. For more information, see VMware NSX Micro-segmentation Day 1.

NSX adds network policies and micro-segmentation to meet the isolation requirements of workloads. You can, for example, define micro-segmentation policies based on traffic flow patterns among the namespaces in which containerized applications are running. Network policies can also segregate pods to securely handle a microservices-based architecture. Each Kubernetes namespace can be isolated from other namespaces. If you have three namespaces, for example, NSX automatically sets up an isolated network for each one. With NSX managing container networking interfaces on VMware Enterprise PKS, network policies specify how traffic can move both between and within Kubernetes namespaces. In short, NSX lets you craft rules to impose your security requirements on workloads.

NSX can enforce additional types of policies:

• Group policies based on IP address• Egress policies• Policies that route traffic to different virtual machines based on

the names of VMs.• Policies that specify what traffic can enter and leave the network for a

containerized application.

MICRO-SEGMENTATION FOR CONTAINERS

Micro-segmentation uses network virtualization to divide a data center and its workloads into logical segments, each of which contain a single workload. You can then apply security controls to each segment, restricting an attacker’s ability to move to another segment or workload.



16

Application Layer

The application layer of a cloud-native stack poses problems of visibility and auditing. At the layer of application management, the following requirements should be met:

• Operational visibility is needed at each layer of the stack, especially the application layer.

• Audit capabilities are required.

VMware Enterprise PKS integrates with several other solutions from VMware to monitor containerized applications and log events: Wavefront by VMware, VMware vRealize Operations, and VMware vRealize Log Insight.

Monitoring Containers and Kubernetes Clusters with Wavefront

Wavefront efficiently monitors containers at scale. Its dashboards give DevOps real-time visibility into the operations and performance of containerized workloads and Kubernetes clusters.

The Wavefront service can measure, correlate, and analyze data across containers and Kubernetes clusters. The dashboard displays data on the performance of microservices and resource utilization to help you identify issues and optimize applications. The data can, for example, help make decisions about how and when to scale a container environment.

Figure 8: Using NSX to apply micro-segmentation denies inter-container communication.



17

Gaining Visibility with vRealize Operations

With VMware vRealize® Operations™, you can improve performance, avoid business disruption, and become more efficient with comprehensive visibility across applications and infrastructure. When you integrate vRealize Operations, with VMware Enterprise PKS you can enable DevOps to effectively monitor and troubleshoot the performance of the Kubernetes clusters and its underlying infrastructure. The outcome is increased operational efficiency.

Logging Events with vRealize Log Insight

VMware vRealize Log Insight™ can be integrated with VMware Enterprise PKS to deliver highly scalable log management with actionable dashboards, analytics, and broad third-party extensibility, giving you deep operational visibility and faster troubleshooting.

Platform Layer: Identity and Access Management

Porting identities and access policies to applications depends on how easily you can integrate your corporate directory service with your container platform. VMware Enterprise PKS integrates with Active Directory or LDAP to authenticate users and groups and control access to the platform.

Figure 9: Wavefront by VMware gives you visibility into the operations, performance, and resource utilization of containerized applications and Kubernetes clusters.



18

In VMware Enterprise PKS, identity and access management is handled predominantly by a service called User Account and Authentication, or UAA. A multitenant identity management service that is also used in Cloud Foundry, UAA is an OAuth2 server that issues tokens and authenticates users. UAA integrates with Active Directory or the Lightweight Directory Access Protocol so you can use your corporate directory service to manage identities and control access to the VMware Enterprise PKS platform. UAA supports standard protocols such as Security Assertion Markup Language (SAML) and OpenID Connect to provide single sign-on and delegated authorization to web applications. It can be invoked by using JSON APIs, and most of the APIs are defined by the specifications for the OAuth2, OpenID Connect, and SCIM standards.

Connecting VMware Enterprise PKS to a SAML external user store lets the UAA server delegate authentication to enterprise user stores. If your enterprise user store is exposed as a SAML identity provider for single sign-on (SSO), you can configure SSO to allow users to access the VMware Enterprise PKS API without creating a new account and without re-entering their credentials.

VMware Enterprise PKS API for UAA

The API of VMware Enterprise PKS works with UAA to manage authentication and authorization. To make this happen, VMware Enterprise PKS deploys a broker VM that contains the API server, a UAA server, and the VMware Enterprise PKS broker. You can communicate with these services by installing command-line tools for VMware Enterprise PKS, UAA, and Kubernetes on your local workstation. Here’s a diagram demonstrating how these services interact:

Figure 10: The interactions of the services providing authentication and access control in VMware Enterprise PKS.



19

A UAA administrative access token, for example, authorizes you to make requests to the VMware Enterprise PKS API by using the VMware Enterprise PKS CLI and to grant cluster access to users.

Controlling Access to Kubernetes Clusters

When a user connects to VMware Enterprise PKS, the API sends a request to the UAA server to validate the user’s token. If the UAA server confirms that the token is valid, the API uses the cluster information from the broker to respond to the request. If the user runs the Vclusters command, the CLI returns a list of the clusters that the user is authorized to manage.

Conclusion

The following diagram summarizes how VMware Enterprise PKS secures all the layers of a full cloud-native stack.

VMware Enterprise PKS delivers fully integrated security throughout the cloud-native stack to help meet NIST requirements for the security of containers and their orchestration system.

Authentication and role-based access control allow only authorized users to access Kubernetes clusters and the container registry.

Figure 11: How VMware Enterprise PKS secures the entire cloud-native stack.



20

Micro-segmentation and network security policies can be associated with individual container workloads to prevent inter-container communication while Traceflow and other tools give you visibility into how traffic moves through the stack.

Vulnerability scanning and Notary services give you the confidence to trust your container images.

Tools such as Wavefront and vRealize Log Insight deliver comprehensive visibility into not only the underlying infrastructure but also container operations.

VMware Enterprise PKS integrates all these security controls and components into a single cloud-native stack that protects your containerized applications and Kubernetes clusters.

LEARN MORE ABOUT CLOUD-NATIVE SOLUTIONS FROM VMWARE

To find out more about how VMware can help you build, run, and manage cloud-native applications, see https://cloud.vmware.com/

https://cloud.vmware.com/pivotal-container-service

Cloud-Native Stack Security€¦ · CLOUD-NATIVE STACK SECURITY WITH VMWARE ENTERPRISE PKS 4 Within...

Documents

Transcript of Cloud-Native Stack Security€¦ · CLOUD-NATIVE STACK SECURITY WITH VMWARE ENTERPRISE PKS 4 Within...