OpsMx has released  OpsMx Enterprise Spinnaker (OES)  2.10.  Following are the key feature addition of these releases are:

  • Policy Management– to help customers enforce policies into their software deployments with easy and simple steps.
  • Audit Enhancements: It also brings more visibility into policy compliance, which is a major enhancement to the Audit feature.
  • Simplified Account Management: Highlights also include a new way of Account Management that provides customers the ability to create new (cloud) accounts in Spinnaker for use without disrupting the already executing deployments.

Below is a description of these features:

1. Policy Management for Spinnaker

DevOps teams are responsible for the rapid delivery of software, and simultaneously ensuring the software is reliable and risk-free. They have to use policy and governance controls to achieve safety. In many cases, the policy is a piece of document which provides guidance for deployment. It is arduous to enforce or record if the deployments are done in a certain way. In some cases, policy or compliance managers enforce policies at the end of the deployment process; well at this point, the cost of an issue becomes exponentially high. The policy management feature of OES 2.10 allows the security and compliance team to automatically express policy (in a declarative language) that can promote safe and fine-grained controls on the Spinnaker deployment pipeline (refer to Fig 1A). They will have the flexibility to declare policies – policies (e.g. Automated Testing should be completed before deployment)  that must be adhered to when creating a Spinnaker pipeline and policies (such as specifying deployment day or window) that must be adhered to while executing a Spinnaker pipeline. Policies are validated, in the runtime, through 3rd party policy engines ( like Open Policy Agent) using REST API. Moreover, security managers get the flexibility to quickly add, modify, delete policies in tune with business policy changes.

OES Policy Management page

OES Policy Management page

Fig 1A: OES Policy Management page where compliance managers can quickly declare policies and integrate with 3rd party policy managers for validations.

Example of dynamic policy that can be easily enforced while creating pipelines in Spinnaker

Example of dynamic policy that can be easily enforced while creating pipelines in Spinnaker

Fig 1B: Example of dynamic policy that can be easily enforced while creating pipelines in Spinnaker


  1. Automated checks during the software deployment process as per policy guidelines                  
  2. Exponentially increase your compliance in software delivery                  
  3. Decrease duress by avoiding managers to hop among tools and documents, with centralized enforcement of policies during software delivery

2. Audit for Spinnaker – advanced filtering

Examples of finding Spinnaker pipeline configuration and pipeline execution in an environment using Audit filters

Fig 2A: Examples of finding Spinnaker pipeline configuration and pipeline execution in an environment using Audit filters

Every company needs to comply with policies and standards like HIPAA and SOX. Auditors are responsible to find if the organizations are compliant through evidence gathered while taking code from build to release. However, there are fewer flexibilities or options for an auditor to find relevant data for auditing. They have to collaborate with multiple stakeholders, download data from different systems, gather suitable data in one place, and provide different filters to arrive at a conclusion. Even if they can easily assemble all the interlocking pieces- people, processes, and technology, it would take them taxing hours to just know about pipeline configurations and executions. OES 2.10 acts as a single source of truth for finding pipeline information by integrating with various sources- Spinnaker, Autopilot, and policy enforcement. First of all, in the Security/Audit screen, an auditor will find the total number of pipelines used by Spinnaker for various software delivery along with the date of creation. Secondly, in the pipeline execution screen auditors will have the option to find the list of pipelines that are executed in a given time interval along with their status. A user will have the option to use filters and quickly find out answers to queries such as who are users responsible for executing failed pipelines, or what is the total number of pipelines that were responsible for deploying business-critical applications are terminated in the recent quarter, or If any deployments happened into Kubernetes clusters during peak business hours, etc.

Examples of using custom Audit filters

Fig 2B: Examples of using custom Audit filters


  1. A one-stop-shop solution to look at auditable events and filter them down to specific conditions
  2. Reduce time to fetch deployment information from hours to seconds with real-time visibility
  3. Faster time to identify non-compliant activities and send for investigation

3. Simplifying Account Management for Spinnaker

There are situations when the infrastructure or admin team has to create a new cloud provider account in Spinnaker during run-time, say, a new Kubernetes cluster during the pipeline deployment or before the pipeline deployment. Typically they have to modify yaml files and deploy those changes using ‘hal deploy apply’. And to initiate those changes, Spinnaker has to be restarted, which will fail all your pipelines in execution. This will negatively impact releases planned for encashing new business opportunities. Instead of saving the files in Spinnaker’s local filesystem, OES Account Management offers an easy way to create and save account information and configuration files in remote locations ( or Data Sources) such as GitHub, Hashicorp Vault, JDBC, CredHub in less than a minute. Without restarting its services, Spinnaker will automatically identify accounts from these external repositories. One needs to mention details (refer Fig3A) of Data Sources, account name, cloud driver, groups that need to have read/write/execute permissions, and config file in Account Management. A YAML file will automatically be created in the data source, which Spinnaker can dynamically fetch for deployment. 

Screenshots represent the data sources available out-of-the-box.

Fig 3A: Screenshots represent the data sources available out-of-the-box.

Screenshot represents easy steps to add a dynamic account in less than 60 seconds.

Fig 3B: Screenshot represents easy steps to add a dynamic account in less than 60 seconds.


  1. Add, update or delete Kubernetes accounts in Spinnaker without the need for restarting Spinnaker
  2. Easy to integrate with your already invested 3rd party external repositories like GitHub, Vault, CredHub, etc.

If you want to know more about the features in this release or request a demonstration, please book a meeting with us

OpsMx is a leading provider of Continuous Delivery solutions that help enterprises safely deliver software at scale and without any human intervention. We help engineering teams take the risk and manual effort out of releasing innovations at the speed of modern business. For additional information, contact us


Submit a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.