How Zero Trust Security Will Revolutionize DevSecOps
Due to the rise of the cloud and containers, software development has made giant steps forward in productivity, agility and scale. DevOps and DevSecOps have created controlled, easily deployable, secure and automated development-to-production processes that allow software updates multiple times per day with less risk. More and more enterprises are moving over to a cloud-native and containerized world when developing new applications.
The biggest DevOps breakthrough is the Continuous Integration and Continuous Deployment (CI/CD) pipeline. When deploying applications on infrastructure in the cloud, APIs and algorithms allow developers to automate microservice workloads to install, test and deploy to production … or roll back the latest code change (known as infrastructure as code). This provides fast feedback to developers and greatly improves software development efficiency.
These cloud-driven development methods are forcing the need for a similar revolution in enterprise network security automation between services that naturally supports the CI/CD pipeline.
Current network security concepts in the cloud don’t work well
Because enterprise network security relies on static firewall rules that can only be updated in maintenance windows after a change approval process, securely deploying applications in an automated way will not work in dynamic cloud environments.
For this reason, most cloud environments come with built-in concepts like security groups and container service meshes that allow automatic network security provisioning as part of service deployments. These methodologies might work well for simple applications but lose their power as soon as you make a connection to or from various regions, clouds or technology stacks. For example, there is no interoperability between different cloud vendors’ security groups or different Kubernetes clusters.
The fallback results in reverting to network ACLs to filter IP addresses over intercloud connectivity (SD-WAN/IPSEC/MPLS) which is problematic when ephemeral workloads are used that change IP addresses constantly or when multiple services share the same cluster IP.
There’s a better way.
Five disruptive ways Zero Trust access improves automated CI/CD pipelines
Zero Trust Network Access (ZTNA) changes a few basic network security concepts and improves automated CI/CD pipelines with:
- 100% software
- Business-driven network security
- Applies secure access to the session not the entire network
- Real-time security based on identity and context
- Full audit trails
This software-driven approach can run on the OS and/or container level to remove technology barriers and secure interservice connections between cloud platforms, Kubernetes clusters and even old school, on-premises hardware. This allows secure communication between services, independent of technology stacks. Embracing cloud-based concepts, such as APIs and Kubernetes operators to deploy configurations from code, the security framework can be implemented like applications and services. Infrastructure as code can extend to the security layer (network security as code) while remaining agnostic to underlying technology.
With ZTNA, policies typically are managed at a business-driven level, not at the network layer. So, security teams control overall policies aligned to business definitions and ZTNA automatically translates them into the right network access controls. This automation means change control processes, like advisory boards for new deployments, are no longer required. For example, containers tagged as production assets can only communicate to other matching production tagged services.
Applying security to network sessions of a service is a game-changer for automation. In a traditional environment, the network is defined by routing tables and interconnectivity, while security is defined by firewall engines that are applied/enforced in many parts of the network. All firewall rules must align to make a network session successful. Changing firewall rules in production environments is intimidating because they can impact the entire production.
In contrast, by applying security directly to a session, secure tunnels are created between services to enforce security on each individual connection. This makes it easy to change, test and scale. By creating a tunnel between services, no extra latency is added (about 1ms max) and security rules only affect that specific session. A direct tunnel between services is important, as a cloud-routed model adds unnecessary latency in most cases … plus a direct tunnel allows disparate clouds to work with overlapping IP-address spaces.
ZTNA uses strong identity controls, such as service certificates to identify the service and define what it can access based on matching higher-level security policies. Besides identity, service attributes like tags, location and role can be included to feed the policy decision. For example, deploying a specific service into development, staging and then production allows connection to different services based on service attributes. This also enables services to talk to their matching peers based on context and completely independent from the underlying technology they run on.
With ZTNA, every service connection is audited with the matching policy and service attributes, making it easy to provide detailed audit logs for development versus production environments.
A little example …
How can ZTNA make network security part of the entire CI/CD pipeline? Let’s assume a simple application called a booking_app runs inside a container of a Kubernetes cluster. This application needs to get data from an external resource from an API in another cloud and needs to perform an update to a database that still runs on-premises.
The policy in this example should dictate that the booking_app can only talk to the remote API and the database using the tag [X] for each resource. As part of the booking_app, a small Kubernetes sidecar will be deployed that provides secure tunnels to the different resources based on the described policy.
Just by changing tag [X] from development to staging tag [Y] or production tag [Z], the same policy rules can be used to deploy the software in different environments, while the network security creates matching tunnels and access rules as part of the deployment code.
Be ready for the future
ZTNA is a secure access tool that allows users to connect safely to workloads inside an enterprise network. The largest ZTNA deployments have been proven to work with hundreds of thousands of users while achieving ultralow latency and linear scalable bandwidths, driven by cloud concepts like autoscaling and stateless architectures. ZTNA also has an established track record of delivering secure access for any type of infrastructure to enteprises with only on-premises equipment to all-cloud ecosystems.
ZTNA is also revolutionizing the DevSecOps world with technology maturity, the power of scale and disruptive attributes aligned perfectly to modern software CI/CD pipeline concepts. Implementing ZTNA unifies user-to-service and service-to-service access into a single policy model and accelerates DevSecOps. And if you’re not that far in your cloud CI/CD journey, remember that ZTNA protects your current network in a better, more cost-efficient way while your security stack becomes future-proof and prepared for when the enterprise might opt for a full cloud model.
Appgate SDP Kubernetes access control security
We just announced Appgate SDP’s extension of Zero Trust secure access into cloud-native workloads to protect Kubernetes-based microservices. We invite you to visit our Github page (https://github.com/appgate/sdp-k8s-client) or contact us to learn more about how Appgate SDP, our leading ZTNA solution, can unify user-to-service and service-to-service access into a single policy model, while accelerating the power and agility of your CI/CD pipeline.