Deploy Anywhere using the OpsMx Enterprise for Spinnaker Anywhere Agent

Enterprise’s adoption of containers has become mainstream, and Kubernetes is the default container management platform of choice across enterprises. 

Spinnaker is now the leading multi-cloud, flexible continuous delivery tool of choice, and it is increasingly being used to automate Kubernetes applications deployments.

However, Spinnaker’s default configuration does not support deployments into a different security domain. This limitation becomes a problem in the following cases.

• Deploy applications in an on-prem environment from a Spinnaker environment in the cloud
  When organizations run Spinnaker in the cloud (for example, when choosing OpsMx Spinnaker-as-a-Service for ease of Spinnaker management), deploying to targets in their on-prem data center is an issue. 

• Spinnaker as a shared service
  Spinnaker as a shared service is a common configuration but has some issues when there are  multiple security domains.

• • When a central Spinnaker instance is used to deploy applications for multiple teams, deploying into the different teams’ security domains is an issue.  

• • When a new environment is created (for example, a new Kubernetes cluster), the environment credentials must be shared with the central instance, and this is an issue for some organizations. 

• • Some organizations require that administrators of a Kubernetes cluster maintain control of the credentials allowing access to the cluster. The default approach is to grant access to the cluster for Spinnaker; this makes it difficult for the cluster administrator to control the credentials. 

• Deploying across multiple security domains
  When a single team has responsibility for deploying applications or services in multiple security domains (for example, if an application or service is deployed across multiple geographic areas, or if a team has an on-prem application that bursts to the cloud), deploying to multiple security domains is an issue. 

These situations are common in advanced organizations, where security is critical, and when the organization intends to use Spinnaker at scale. 

OpsMx Enterprise for Spinnaker (OES) addresses these challenges through the use of the OpsMx Enterprise for Spinnaker Anywhere agent. This enables the simple adoption of Spinnaker with the knowledge that the deployment will be successful even as it grows across the organization.

Challenges with Deploying to Kubernetes with Spinnaker

In a typical enterprise, each development group has one or more Kubernetes clusters to deploy their applications. Spinnaker is installed in a shared services cluster with full access to those target Kubernetes clusters. Spinnaker uses privileged access to deploy applications and retrieve the deployed application status, and to perform scale-up/down or rollback functions.

In the cases described above, there is a need for the Spinnaker to connect to a Kubernetes cluster from a different security domain. Typical security policies prevent externally initiated connections. This means that Spinnaker can not communicate with the Kubernetes clusters in a separate security domain.

The below figures depict the above scenarios.

Kubernetes Deployment Options with Spinnaker

In the situation on the left, with Spinnaker and the Kubernetes cluster in the same zone, everything is fine. However, in the situation on the right, with Spinnaker and the Kubernetes cluster in different zones, communication fails and so Spinnaker is ineffective. 

Another big security challenge with the current Spinnaker support of Kubernetes is that Spinnaker needs the credentials for access to each of the Kubernetes clusters where it deploys applications. The Kubernetes cluster admins can’t easily revoke these credentials.

OpsMx Enterprise for Spinnaker Anywhere Agent

To address these challenges, OpsMx has created the OpsMx Enterprise for Spinnaker Anywhere agent. 

OES Anywhere agents are deployed in target Kubernetes clusters, and they establish a secure connection to the  Spinnaker services in the separate security domain. Each target Kubernetes cluster dynamically self-registers with the Spinnaker services, creating an out-bound connection to Spinnaker that satisfies security requirements. 

Benefits of the solution include:

• Allows Spinnaker to deploy to Kubernetes wherever it might be – in a private VPC or private cloud.
• Allows adoption of Spinnaker-as-a-Service using the OpsMx Cloud.
• Eliminates the need for configuring Spinnaker with the credentials for each of the target Kubernetes clusters. The administrator of each Kubernetes cluster retains control over the credentials and can remove permissions independently if needed. 
• Because the target Kubernetes cluster dynamically self-registers with the Spinnaker services, there is no need to restart Spinnaker when adding a new  Kubernetes cluster.

The below figure illustrates the possible deployment options of Spinnaker and Kubernetes clusters.

Kubernetes Anywhere Solution for Spinnaker

If you have a situation where you are considering using Spinnaker to deploy across multiple security zones, please contact us. OpxMx Enterprise for Spinnaker is deployed in some of the most security-conscious organizations in the world, and we would be happy to share our expertise. 

Additionally, if you would like to use OpsMx Spinnaker-as-a-Service, which means that OpsMx will completely simplify the operation of your continuous delivery platform, let us know and we will be happy to help you deploy to all your target environments.