Kubernetes has become the de facto way to run modern computing platforms, both in the cloud and on-premise. This is a huge change from just a few years ago, and it didn’t happen overnight. On the road to production readiness with Kubernetes, many have run afoul. Thanks to Kubernetes Failure Stories though, engineering teams from around the world have shared in detail what they did wrong and how they can avoid making the same mistake in the future.

Kubernetes admission control is a mechanism that validates and modifies requests to the Kubernetes API server before they are processed. Admission control can enforce policies, security rules, resource limits, default values and other elements of the cluster’s use. This mechanism can also reject requests that violate certain rules or conditions.

The practice of infrastructure as code (IaC) has enabled platform teams to control infrastructure using code stored in Git. This enables teams to apply standard development practices like code review and testing to infrastructure management. The practice of GitOps takes this a step further by: Open Policy Agent (OPA), thanks to its Rego policy language, enables organizations to manage their authorization policies as code (PaC).

We recently released Enterprise OPA, the drop-in enterprise edition of Open Policy Agent (OPA). With Enterprise OPA, we aim to solve several challenges large organizations encounter when using OPA. These include performance and memory usage when using large datasets, keeping authorization data up to date and performing policy updates in a safe way.

A common use case our customers have for Open Policy Agent (OPA) is access control. The problem of access control is generally broken down into two parts, authentication and authorization. Authentication is about making sure we can trust someone’s stated identity, authorization is making decisions about who can do what.

A microservice application comprises small autonomous services that communicate with each other through application programming interfaces (APIs) — as standalone services or via a service mesh. These API calls or requests raise security and compliance concerns if not appropriately secured through authentication and authorization checks. Service-to-service authorization is the process of determining what actions an authenticated service is allowed to perform based on pre-defined policies.

Many engineers like to stick to the IDE or the command line as they use those for their daily tasks instead of jumping into yet another SaaS web application. To improve the Styra DAS experience for them, we developed Styra Link, a tool that allows users to perform most of the tasks of the Styra DAS UI and manage OPA from the CLI or from VS Code. Styra DAS offers a fully integrated policy authoring and lifecycle management experience in a web-based UI.

As enterprises build and run cloud-native applications on Kubernetes, platform engineering teams are responsible for empowering dozens, hundreds or even thousands of developers to rapidly configure the right infrastructure resources to run mission-critical applications. At the same time, today’s complex threat landscape and strict regulatory environment make it increasingly difficult for developers to configure secure and compliant infrastructure.

Following up from our previous Kubernetes Essential Policy Toolkit Deeper Dive, we’re excited to announce upcoming enhancements to Terraform use cases in Styra DAS and take a deeper dive into the Styra DAS Terraform policy toolkit. With the enhanced Styra DAS Terraform policy toolkit, we’re making it even easier for platform engineering and cloud infrastructure teams to support their company’s application developers while delivering secure and compliant infrastructure configurations.