Skip to main content

Armory Policy Engine – CD Governed Admission Policy

Aug 5, 2021 by Nate Reid

In this demonstration, I’ve configured OPA policy at the K8s cluster, allowing only the Spinnaker service account to create a deployment via the kube-api server. Additionally, I’ve defined a policy within the pipeline via Armory Policy Engine, requiring all images be specified with a tag other than ‘latest’. This demonstrates the centralization and consolidation of admission policy for K8s.

Safe Continuous Deployment/Delivery (CD) is a key focus for us at Armory. Establishing policy-driven governance as a core part of CD pipelines is one way we enhance this goal. Through policy, elements of a CD pipeline are controlled at a much finer level than with RBAC alone.

Open Policy Agent (a.k.a. OPA) is a well-known project to Kubernetes (K8s) administrators, providing policy governance where K8s RBAC leaves off . The OPA project describes itself as “an open source, general-purpose policy engine that enables unified, context-aware policy enforcement across the entire stack”. So, OPA is is a general purpose policy engine that can integrate with any stack, K8s being one of them.

Armory Policy Engine integrates OPA with the CD stack. Policies are applied consistently before deployment, enabling the CD platform to consider policies specific to pipeline creation and execution, along with admissions policies that a kube-api server might otherwise rely on OPA for.

With OPA, we define allow/deny rules that can be applied to requests (CRUD operations, conditional approvals, etc.). These rules are evaluated within the context of those requests. When used with K8s, we insert OPA as an Admission Controller. The kube-api server checks with OPA before executing any CRUD requests that pass an RBAC privilege check.

For example, a principal might have RBAC privileges to create a pod, but we need to ensure the request only pulls images from a trusted registry. With OPA, we can define the list of allowed registries. The kube-api server checks the request against RBAC and then passes it to OPA. Then, OPA parses the registry/image value and returns either allow or deny based on defined policies.

One model I’ve recently begun contemplating is applying policy at the K8s cluster level to effectively deny all requests unless they originate from a CD pipeline. From the pipeline, we can manage the K8s admission policy.

This can be applied across all target clusters, preventing any direct interaction with resources via the kube-api server while enforcing consistent policy from a single policy set definition. Essentially, you can have a single (non-replicated) policy for potentially thousands of K8s clusters that is immediately consistent. Using CD and K8s RBAC, we can restrict privileges to only update the OPA rules via the same CD platform pattern. The end result is an entirely auditable and secure single-source for all K8s cluster policies.

Recently Published Posts

Welcoming 2022: Reflecting and looking forward

Dec 22, 2021
|
by Jim Douglas

Nearly all cultures globally have some form of celebration marking the Winter Solstice. Common threads found in most observances of the annual event are celebration of family and friends (living and past), reflection of the past year, and some form of giving thanks for continued health and sustenance. Exiting 2021, said celebrations would seem especially […]

Read more

Resiliency and Load distribution

Dec 16, 2021
|
by Daniel Gonzalez

Introduction When scaling a network service, there are always two concerns: resiliency and load distribution, to understand these concepts let us first understand the broader term “Redundancy”. Redundancy is the duplication of a component to increase reliability of the system, usually in the form of a backup, fail-safe, or to improve actual system performance. Resiliency […]

Read more

CVE-2021-44228 – log4j (Log4Shell) – an analysis

Dec 10, 2021
|
by Jason McIntosh

Today marked a 0-day disclosure of a rather nasty vulnerability in one of the most commonly used frameworks for logging – log4j.  This one is nasty on multiple levels.  Note that Armory Enterprise is NOT affected by this vulnerability.  The impact on this vulnerability is likely huge and is already being exploited.  Additionally it can […]

Read more