Enhancing Kubernetes Security by Shifting Security Left

In the rapidly evolving world of Kubernetes security & compliance, DevOps and DevSecOps teams are detecting security challenges and compliance issues later in the development & deployment cycles.

We are excited to share new features and updates that help DevOps and DevSecOps teams detect issues and ensure compliance throughout the development cycle. We’ve been hard at work since we introduced Styra’s Declarative Authorization Service (DAS) in March, and today we are announcing a variety of additional features to further bolster our policy and compliance solution for Kubernetes.

We believe these features will help drive a paradigm shift in the enterprise development lifecycle by providing developers with the right toolset to detect issues and ensure compliance much earlier.

This blog details the features we are announcing today:  

• Styra Policy Check Github App

• Styra CLI for policy checks in CI/CD Pipelines
• Support for Git as source of truth

• Enterprise security controls and

• Many more policy guardrails

Shift security left

“Shifting Left” is an established practice in software development where teams focus on quality, work on problem prevention instead of detection, and generally focus on testing earlier. Similarly “Shift Security Left” is the same principle from a security perspective. Security policy works best when it eliminates risk early. If deployments are vetted for security issues from the early phases of development, it’s less likely that security concerns will arise toward the end of the delivery pipeline.

Since developers are not always security experts, shifting security left works only when proper security tooling is made available to developers. The tooling can ensure that Kubernetes configurations/deployments are in compliance with internal or external security policies/regulations and notify developers earlier so issues are fixed in a timely manner, and before getting committed into production. Security (DevSecOps) can define the policies once and check if config/deployments for Kubernetes are in compliance at every stage: Development, Build/Test and Production. This method will stop errors and eliminate rogue deployments early and directly helps enterprises be more productive.

To facilitate this shift, Styra now offers policy enforcement capabilities for development at code check-in, and for continuous integration, at the build/test phase.

Policy enforcement during Code check-in via Styra Policy Check Github App

Styra now provides a GitHub marketplace application that can be installed in Github organization/account to analyze Kubernetes configurations/deployments for compliance based on the policies defined in Styra.

Styra’s Policy Check Github app performs the defined policy checks as a part of commits on a local branch to be pushed to the protected remote branch. Detailed build output from the Styra policy check is included as a part of the Pull request so developers can understand the impact of the code.

Policy enforcement during continuous integration (CI) phase via Styra CLI

Styra now offers CLI & API toolkits that make it easy to integrate policy checks into existing continuous integration (CI) tools like Jenkins, etc. As a part of the CI pipeline/workflow, the Styra CLI performs policy checks against a local Git repository and stops the pipeline from advancing if failures exist. Detailed output from policy checks is, of course, provided to developers as feedback.

Styra CLI binaries are available for Mac, Windows and Linux. A Styra CLI docker image is also available to make it easier for integration into the Jenkins pipelines.

Git as source of truth

GitOps is a new way of continuous delivery for cloud-native environments. At the heart of GitOps is the principle of using Git as the source of truth for describing deployments (both apps as well as infrastructure) declaratively using yaml files. (For example, Kubernetes manifests.) Any change request needs to be handled as code and maintained in the Git repository.

To better fit into this new model, Styra now includes the ability to save policies into Git. This allows users to author policy via the Styra UI, CLI, or APIs, and then store the subsequent policies in Git, to better enable enterprises who use Git for version control/change management.

Styra is also including the ability to fetch policy bundles from Git and distribute them to Open Policy Agents (OPAs) running on clusters.

Enterprise security controls: Single Sign-On (SSO), RBAC, and user activity

Styra’s DAS control plane has a full feature set built out for enterprises. Styra adds access management features that don’t get in the way of security and allows enterprises to meet compliance requirements and have complete visibility into access and behavior.

• Single Sign-On (SSO): Styra now fully supports SSO using OpenID Connect. This includes password complexity policies, time-of-day access, two-factor authentication, and any other controls required by your organization’s security policy. Enforcing SSO login has many benefits for both you and your users. It allows users to log in to Styra quickly and easily, and allows admins to manage users from one centralized user directory.
  
  
  
• Role Based Access Controls – Styra added support for role-based access control to help manage who has access to resources and what operations can be done. Styra currently supports two roles: Administrator and Read-only. The Administrator role can control all aspects of the control plane while Read-only allows users to log in with restricted functions. Roles will be further extended in the future for more fine-grained controls.
  

• User Activity –  Styra now provides user activity logs that let you track all the actions from users, as well as the activity from API calls and system events. Activity logs contains log entries for operations that modify the configuration or metadata of system resources. Any API call that modifies a resource such as creation, deletion, updating, or modifying a resource using a custom verbs fall into this category. All log entries record the request and response data of the API actions that were performed.

Extended number of policies in the built-in library

Our customers have told us they want more policy rules—and we’ve got them. A new set of built-in policies has been added to the library, including the following and many more:

• Restrict external load balancers – Prevent creating new externally-facing IP addresses that could be used for command and control traffic, data theft, or simple unintended access.
• Specify container resource requests – Ensure that all containers have specific CPU and memory requirements, to prevent attacks that purposely over-utilize resources to cause outages, or reschedule pods across clusters, and to better utilize resources.
• Block master toleration – Prevent rogue workloads from being pushing into nodes responsible for managing cluster scheduling.

Get started

We hope you’re as excited as we are about this new release. The Styra team will be showcasing these new features at KubeCon Barcelona, booth S20, so stop by if you’re at the show! You can also learn more about all the new features by starting a free trial for 30 days.