DainQ

Introduction

Container-based applications have revolutionised software deployment, allowing organisations to break down monolithic applications into manageable units for improved development and deployment cycles. However, as organisations leverage containers, ensuring the security and integrity of the software supply chain becomes a pressing concern. 

In the ever-evolving landscape of cloud-native / container-based applications and microservices, where agility and scalability are key, security should never be compromised. Kubernetes has also emerged as a powerful tool for managing containerized workloads. However, with the increased adoption of Kubernetes, security concerns have also risen to the forefront. One critical aspect of ensuring the security of Kubernetes clusters is having control over the container images that are deployed within them. This is where Binary Authorization comes into play. 

In this blog post, we’ll explore the concept of Binary Authorization, its significance, and how it works within the Kubernetes ecosystem. We’ll also look at the implementation steps and required roles on a very high level to set it up effectively.

Understanding the Need for Binary Authorization

Container Provenance and Security Concerns

Container images are at the heart of Kubernetes workloads. Each pod in a Kubernetes cluster runs one or more containers, and these containers are derived from container images. Ensuring the security and integrity of these container images is paramount. Organisations need to know where these images originate, whether they’ve been tampered with, and whether they adhere to the desired security policies. 

Some of the key concerns in a containerised environment:

• Safe Origin: How can you ensure that all container images running in the cluster come from approved and trusted sources?
• Consistency and Validation: How do you guarantee that all necessary validation steps were successfully completed for each container build and deployment?
• Integrity: How can you be certain that container images haven’t been modified after their provenance was established?

Potential Risk:

From a security standpoint, not enforcing where images originate from presents several risks:

• A malicious actor that has compromised a container may be able to obtain sufficient cluster privileges to launch other containers from an unknown source without enforcement.
• An authorised user with the permissions to create pods may be able to accidentally or maliciously run an undesired container directly inside a cluster.
• An authorised user may accidentally or maliciously overwrite an image tag with a functional container that has undesired code silently added to it, and Kubernetes will pull and deploy that container as a part of a deployment automatically.

Introducing Binary Authorization

To address these security concerns and provide a robust mechanism for enforcing policies on container images, Google Cloud offers a powerful solution called Binary Authorization. Binary Authorization is a managed service that works seamlessly with Google Kubernetes Engine (GKE) to establish deploy-time security controls, ensuring that only trusted container images are deployed. It does this by enforcing a policy that defines which images are allowed to run. The policy can be based on a variety of factors, such as the image’s source, its signing status, and its vulnerability status.

The primary goal of Binary Authorization is to ensure that only authorised and verified container images are deployed within the cluster. This involves setting up policies that require one or more trusted parties, known as “attestors,” to approve an image before it can be deployed. This mechanism is particularly useful in multi-stage deployment pipelines, where images progress from development to testing to production clusters.

Below are some of the Binary Authorization features that enhance container security:

• Container Registry Allowlisting: Organisations can define approved container registries, ensuring that only images from trusted sources are integrated into the build and release process.
• Policy Model: Describe deployment constraints for images through a policy model. Define criteria such as vulnerability scans, compliance checks, or successful testing.
• Central Policy Enforcement: Policies can be centrally managed and enforced, providing a unified approach to security across the entire Kubernetes environment.
• Attestation Model: Establish trusted authorities (attestors) who verify that required processes were executed before deployment. This cryptographic verification adds an additional layer of trust confirming the authenticity of the image and its source..
• Deploy-Time Enforcer: The Binary Authorization service acts as a gatekeeper, preventing images that violate policy rules from being deployed. This ensures that only secure and approved images make it into production.

The Container Build Pipeline and Lifecycle

In a typical container build pipeline, the steps involved are:

• Source Code Management: The source code for creating the container is stored in a version control system.
• Build and Test: Upon committing changes, the container is built and tested, ensuring its correctness.
• Container Registry: If the build and test steps are successful, the container image artifact is placed in a central container registry.
• Deployment: When a deployment of that container version is submitted to the Kubernetes API, the container runtime pulls the image from the registry and runs it as a pod.

To grasp the significance of Binary Authorization, let’s consider a typical deployment lifecycle for container images. This lifecycle consists of several stages, each building upon the previous one:

• Build and Unit Testing: The initial stage involves building the container image and performing unit testing to ensure its functionality.
• Development Environment: Images move to a development environment where internal users can test without affecting external users.
• QA Environment: The next stage includes deployment into a quality assurance environment, further testing the image with internal users.
• Canary Environment: Images are deployed to a small fraction of external users in a canary environment to assess real-world performance.
• Production: Finally, images are deployed to the production environment for widespread use.

How Binary Authorization Works

Binary Authorization builds upon the foundation of open-source projects Grafeas and Kritis. Grafeas defines an API specification for managing metadata about software resources, while Kritis defines an API for ensuring deployments adhere to central policy.

Binary Authorization allows organisations to set rules that determine when an image can progress from one stage to another. Each stage can have specific criteria and deployment environments. For example, Google Kubernetes Engine (GKE), Cloud Run, Anthos Service Mesh, and Anthos clusters are supported platforms.

