Pipeline Policies With Spinnaker

May 29, 2019 by Isaac Mosquera

A pattern we’ve noticed working with large enterprises and Spinnaker is that compliance & security is a critical concern to on-boarding applications and developers. For these customers to on-board applications onto Spinnaker they must have security and compliance enforcement across their pipelines. There is an opportunity to solve this as a part of Spinnaker.

Customer problem

Spinnaker gives developers and users a great deal of control across their software delivery pipeline and infrastructure for their apps.  While there is a strong desire to achieve service-ownership it is challenging to hand over full control until there are compliance guarantees in place.  This causes bottlenecks in adoption because any changes to Spinnaker such as adding applications & pipelines must go through a central team.  Below are some of the use-cases covered in our initial customer discovery:

  • Conform to best practices by requiring certain stages and attributes (ex: security stage is required or certain namespace) (demo below)
  • Enforce certain thresholds within stages  (ex: failure rate of QA test stage cannot exceed x)
  • Validate a Terraform HCL or plan file against defined policy
  • Blacklist or Whitelist of accounts/targets/infra that a user can target
  • RBAC, Authz
  • Must include a particular pipelines as code module
  • Service Roles for services like Igor so that it can only fetch the appropriate credentials.
  • Avoid exposing unprotected resources (ex: s3) as a part of software delivery
  • Best practice policies to apply to software delivery to achieve Fedramp, ISO2700, SOX, PCI compliance
  • Globally applicable policy for a definition of done for all pipelines

Demo & Solution

Our solution relies on OPA, the policy agent used for the Admission Controller in Kubernetes.  This allows for defining arbitrary policies against the pipeline JSON in Spinnaker and, in the future, against its execution context.  The demo below focuses on our first use case:

Conform to best practices by requiring certain stages and attributes

If you’re interested in testing this policy engine with us or have feedback please reach out: https://www.armory.io/contact-us/

Recently Published Posts

A Faster Way to Evaluate Self-Hosted Continuous Deployment from Armory

Sep 30, 2022

Introducing Quick Spin One of the most common challenges that organizations face when implementing a continuous deployment strategy is the time and focus that it takes to set up the tools and processes. But a secure, flexible, resilient and scalable solution is available right now. Want to see if it’s the right tool for your […]

Read more

3 Common Spinnaker Challenges (and Easy Ways to Solve Them)

Sep 27, 2022

Spinnaker is the most powerful continuous delivery tool on the market.  DevOps engineers and developers recognize this power and are looking to use Spinnaker as a foundational tool in their Continuous Integration and Continuous Delivery (CI/CD) process for hybrid and multi-cloud deployments. Such a powerful, expansive open source tool needs expertise within your organization to […]

Read more

Streamline Advanced Kubernetes Deployments from GitHub Actions with New Armory Service

Sep 23, 2022

Today, Armory is excited to announce the availability of the GitHub Action for Armory Continuous Deployment-as-a-Service. GitHub is where developers shape the future of software. After a developer writes and tests their code in GitHub, it must be deployed. Armory’s GitHub Action for Continuous Deployment-as-a-Service extends the best-in-class deployment capabilities to Kubernetes. CD-as-a-Service enables declarative […]

Read more