Since the launch of Chainguard Enforce in 2022, we have seen organizations of all sizes enthusiastically leverage our comprehensive software supply chain security platform to protect their software delivery. Today, Chainguard Enforce is adding new enterprise features to extend the platform beyond traditional admission controller and security platform capabilities in order to help our customers manage their deployments in the context of their enterprise cloud environments.
New Configuration Option: Failing Open
Chainguard Enforce, like most Kubernetes admission controllers, is configured to "fail closed” by default. That means that if an admission request is not matched by a specific policy in the user's organization, the request will fail. While this is preferable in strict production environments, organizations may want to use Enforce to standardize across their environments for every application and in every phase of the software development lifecycle. Organizations may prefer this route so applications that don't match a defined policy to be deployed anyway.
For example, think about a test or staging environment. For those environments, you may want to allow applications to be deployed with a warning. Meanwhile, for production environments, you want those deployments to be stopped if they do not meet your policy requirements. With the new "Failing Open" option, Enforce administrators can configure portions of their infrastructure to allow deployment by default, even while monitoring compliance with defined policies through our Continuous Verification feature. Customers can also take advantage of customizing the admissions controller behavior with the “Failing Open” feature across different types of clusters to meet their specific policy needs in all environments.
“Having a ‘fail open’ configuration in Chainguard Enforce was a critical need for our development and security teams working to secure our software supply chain across the entire SDLC,” said Drew Hintz, Director of Product Security at Block. “We needed a developer-first approach with low friction on the end user. Enforce’s new capability will allow us to customize our admission controller behavior in all of our environments without sacrificing our compliance needs for production workloads that have to meet our security policy requirements.”
To configure this option on a cluster, a user can use the chainctl to enable deployments to go through by default, rather failing:
New Configuration Option: Kubernetes Namespace Opt-in vs Opt-out
We’re also launching a new configuration option that allows administrators to configure Enforce to apply policy enforcement to all namespaces by default, and only lets users opt out of enforcement by applying a specific label to the namespace.
Out of the box, Chainguard Enforce requires users to apply a label to each Kubernetes namespace they wish to apply policies on in order to control deployments on that namespace. Our team designed it this way so that installing an admission controller would not immediately stop all deployments to a cluster in all namespaces (such as kube-system, etc.) and subsequently make the cluster unusable. Today’s announcement allows organizations to ensure there are no gaps in enforcement across any of their environments.
This is useful when an organization lets their engineers deploy clusters in development and test environments without giving the administrators access to the cluster. In this case, if the parent account can deploy the Enforce agent (or connect in agentless mode), policies can still be applied and monitored on every cluster, and every namespace.
To use this feature of Enforce, simply configure your cluster installation with this optional flag
More information can be found in the Enforce for Kubernetes documentation.
Note that the above optional flag will enable enforcement of policies across all Kubernetes namespaces and in order to exclude namespaces, one need to label them with
Policy Versions
Another Enforce feature by popular customer demand is visibility into how policies affect their clusters over time and the ability to roll back if changes introduce disruption. We are excited to announce Policy Versions, which keeps a record of every change to an Enforce policy. This includes the date and time it was changed, who made the change, and allows you to roll back to previous versions of a policy if needed. This is a fantastic enterprise reliability feature that really separates Enforce from free and open source products that require users to manage their own testing and rollback plans.
Custom Identity Providers
We know some organizations leverage custom identity providers (IdPs) beyond Google, GitHub or Gitlab. Today, organizations can bring their own identity providers to Enforce as long as it supports OIDC such as Okta, PingID and Azure Active Directory.
This allows customers to tie in their SSO providers and lets security teams control access to Chainguard. Please see the following documentation pages on how to configure Chainguard Enforce to leverage an OIDC compliant IdP in order to delegate authentication and authorization and allow for fine grained access control to Enforce.
Enterprise Reliability
Chainguard Enforce continues to expand its capabilities to be the most feature-rich, enterprise-ready platform for software supply chain security on the market. We’re excited to be addressing these needs of enterprise customers looking to protect their software supply chains.
Interested in learning more? Sign up for a Chainguard Enforce 30 day trial.