At each stage, Binary Authorization enforces the defined rules and criteria before allowing image deployment to the next stage. It works by intercepting all requests to deploy container images to a Kubernetes cluster. The request is then evaluated against the policy. If the image is allowed to run, the request is allowed to proceed. If the image is not allowed to run, the request is denied.

Binary Authorization can be used to implement a variety of security policies. For example:

• Only allow images that are signed by a trusted authority.
• Only allow images that have been scanned for vulnerabilities.
• Only allow images that are from a specific source, such as a private container registry.

Here is an example of how Binary Authorization can be implemented in a real-world scenario. Let’s say you are a company that develops and deploys container-based applications. You want to ensure that only trusted images are deployed to your Kubernetes clusters. You can use Binary Authorization to do this by creating a policy that only allows images that are signed by your company’s internal signing authority. This will help to prevent the deployment of images that have been tampered with or that contain malicious code.

Attestation, Policy Enforcement and Required Roles

Binary Authorization enhances the deployment pipeline by introducing opportunities for attestation at various stages. Attestation involves signing metadata about each step in the process. Different entities, such as humans or systems, can perform these attestations. Each attestation is associated with a PGP key and stored as a “note occurrence” in the Container Analysis API.

During deployment, the Kubernetes Admission Controller sends a webhook to the Binary Authorization API for policy decisions. The policy, along with necessary attestation occurrences, is consulted. If the image conforms to the policy, it’s allowed to run; otherwise, it’s denied.

The Different Roles of Attestors in Binary Authorization

Attestors are individuals, teams, or processes responsible for verifying the readiness of an image for deployment. They are integral in the chain of trust within your deployment pipeline. Each attestation is established and validated using cryptographic public and private keys. This cryptographic verification ensures that only trusted parties can authorise the deployment of software in your environment.

• Deployer: This role is responsible for running code on the GKE cluster. Their main focus is on deploying applications, not on the specifics of security policies.
• Policy Creator: The Policy Creator defines high-level security policies for the organisation. They outline rules and criteria that must be satisfied before a container can run. They determine who needs to approve an image before it’s considered safe.
• Attestor: Attestors are individuals or processes responsible for enforcing specific aspects of the policy. They possess cryptographic keys and sign images that pass their approval process.

Implementation Steps:

Implementing Binary Authorization involves a few crucial steps:

• Enable the Service: Activate Binary Authorization for your Google Cloud projects that encompass your deployment pipeline.
  • gcloud container binauthz policy enable
• Define Deployment Policy: Policy Creators play a crucial role in crafting a policy that outlines the constraints under which container images can be deployed. This policy dictates the criteria images must meet at each stage.
  • Either the Google Cloud Console or the gcloud command-line tool can be used. 
  • The policy file is a YAML file that defines the rules for which images are allowed to run.
• Set Up Attestors (if required): Attestors are pivotal to the trust chain in Binary Authorization. If your policy mandates attestations before deployment, establish attestors—trusted authorities that verify required processes were completed before allowing images to deploy. They are created using the Container Analysis API and tied to cryptographic keys. These keys are used to sign images that pass attestation. The process involves
  • Creating a Container Analysis Note, 
  • Registering the Attestor in Binary Authorization, 
  • Configuring IAM roles to grant access to the Note.
• Signing and Verifying Container Images: Attestors, acting as trusted authorities, sign container images to indicate their approval. This is done using cryptographic keys stored in Google Cloud Key Management Service (KMS). The signed attestation is associated with the container image’s digest.
• Policy Deployment: Finally, the deployer now deploys the updated policy, which includes requirements for attestation from specific attestors, and is enforced by Binary Authorization. Only images that have been signed by approved attestors will be allowed to run in the GKE cluster.
  • use the kubectl apply command

Conclusion: Strengthening Kubernetes Security

In a world where cyber threats loom large, securing container-based applications demands a proactive approach. As the adoption of container-based applications continues to surge, Binary Authorization plays a pivotal role in building a resilient security foundation. By implementing Binary Authorization, organisations can confidently embrace the advantages of containerization without compromising on security. 

Binary Authorization emerges as a powerful tool to address the security challenges posed by containerized environments in Kubernetes. By ensuring only trusted and verified container images are deployed, organisations can significantly mitigate the risks associated with unauthorised or compromised containers. The ability to enforce policies, allowlist container registries, and require image signing empowers Kubernetes administrators with greater control and visibility into their container environment.

However, it’s important to note that while Binary Authorization provides a robust layer of security, it’s just one piece of the larger security puzzle. A comprehensive security strategy should encompass other best practices such as pod security policies, network policies, and regular vulnerability assessments.

As Kubernetes continues to play a central role in modern application deployment, solutions like Binary Authorization become indispensable for maintaining the integrity and security of container workloads. By embracing these tools, organisations can confidently harness the power of Kubernetes without compromising on security.

Additional Resources

• Gating Deployments with Binary Auth
• Securing Your GKE Deployments with Binary Authorization

Disclaimer

This blog post is my opinion on a high-level overview of Binary Authorisation in a GKE environment. Readers are encouraged to explore the official GCP documentation and additional resources for more in-depth information. Feel free to leave comments with your opinion on how elsse we can use Binary Authorisation in a GKE Environment.

I am always happy to help and provide any guidance if you need. Feel free to connect with or follow me on LinkedIn or Twitter.

Goo(gle)d Luck!!!