Armory Docs – Armory Continuous Deployment

Continuous-Deployment: Cloud Foundry as a Deployment Target in Spinnaker

Mon, 01 Jan 0001 00:00:00 +0000

How Spinnaker interacts with Cloud Foundry

Spinnaker - Cloud Foundry Deployment Design

Spinnaker has caching agents for Cloud Foundry Server Groups, Load Balancers, and Spaces. In order to perform caching and operations, these caching agents communicate directly with the Cloud Foundry Cloud Controller via its REST API. The caching agents run on a specific interval, typically every 30 seconds. You can read more about caching agents in the Clouddriver Caching Agents in Spinnaker guide.

Cloud Foundry as a deployment target

Cloud Foundry administrators should configure the minimal amount of permissions required by Spinnaker to successfully function. This typically means the Cloud Foundry account has Space Developer permissions for at least one organization/space. In some cases, it may make sense to have one account for the entire Foundation, but this configuration isn’t normal or desired for security reasons.

Spinnaker administrators can configure one or more Cloud Foundry accounts as cloud providers.

Spinnaker users can use a Cloud Foundry account as a deployment target. Users can perform Cloud Foundry operations by using the Cloud Foundry stages in their pipelines.

What’s next

Continuous-Deployment: Install Operator and Deploy Armory Continuous Deployment Quickstart

Mon, 01 Jan 0001 00:00:00 +0000

This guide is for both the Armory Operator and the Spinnaker Operator. Armory Continuous Deployment and Spinnaker configuration is the same except for features only in Armory Continuous Deployment. Those features are marked .

Before you begin

The goal of this guide is to deploy Armory Continuous Deployment with bare minimum configuration. The What’s next section contains links to advanced configuration guides.

You are familiar with Kubernetes Operators, which use custom resources to manage applications and their components.
You understand the concept of managing Kubernetes resources using manifests.
You have reviewed and met the Armory Continuous Deployment system requirements.

If you are using Armory Continuous Deployment, be sure to choose the Armory Operator version that is compatible with your Armory CD and Kubernetes versions. Likewise, if you are using open source Spinnaker, choose the Spinnaker Operator that is compatible with your Spinnaker and Kubernetes versions.

Kubernetes Version	Armory Operator Version	Armory CD Version
< 1.21	<= 1.6.x	<= 2.28.0
>= 1.21	>= 1.7.x	All supported versions

Kubernetes Version	Spinnaker Operator Version	Spinnaker Version
< 1.21	<= 1.2.5	>= 1.27.3
>= 1.21	>= 1.3.x	>= 1.27.3

Consult the Manage Operator guide for how to upgrade your Operator version.

Depending on your Kubernetes version, you may need to adjust the following instructions to use a supported Operator version.

Operator installation options

The Operator has basic and cluster installation modes. The option you use depends on which namespace you want to deploy Armory Continuous Deployment or open source Spinnaker to.

Most users choose Cluster Mode.

	Basic Mode	Cluster Mode
Must deploy Armory Continuous Deployment or open source Spinnaker in the same namespace as the Operator; permissions scoped to single namespace; suitable for a Proof of Concept (POC)	✅	❌
Can deploy Armory Continuous Deployment or open source Spinnaker to multiple namespaces (requires Kubernetes ClusterRole)	❌	✅
Configure Armory Continuous Deployment or open source Spinnaker using a single manifest file	✅	✅
Configure Armory Continuous Deployment or open source Spinnaker using Kustomize patches	✅	✅
Perform pre-flight checks to prevent misconfiguration	❌	✅

Install the Operator

You need Kubernetes ClusterRole authority to install the Operator in cluster mode. You should use Cluster mode to do one of the following:

Install a single Spinnaker Operator to manage an entire Kubernetes cluster of Spinnaker installations
Install a single Armory Operator to manage an entire Kubernetes cluster of Armory CD installations

You can find the Operator’s deployment configuration in spinnaker-operator/deploy/operator/cluster after you download and unpack the archive. You don’t need to update any configuration values.

Get the latest Operator release:

Armory Operator for Armory CD Installation

mkdir -p spinnaker-operator && cd spinnaker-operator
bash -c 'curl -L https://github.com/armory-io/spinnaker-operator/releases/latest/download/manifests.tgz | tar -xz'

Spinnaker Operator for Open Source Spinnaker Installation

mkdir -p spinnaker-operator && cd spinnaker-operator
bash -c 'curl -L https://github.com/armory/spinnaker-operator/releases/latest/download/manifests.tgz | tar -xz'

Install or update CRDs across the cluster:
```
kubectl apply -f deploy/crds/
```
Create the namespace for the Operator:

In cluster mode, if you want to use a namespace other than spinnaker-operator, you need to edit the namespace in deploy/operator/cluster/role_binding.yaml.
```
kubectl create ns spinnaker-operator
```

Install the Operator:

kubectl -n spinnaker-operator apply -f deploy/operator/cluster

Verify that the Operator is running:

kubectl -n spinnaker-operator get pods

The command returns output similar to the following if the pod for the Operator is running:

NAMESPACE READY STATUS RESTARTS AGE
spinnaker-operator-7cd659654b-4vktl 2/2 Running 0 6s

Operator in basic mode has permissions scoped to a single namespace, so the Operator can’t see anything in other namespaces. You must deploy Armory Continuous Deployment or open source Spinnaker to the same namespace as the Operator, in a 1:1 correlation (one Armory Operator per Armory CD; one Spinnaker Operator per open source Spinnaker install).

You can find the Operator’s deployment configuration in spinnaker-operator/deploy/operator/basic after you download and unpack the archive. You don’t need to update any configuration values.

Get the latest Operator release:

Armory Operator for Armory CD Installation

mkdir -p spinnaker-operator && cd spinnaker-operator
bash -c 'curl -L https://github.com/armory-io/spinnaker-operator/releases/latest/download/manifests.tgz | tar -xz'

Spinnaker Operator for Open Source Spinnaker Installation

mkdir -p spinnaker-operator && cd spinnaker-operator
bash -c 'curl -L https://github.com/armory/spinnaker-operator/releases/latest/download/manifests.tgz | tar -xz'

Install or update CRDs across the cluster:
```
kubectl apply -f deploy/crds/
```
Create the namespace for the Operator:

In basic mode, the namespace must be spinnaker-operator.
```
kubectl create ns spinnaker-operator
```

Install the Operator:

kubectl -n spinnaker-operator apply -f deploy/operator/basic

Verify that the Operator is running:

kubectl -n spinnaker-operator get pods

The command returns output similar to the following if the pod for the Operator is running:

NAMESPACE READY STATUS RESTARTS AGE
spinnaker-operator-7cd659654b-4vktl 2/2 Running 0 6s

Deploy an Armory Continuous Deployment instance

Single manifest file option

You can find the SpinnakerService.yml manifest file in /spinnaker-operator/deploy/spinnaker/basic/. You need to specify persistent storage details and the version to deploy before you can use the manifest to deploy Armory Continuous Deployment.

The following example uses an AWS S3 bucket. You can find configuration for other storage types in the Persistent Storage reference.

You can see the list of Armory Continuous Deployment versions on the Release Notes page.

apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 spinnakerConfig:
 config:
 version: <version> # the version of Armory Continuous Deployment to deploy
 persistentStorage:
 persistentStoreType: s3
 s3:
 bucket: <change-me> # Armory Continuous Deployment stores application and pipeline definitions here. Create an S3 bucket and provide the name here.
 rootFolder: front50
 # spec.expose - This section defines how Armory Continuous Deployment should be publicly exposed
 expose:
 type: service # Kubernetes LoadBalancer type (service/ingress), note: only "service" is supported for now
 service:
 type: LoadBalancer

The Armory Operator contains Halyard to manage a portion of your Armory Continuous Deployment installation. See Advanced Operator Configuration if you need to override the default settings for the Halyard container for some advanced features.

Deploy using kubectl:

kubectl create ns spinnaker
kubectl -n spinnaker apply -f deploy/spinnaker/basic/SpinnakerService.yml

You can find the basic spinnakerservice.yml manifest file in /spinnaker-operator/deploy/spinnaker/basic/.

You need to specify persistent storage details and the version to deploy before you can use the manifest to deploy Spinnaker. The following example uses an AWS S3 bucket. You can find configuration for other storage types in the Persistent Storage reference.

You can see the list of Spinnaker versions on the Spinnaker Versions page.

apiVersion: spinnaker.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 spinnakerConfig:
 config:
 version: <version> # the version of Spinnaker to deploy
 persistentStorage:
 persistentStoreType: s3
 s3:
 bucket: <change-me> # Spinnaker stores application and pipeline definitions here. Create an S3 bucket and provide the name here.
 rootFolder: front50
 # spec.expose - This section defines how Spinnaker should be publicly exposed
 expose:
 type: service # Kubernetes LoadBalancer type (service/ingress), note: only "service" is supported for now
 service:
 type: LoadBalancer

Deploy using kubectl:

kubectl create ns spinnaker
kubectl -n spinnaker apply -f deploy/spinnaker/basic/spinnakerservice.yml

You can watch the installation progress by executing:

kubectl -n spinnaker get spinsvc spinnaker -w

You can verify pod status by executing:

 kubectl -n spinnaker get pods

The included manifest file is only for a very basic installation. Configure Armory Continuous Deployment Using a Manifest File contains detailed manifest configuration options.

Kustomize patches option

This example assumes you deploy Armory Continuous Deployment to the spinnaker-operator namespace.

Kustomize uses patch files to build a deployment file by overwriting sections of the spinnakerservice.yml manifest file. You declare your patch files in a kustomization.yml file, which kubectl and Kustomize and use to build the Armory Continuous Deployment or Spinnaker manifest file.

You can put each manifest config section in its own file. For example, if you create a profiles-patch.yml patch with configuration for various services, you are telling Kustomize to overwrite the profiles section of the spinnakerservice.yml manifest with the contents of profiles-patch.yml. Kustomize is flexible, though, so you could instead create a separate patch file for each service (profiles-clouddriver-patch.yml, profiles-gate-patch.yml, profiles-deck-patch.yml, etc.), and then declare those patches in the kustomization.yml file.

Kustomize is part of kubectl, so you do not need to install Kustomize locally to build and verify your manifest file. You can run kubectl kustomize <path-to-kustomization.yml>. This prints out the contents of the manifest file that Kustomize builds using your kustomization.yml file.

kubectl versions up to and including v1.20 come bundled with Kustomize v2.0.3. kubectl 1.21 comes bundled with Kustomize v4.0.5. Using Kustomize patches has been tested with kubectl v1.19.x. and standalone Kustomize v2 and v3. You may see a panic error if you use the spinnaker-kustomize-patches repo with Kustomize v4.0+ or kubectl v1.21+.

For this quickstart, you can find bare minimum patches in /spinnaker-operator/deploy/spinnaker/kustomize. Before you deploy Armory Continuous Deployment, you need to update the version and persistentStorage values in config-patch.yml.

The following example uses an AWS S3 bucket. You can find configuration for other storage types in the Persistent Storage reference.

This quickstart example is suitable for a proof of concept. For production environments, you should use a robust set of Kustomize patches. See the Configure Armory Continuous Deployment Using Kustomize guide for details.

You can see the list of Armory Continuous Deployment versions on the Release Notes page.

apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 # spec.spinnakerConfig - This section is how to specify configuration spinnaker
 spinnakerConfig:
 # spec.spinnakerConfig.config - This section contains the contents of a deployment found in a halconfig .deploymentConfigurations[0]
 config:
 version: <version> # the version of Armory Continuous Deployment to be deployed
 persistentStorage:
 persistentStoreType: s3
 s3:
 bucket: mybucket
 rootFolder: front50

The Armory Operator contains Halyard to manage a portion of the deployment Armory Continuous Deployment. See Advanced Operator Configuration if you need to override the default settings for the Halyard Container for some advanced features.

You can see the list of open source Spinnaker versions on the Spinnaker website’s Versions page.

apiVersion: spinnaker.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 # spec.spinnakerConfig - This section is how to specify configuration Spinnaker
 spinnakerConfig:
 # spec.spinnakerConfig.config - This section contains the contents of a deployment found in a halconfig .deploymentConfigurations[0]
 config:
 version: <version> # the version of Spinnaker to be deployed
 persistentStorage:
 persistentStoreType: s3
 s3:
 bucket: mybucket
 rootFolder: front50

If you want to verify the contents of the manifest file, execute from the /spinnaker-operator/deploy/spinnaker/kustomize/ directory:
```
kubectl kustomize .
```
This prints out the contents of the manifest file that Kustomize built based on your kustomization.yml file.
Deploy from the /spinnaker-operator/deploy/spinnaker/kustomize/ directory:
```
kubectl create ns spinnaker
kubectl -n spinnaker apply -k .
```
You can watch the installation progress by executing:
```
kubectl -n spinnaker get spinsvc spinnaker -w
```
You can verify pod status by executing:
```
kubectl -n spinnaker get pods
```

Help resources

Armory Operator and Armory Continuous Deployment: contact Armory Support or use the Spinnaker Slack #armory channel.
Spinnaker Operator and Spinnaker: Spinnaker Slack #kubernetes-operator channel.

What’s next

Register your Armory Continuous Deployment instance.
Learn how to Manage Armory Continuous Deployment using the Operator.
See advanced manifest configuration in the Configure Armory Continuous Deployment Using a Manifest File guide.
See advanced configuration using Kustomize in the Configure Armory Continuous Deployment Using Kustomize guide.
See the Errors and Troubleshooting guide if you encounter issues.
If you are deploying Armory Continuous Deployment, you may need to override the default settings for the Halyard container for some advanced features. See the Advanced Operator Configuration guide.
Learn how to Manage Operator.

Continuous-Deployment: System Requirements for Armory Continuous Deployment

Mon, 01 Jan 0001 00:00:00 +0000

The requirements described on this page are meant as a minimum starting point for installing Armory Continuous Deployment. You may need to increase the resources based on the number of applications, pipelines, and executions. Work with your IT organization to make sure that the requirements are met.

Installation targets

This section defines where you can run Armory Continuous Deployment, not where you can deploy your applications. For information about where you can deploy applications to, see the Product Compatibility Matrix.

Armory Continuous Deployment can be installed on any certified Kubernetes cluster that meets the following version requirements:

Minimum version: 1.20
Maximum version: 1.25

You install Armory Continuous Deployment using the Armory Operator (a Kubernetes operator), which has the following requirements:

You must be able to apply Kubernetes manifests and CRDs, either directly using kubectl commands from your machine or another method.
By default, the Operator pulls images from a public registry. If you cannot pull images from public registries, see Air-Gapped with the Armory Operator.

Note that Armory does not produce marketplace specific images that can be used by different certified Kubernetes offerings.

The Kubernetes cluster itself must meet the following requirements:

You have administrator rights to install the Custom Resource Definition (CRD) for the Armory Operator.
If you are managing your own Kubernetes cluster (not EKS), be sure:
- You have enabled admission controllers in Kubernetes (-enable-admission-plugins).
- You have ValidatingAdmissionWebhook enabled in kube-apiserver. Alternatively, you can pass the --disable-admission-controller parameter to the to the deployment.yaml file that deploys the Operator.

If you do not have a cluster already, consult guides for Amazon EKSor the equivalent for your Kubernetes provider.

Browsers

The UI for Armory Continuous Deployment works best on Firefox or Chromium-based browsers.

External storage

Armory Continuous Deployment requires external storage for storing metadata and history.

Bucket storage

You need an S3-compatible object store, such as an S3 bucket or Minio, for persisting your application settings and pipelines. The account you use to install and run Armory Continuous Deployment needs read/write access to the buckets.

RDBMS (SQL)

Depending on the service, Armory Continuous Deployment also uses either Redis, MySQL, or Postgres as a backing store. The following table lists the supported database and the service:

Database	DB version	Armory	Services	Note
Redis	All supported versions	All supported versions	All Armory Continuous Deployment services that require a backing store	The DB versions refer to external Redis instances. Supported only for services that still require Redis for a feature, such as Gate sessions. Redis is not supported as a core persistent storage engine. Although Armory Continuous Deployment deploys internal Redis instances, do not use these instances for production deployments. Armory recommends only using them for testing and proof-of-concept deployments. For AWS ElastiCache for Redis, the instance type should minimally be set to `cache.m5.large`.
MySQL	5.7; AWS Aurora	All supported versions	Clouddriver, Front50, Orca	For AWS RDS, the instance type should minimally be set to `db.r5`.
PostgreSQL	10+	2.24.0 or later	Clouddriver	For AWS RDS, the instance type should minimally be set to `db.r5`.

Armory recommends using MySQL or PostgreSQL as the backing store when possible for production instances of Armory Continuous Deployment. For other services, use an external Redis instance for production instances of Armory Continuous Deployment.

Hardware requirements

Armory recommends a minimum of 3 nodes that match the following profile:

CPUS: 8
Memory (GiB): 32

kubectl

To install and manage Armory Continuous Deployment, Armory recommends using the Armory Operator with Kustomize and tailoring the Kustomize files to meet the requirements of your instance and environment. This installation method supports the following versions of kubectl: 1.16 to 1.19.

It is possible to use the Operator to install Armory Continuous Deployment without the Kustomize repo. In that case, any actively maintained version of kubectl is supported.

Networking

Pods in your Kubernetes cluster must be able to communicate with each other without restrictions.

Additionally, the ports for the API gateway (the Gate service) and the UI (the Deck service) need to be exposed. All interactions with Armory Continuous Deployment go through these two services.

Gate ports

8084
8085 when secured by x509

Deck port

9000

Security

Armory Continuous Deployment needs to be able to assume roles in the accounts that it deploys applications to. For example, Armory Continuous Deployment needs the sts:AssumeRole permission for AWS. Elevated access (equivalent to the level of PowerUser access in AWS) is helpful so that Armory Continuous Deployment can cache data from deployment target accounts and deploy without errors.

In addition to the security requirements that Armory Continuous Deployment needs to run, Armory recommends securing your installation by using a secret store for sensitive values in your configs as well as configuring authentication and authorization.

Continuous-Deployment: Air-Gapped with the Armory Operator

Mon, 01 Jan 0001 00:00:00 +0000

Overview

This guide details how you can host the Armory Continuous Deployment Bill of Materials (BOM) and Docker images, as well as the Armory Operator Docker images, in your air-gapped environment. The steps at a high level are:

Clone the spinnaker-kustomize-patches repo, which contains helper scripts as well as Kustomize patches.
Deploy S3-compatible MinIO to store the BOM.
Download the BOM.
Copy the BOM to your MinIO bucket.
Host Armory Continuous Deployment Docker images in your private Docker registry.
Download the Armory Operator.
Host Armory Operator Docker images in your private Docker registry.
Update Armory Operator configuration.
Deploy the Armory Operator in your Kubernetes cluster.

Before you begin

You are familiar with the Armory Operator and configuring Armory Continuous Deployment using Kustomize patches.
You have read the introduction to air-gapped environments.
You have public internet access.
You have administrator access to your Kubernetes cluster.
You have created two namespaces in Kubernetes: spinnaker and spinnaker-operator.
You have access to a private Docker registry with credentials to push images.
You have installed the AWS CLI.
You have installed yq version 4+. This is used by helper scripts.

Clone the `spinnaker-kustomize-patches` repo

Armory maintains the spinnakaker-kustomize-patches repo, which contains common configuration options for Armory Continuous Deployment or Spinnaker as well as helper scripts. The patches in this repo give you a reliable starting point when adding and removing features.

Configuration in this repository is meant for Armory Continuous Delivery. To make it compatible with Spinnaker instead, apply the utilities/switch-to-oss.yml patch.

To start, create your own copy of the spinnaker-kustomize-patches repository by clicking the Use this template button:

If you intend to update your copy from upstream, use Fork instead. See Creating a repository from a template for the difference between Use this template and Fork.

Once created, clone this repository to your local machine.

Deploy MinIO for storage

Now that you have cloned the spinnaker-kustomize-patches repo, you need to create a storage bucket to host the BOM. MinIO is a good choice for the bucket since it’s S3 compatible and runs as a pod in Kubernetes. A ready to use MinIO component can be referenced in spinnaker-kustomize-patches/core/persistence/in-cluster.

# Your kustomization.yml file

resources:
 - path/to/spinnaker-kustomize-patches/core/persistence/in-cluster/minio.yml

When you look at the content of the minio.yml manifest, you see that MinIO needs a secret key called minioAccessKey:

env:
 # MinIO access key and secret key
 - name: MINIO_ACCESS_KEY
 value: "minio"
 - name: MINIO_SECRET_KEY
 valueFrom:
 secretKeyRef:
 name: minio-secret-key
 key: minioAccessKey

minioAccessKey is stored in a Kubernetes secret called minio-secret-key. You create the secret by adding a generator to your kustomization.yml file.

secretGenerator:
 - name: minio-secret-key
 options:
 disableNameSuffixHash: true
 literals:
 - minioAccessKey=MyAccessKeyValue

Consult the kustomize documentation for more ways to configure secrets.

Deploy MinIO with your infrastructure:
```
kubectl apply -k .
```

Download the BOM

Decide which Armory Continuous Deployment version you want to deploy. Check Armory Release Notes for the latest supported versions.

The spinnaker-kustomize-patches/utilities/airgap directory contains helper scripts for air-gapped environments. Use bomdownloader.sh to download the version of the Armory Continuous Deployment BOM that you require.

bomdownloader.sh takes two command line parameters in the following order:

Armory Continuous Deployment version; for example, 2.34.
The name of your Docker registry; for example, my.jfrog.io/myteam/armory.

The script creates a halconfig folder, downloads the necessary files, and updates the BOM to use the Docker registry you specified. To download the BOM:

Switch to the spinnaker-kustomize-patches directory.

Run bomdownloader.sh <armory-version> <docker-registry>. For example, if you want to download the 2.25.0 BOM and your registry is my.jfrog.io/myteam/armory:

./utilities/airgap/bomdownloader.sh 2.25.0 my.jfrog.io/myteam/armory

Output is similar to:

download: s3://halconfig/versions.yml to halconfig/versions.yml
download: s3://halconfig/bom/2.25.0.yml to halconfig/bom/2.25.0.yml
download: s3://halconfig/profiles/clouddriver/2.25.3/clouddriver.yml to halconfig/profiles/clouddriver/2.25.3/clouddriver.yml
...
Version 2.25.0 is ready to be uploaded to your private bucket.
For example, with "aws cp --recursive" or "gsutil cp -m -r ..."

Inspecting your file system, you should see the new halconfig folder. For example, if you specified Armory Continuous Deployment v2.25.0, your file system should be:

halconfig
 ┣ bom
 ┃ ┗ 2.25.0.yml
 ┣ profiles
 ┃ ┣ clouddriver
 ┃ ┣ dinghy
 ┃ ┣ echo
 ┃ ┣ fiat
 ┃ ┣ front50
 ┃ ┣ gate
 ┃ ┣ igor
 ┃ ┣ kayenta
 ┃ ┣ monitoring-daemon
 ┃ ┣ orca
 ┃ ┣ rosco
 ┃ ┗ terraformer
 ┗ versions.yml

Each subdirectory in the profiles directory contains a <service-name>.yml profile file.

If you need to change your Docker registry, you can manually edit the <armory-version>.yml file located under halconfig/bom. Update the value for the key artifactSources.dockerRegistry.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


version: 2.25.0
timestamp: "2021-03-25 09:28:32"
services:
 clouddriver:
 commit: de3aa3f0
 version: 2.25.3
 deck:
 commit: 516bcf0a
 version: 2.25.3
 ...
 terraformer:
 commit: 5dcae243
 version: 2.25.0
dependencies:
 redis:
 version: 2:2.8.4-2
artifactSources:
 dockerRegistry: my.jfrog.io/myteam/armory

Copy the BOM

With the MinIO pod running, copy your local BOM into your MinIO bucket.

Set environment variables:

Update the AWS_SECRET_ACCESS_KEY with the minioAccessKey value you created in the Deploy MinIO to host the BOM section.
```
export AWS_ACCESS_KEY_ID=minio
export AWS_SECRET_ACCESS_KEY=<minioAccessKey>
```

Port forward the MinIO service:

kubectl port-forward svc/minio 9000 -n spinnaker

Copy your local BOM to MinIO:

aws s3 mb s3://halconfig --endpoint=http://localhost:9000
aws s3 cp --recursive halconfig s3://halconfig --endpoint=http://localhost:9000

Host the Armory Continuous Deployment Docker images

There are two options for hosting the Docker images: 1) configure your Docker registry as a proxy for docker.io/armory; or 2) download the images and push them to your private Docker registry.

Proxy to `docker.io/armory`

Configure docker.io/armory as a remote repository within your private Docker registry. If you are using JFrog Artifactory, you can follow the instructions in the Remote Docker Repositories section of the JFrog docs.

Download images

You can use the imagedownloader.sh helper script in the spinnaker-kustomize-patches/utilities/airgap directory to download and push the images to your private Docker registry.

The execution format is:

./utilities/airgap/imagedownloader.sh <armory-version>

<armory-version> is the version you specified in the Download the BOM section.

When you run imagedownloader.sh from the spinnaker-patches-repository directory, the script looks for the downloaded BOM and proceeds to download, tag, and push the images for that particular version to the private Docker registry you specified when you ran bomdownloader.sh.

Download the Armory Operator

Download and unpack the latest Armory Operator release into the spinnaker-kustomize-patches/operator folder. Run the following command from your spinnaker-kustomize-patches/operator directory:

bash -c 'curl -L https://github.com/armory-io/spinnaker-operator/releases/latest/download/manifests.tgz | tar -xz'

You should see the following directory structure in the spinnaker-kustomize-patches/operator folder:

operator
 ┣ deploy
 ┃ ┣ crds
 ┃ ┣ openshift
 ┃ ┣ operator
 ┃ ┗ spinnaker
 ┣ halyard-local.yml
 ┣ kustomization.yml
 ┣ patch-config.yaml
 ┗ patch-validations.yaml

Host the Armory Operator Docker images

You can find the operatorimageupdate.sh script in spinnaker-kustomize-patches/utilities/airgap. The script does the following:

Downloads the Armory Operator Docker images and updates their names.
Pushes the images to the Docker registry you specify in the command line.
Updates the Armory Operator’s kustomization.yml with the new image names.

From the spinnaker-kustomize-patches/operator folder, execute the operatorimageupdate.sh script:

../utilities/airgap/operatorimageupdate.sh <your-docker-registry>

Update Armory Operator configuration

Update MinIO secret access key

You also need to update Armory Operator configuration to include the secret access key for MinIO. Locate spinnaker-kustomize-patches/operator/patch-config.yml and update the AWS_SECRET_ACCESS_KEY value with the minioAccessKey value you created in the Deploy MinIO to host the BOM section.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


apiVersion: apps/v1
kind: Deployment
metadata:
 name: spinnaker-operator
spec:
 template:
 spec:
 containers:
 - name: spinnaker-operator
 env:
 - name: AWS_ACCESS_KEY_ID # you can choose to use a secret for these values
 value: minio
 - name: AWS_SECRET_ACCESS_KEY # you can choose to use a secret for these values
 value: changeme
 volumeMounts:
 - mountPath: /opt/spinnaker/config/halyard.yml
 name: operator-config
 subPath: halyard-local.yml
 - name: halyard
 env:
 - name: AWS_ACCESS_KEY_ID # you can choose to use a secret for these values
 value: minio
 - name: AWS_SECRET_ACCESS_KEY # you can choose to use a secret for these values
 value: changeme
 volumeMounts:
 - mountPath: /opt/spinnaker/config/halyard-local.yml
 name: operator-config
 subPath: halyard-local.yml
 volumes:
 - configMap:
 defaultMode: 420
 name: operator-config
 name: operator-config

Update Halyard configuration

The Armory Operator uses its own Halyard installation to deploy and manage Armory Continuous Deployment. You need to configure the new BOM location in spinnaker-kustomize-patches/operator/halyard-local.yml. Update your halyard-local.yml to match the content of the highlighted lines in the following example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


halyard:
 halconfig:
 directory: /home/spinnaker/.hal
spinnaker:
 config:
 # This section is used in air-gapped environments to specify an alternate location for the Bill Of Materials (BOM).
 input:
 gcs:
 enabled: false # If the BOM is stored in a GCS bucket, switch this to true.
 bucket: halconfig # Name of the bucket where the BOM is located.
 #region: us-west-2 # Bucket region; region does not matter for MinIO.
 enablePathStyleAccess: true # If you are using a platform that does not support PathStyleAccess, such as MinIO, switch this to true (https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingBucket.html#access-bucket-intro).
 endpoint: http://minio.spinnaker:9000
 anonymousAccess: false

Deploy the Armory Operator

Now that you have updated halyard-local.yml and patch-config.yml, you can deploy the Armory Operator using its kustomization.yml file. By default, the Armory Operator deploys to the spinnaker-operator namespace. From the spinnaker-kustomize-patches/operator directory, execute:

kubectl apply -k .

After the Armory Operator pod is running, verify that the S3-compatible MinIO bucket is properly configured and that the bucket contains the BOM.

The following example uses version 2.25.0 and a private Docker registry called my.jfrog.io/myteam/armory.

Run the following to access the Halyard container running in the spinnaker-operator pod:
```
kubectl exec -ti deploy/spinnaker-operator -c halyard -- bash
```

Verify that the bucket is properly configured by running:

aws s3 ls --endpoint=http://minio.spinnaker:9000 s3://halconfig/

Inspect the contents of the BOM for the version you downloaded in Download the BOM:

hal version bom <version-number>

If you run the command passing in 2.25.0, output is similar to:

+ Get BOM for 2.25.0
Success
version: 2.25.0
timestamp: '2021-03-25 09:28:32'
services:
 echo:
 version: 2.25.2
 commit: 3a098acc
 clouddriver:
 version: 2.25.3
 commit: de3aa3f0
...
dependencies:
 redis:
 version: 2:2.8.4-2
artifactSources:
 dockerRegistry: my.jfrog.io/myteam/armory

Help resources

Contact Armory Support or use the Spinnaker Slack #armory channel.

What’s next

Configure and deploy Armory Continuous Deployment using Kustomize patches.

Continuous-Deployment: Armory Config

Mon, 01 Jan 0001 00:00:00 +0000

spec.spinnakerConfig.config.armory

armory:
 dinghy:
 enabled:
 templateOrg:
 templateRepo:
 githubToken:
 githubEndpoint:
 stashUsername:
 stashToken:
 stashEndpoint:
 gitlabToken:
 gitlabEndpoint:
 dinghyFilename:
 autoLockPipelines:
 fiatUser:
 notifiers:
 slack:
 enabled:
 channel:
 github:
 enabled:
 webhookValidationEnabledProviders:
 webhookValidations:
 - enabled:
 versionControlProvider:
 organization:
 repo:
 secret:
 diagnostics:
 enabled:
 uuid:
 logging:
 enabled:
 endpoint:
 terraform:
 enabled:
 git:
 enabled:
 accessToken:
 username:
 secrets:
 vault:
 enabled:
 url:
 path:
 role:
 authMethod:

Dinghy parameters

enabled: true or false.
templateOrg: SCM organization or namespace where application and template repositories are located.
templateRepo: SCM repository where module templates are located
githubToken: GitHub token. Supports encrypted value.
githubEndpoint: (Default: https://api.github.com) Github API endpoint. Useful if you’re using Github Enterprise.
stashUsername: Stash username.
stashToken: Stash token. Supports encrypted value.
stashEndpoint: Stash API endpoint.
gitlabToken: GitLab token. Supports encrypted value.
gitlabEndpoint: GitLab endpoint.
dinghyFilename: (Default: dinghyfile) Name of the file in application repositories which contains pipelines.
autoLockPipelines: (Default: true) Lock pipelines in the UI before overwriting on change.
fiatUser: Fiat user to use for Dinghy operations.
notifiers:
- slack:
  - enabled: true or false.
  - channel: Name of channel to send notifications to.
- github:
  - enabled: true or false. This enables comments to the PR to allow for more robust feedback information from Dinghy. May cause issues with those using custom GitHub endpoints, as detailed in this KB article.
webhookValidationEnabledProviders: List of enabled providers for Webhook validations.
webhookValidations: Webhook validations list
- enabled: true/false flag to enable this validation.
- versionControlProvider: Version control provider.
- organization: Organization for the repository.
- repo: Repository name.
- secret: Secret configured.

Diagnostics parameters

enabled: true or false.
uuid: UUID of the Armory installation
logging:
- enabled: true or false.
- endpoint: Example: https://debug.armory.io/v1/logs

Armory Terraform parameters

enabled: true or false.
git:
- enabled: true or false.
- accessToken: Git access token. Supports encrypted value.
- username: Git username.

Secrets parameters

vault:
- enabled: true or false.
- url: URL of the Vault endpoint from Spinnaker services.
- path: (Default: kubernetes) (Applies to Kubernetes authentication method) Path of the Kubernetes authentication backend mount.
- role: (Applies to Kubernetes authentication method) Name of the role against which the login is being attempted.
- authMethod: Method used to authenticate with the Vault endpoint. Must be either KUBERNETES for Kubernetes service account auth or TOKEN for Vault token auth. The TOKEN method requires a VAULT_TOKEN environment variable for Operator and the services.

Kustomize patch examples

You can see examples in the spinnaker-kustomize-patches repo’s armory folder.

Continuous-Deployment: Artifact Config

Mon, 01 Jan 0001 00:00:00 +0000

spec.spinnakerConfig.config.artifacts

artifacts:
 bitbucket:
 gcs:
 github:
 gitlab:
 gitrepo:
 helm:
 http:
 maven:
 oracle:
 s3:
 templates:

Bitbucket

spec.spinnakerConfig.config.artifacts.bitbucket

artifacts:
 bitbucket:
 enabled: false
 accounts:
 - name:
 username:
 password:
 token:
 tokenFile:
 usernamePasswordFile:

enabled: true or false

Account parameters

username: Bitbucket username
password: Bitbucket password. Supports encrypted value.
usernamePasswordFile: File containing “username:password” to use for Bitbucket authentication. File needs to be present on the machine running Spinnaker. Supports encrypted file.
token: Bitbucket Server token. Supports encrypted value.
tokenFile: File containing a Bitbucket Server authentication token. File needs to be present on the machine running Spinnaker. Supports encrypted file. This file can be dynamically updated because it is automatically reloaded each time Armory Continuous Deployment makes a request.

Note: supply username and password OR usernamePasswordFile OR token OR tokenFile

GCS

spec.spinnakerConfig.config.artifacts.gcs

gcs:
 enabled: false
 accounts:
 - name: my-gcs-account
 jsonPath:

enabled: true or false

Account parameters

json-path: The path to a JSON service account that Spinnaker will use as credentials. This is only needed if Spinnaker is not deployed on a Google Compute Engine VM, or needs permissions not afforded to the VM it is running on. See service-accounts for more information. File needs to be present on the machine running Spinnaker. Supports encrypted file.

GitHub

spec.spinnakerConfig.config.artifacts.github

github:
 accounts:
 - name: my-github
 username:
 password:
 usernamePasswordFile:
 token:
 tokenFile:
 enabled: true

enabled: true or false

Account parameters

username: GitHub username
password: GitHub password. Supports encrypted value.
usernamePasswordFile: File containing “username:password” to use for GitHub authentication. File needs to be present on the machine running Spinnaker. Supports encrypted file.
token: GitHub token. Supports encrypted value.
tokenFile: File containing a GitHub authentication token. File needs to be present on the machine running Spinnaker. Supports encrypted file. This file can be dynamically updated because it is automatically reloaded each time Armory Continuous Deployment makes a request.

Note: supply username and password OR usernamePasswordFile or token or tokenFile

GitLab

spec.spinnakerConfig.config.artifacts.gitlab

gitlab:
 enabled:
 accounts:
 - name:
 token:
 tokenFile:

enabled: true or false

Account parameters

token: Gitlab token. Supports encrypted value.
tokenFile: File containing a Gitlab authentication token. File needs to be present on the machine running Spinnaker. Supports encrypted file. This file can be dynamically updated because it is automatically reloaded each time Armory Continuous Deployment makes a request.

Note: supply token or tokenFile

GitRepo

spec.spinnakerConfig.config.artifacts.gitrepo

gitrepo:
 enabled:
 accounts:
 - name:
 username:
 password:
 usernamePasswordFile:
 token:
 tokenFile:
 sshPrivateKeyFilePath:
 sshPrivateKeyPassphrase:
 sshKnownHostsFilePath:
 sshTrustUnknownHosts:

enabled: true or false

Account parameters

username: Git username
password: Git password. Supports encrypted value.
usernamePasswordFile: File containing “username:password” to use for Git authentication. File needs to be present on the machine running Spinnaker. Supports encrypted file.
token: Git token. Supports encrypted value.
tokenFile: File containing a Git authentication token. File needs to be present on the machine running Spinnaker. Supports encrypted file. This file can be dynamically updated because it is automatically reloaded each time Armory Continuous Deployment makes a request.
sshPrivateKeyFilePath: Path to the ssh private key in PEM format. File needs to be present on the machine running Spinnaker. Supports encrypted file.
sshPrivateKeyPassphrase: Passphrase for encrypted private key. Supports encrypted value.
sshKnownHostsFilePath: File containing the known and trusted SSH hosts. File needs to be present on the machine running Spinnaker. Supports encrypted file.
sshTrustUnknownHosts: Setting this to true allows Spinnaker to authenticate with unknown hosts

Note: supply username and password OR usernamePasswordFile or token or tokenFile

Helm

spec.spinnakerConfig.config.artifacts.helm

helm:
 enabled:
 accounts:
 - name:
 repository:
 username:
 password:
 usernamePasswordFile:

enabled: true or false

Account parameters

repository: Helm chart repository
username: Helm chart repository basic auth username
password: Helm chart repository basic auth password. Supports encrypted value.
usernamePasswordFile: File containing “username:password” to use for helm chart repository basic auth. File needs to be present on the machine running Spinnaker. Supports encrypted file.

Note: supply username and password OR usernamePasswordFile

HTTPS

spec.spinnakerConfig.config.artifacts.https

http:
 enabled:
 accounts:
 - name:
 username:
 password:
 usernamePasswordFile:

enabled: true or false

Account parameters

username: HTTP basic auth username
password: HTTP basic auth password. Supports encrypted value.
usernamePasswordFile: File containing “username:password” to use for HTTP basic auth. File needs to be present on the machine running Spinnaker. Supports encrypted file.

Note: supply username and password OR usernamePasswordFile

Maven

spec.spinnakerConfig.config.artifacts.maven.accounts

maven:
 enabled:
 accounts:
 - name:
 repositoryUrl:

enabled: true or false

Account parameters

repositoryUrl: Full URI for the Maven repository ie.http://some.host.com/repository/path

Oracle

spec.spinnakerConfig.config.artifacts.oracle

oracle:
 enabled:
 accounts:
 - name:
 namespace:
 region:
 userId:
 fingerprint:
 sshPrivateKeyFilePath:
 privateKeyPassphrase:
 tenancyId:

enabled: true or false

Account parameters

namespace: The namespace the bucket and objects should be created in
region: An Oracle region (e.g., us-phoenix-1)
userId: Provide the OCID of the Oracle User you’re authenticating as
fingerprint: Fingerprint of the public key
sshPrivateKeyFilePath: Path to the private key in PEM format. File needs to be present on the machine running Spinnaker. Supports encrypted file.
privateKeyPassphrase: Passphrase used for the private key, if it is encrypted. Supports encrypted value.
tenancyId: Provide the OCID of the Oracle Tenancy to use.

S3

spec.spinnakerConfig.config.artifacts.s3

s3:
 enabled:
 accounts:
 - name:
 apiEndpoint:
 apiRegion:
 region:
 awsAccessKeyId:
 awsSecretAccessKey:

enabled: true or false

Account parameters

apiEndpoint: S3 api endpoint; only required when using an S3 clone such as Minio
apiRegion: S3 api region; only required when using an S3 clone such as Minio
region: S3 region
awsAccessKeyId: Your AWS Access Key ID. If not provided, Halyard/Spinnaker will try to find AWS credentials as described at http://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/credentials.html#credentials-default
awsSecretAccessKey: Your AWS Secret Key. Supports encrypted value.

Templates

templates:
- name:
 templatePath:

templatePath: The path to the Jinja template to use for artifact extraction. File needs to be present on the machine running Spinnaker.

Continuous-Deployment: AWS QuickStart Step 1

Mon, 01 Jan 0001 00:00:00 +0000

The AWS QuickStart walks you through configuring your Spinnaker instance hosted on AWS to deploy to AWS.

Note

This guide assumes that Spinnaker is installed with Halyard, not Operator.

Prerequisites

Before you start, ensure that you complete the following requirements:

Have your AWS Account number available in a text editor*
Have Minnaker installed on AWS. For more information about Minnaker, see Minnaker.
SSH into your Minnaker Instance with AWS keys

Need help setting this up? - For a guided tutorial, watch the Video Walkthrough at the bottom of this document.

Prepare AWS by creating Roles, Permissions, and Trust

In this step, we configure 2 AWS Roles to enable Spinnaker to deploy to your AWS environment

Create - “Spinnaker-Managed-Role” in AWS Console -> IAM -> Roles.
Bind “PowerUserAccess” to “Spinnaker-Managed-Role” in Permissions.

“PassRole-and-Certificate” (inline policy for Spinnaker-Managed-Role):

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Action": [
 "iam:ListServerCertificates",
 "iam:PassRole"
 ],
 "Resource": [
 "*"
 ],
 "Effect": "Allow"
 }
 ]
}

Create - “Spinnaker-Managing-Role”.
Bind “PowerUserAccess” to “Spinnaker-Managing-Role”.

“BaseIAM-PassRole” (Create as inline policy on “Spinnaker-Managing-Role”). You must replace [YOUR_AWS_ACCOUNT_ID] with your actual AWS account id.

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": [
 "ec2:DescribeAvailabilityZones",
 "ec2:DescribeRegions"
 ],
 "Resource": [
 "*"
 ]
 },
 {
 "Action": "sts:AssumeRole",
 "Resource": [
 "arn:aws:iam::[YOUR_AWS_ACCOUNT_ID]:role/Spinnaker-Managed-Role"
 ],
 "Effect": "Allow"
 }
 ]
}

Spinnaker-Managed-Role -> Trust relationship

Now, “Spinnaker-Managed-Role” must have Trust relationship with “Spinnaker-Managing-Role”. You must replace [YOUR_AWS_ACCOUNT_ID] with your actual AWS account id.

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Principal": {
 "AWS": "arn:aws:iam::[YOUR_AWS_ACCOUNT_ID]:role/Spinnaker-Managing-Role",
 "Service": [
 "ecs.amazonaws.com",
 "application-autoscaling.amazonaws.com",
 "ecs-tasks.amazonaws.com",
 "ec2.amazonaws.com"
 ]
 },
 "Action": "sts:AssumeRole"
 }
 ]
}

Bind “Spinnaker-Managing-Role” to Minnaker Instance in AWS Console

Locate your Minnaker EC2 instance in the AWS Console and click Action > Instance Settings > Attach Replace IAM Role.
From the dropdown menu, find “Spinnaker-Managing-Role” and click Apply to bind the Role to the Minnaker Instance.

Verify Roles are configured correctly

Download the aws-cli:
```
sudo snap install aws-cli --classic
```

Verify “Spinnaker-Managing-Role”:

aws sts get-caller-identity

The command returns output similar to the following output:

ubuntu:~$ aws sts get-caller-identity
{
 "UserId": "AROA3SQXSP.............7893f355",
 "Account": "[YOUR_AWS_ACCOUNT_ID]",
 "Arn": "arn:aws:sts::[YOUR_AWS_ACCOUNT_ID]:assumed-role/Spinnaker-Managing-Role/i-0e.........7893f355"
}

Verify that Spinnaker Managing Role can Assume Managing Role:

aws sts assume-role --role-arn arn:aws:iam::[YOUR_AWS_ACCOUNT_ID]:role/Spinnaker-Managed-Role --role-session-name test

The command returns output similar to the following output:

ubuntu:~$ aws sts assume-role --role-arn arn:aws:iam::[YOUR_AWS_ACCOUNT_ID]:role/Spinnaker-Managed-Role --role-session-name test
{
 "Credentials": {
 "Expiration": "2020-01-09T01:03:05Z",
 "AccessKeyId": "AWS_ACCESS_KEY",
 "SecretAccessKey": "AWS_SECRET_ACCESS_KEY",
 "SessionToken": "FwoGZXIvYXdzEGEaDEyTECcALWUjAgy0GyKoAZ5PapC1qqFwN55X0vRISdtZh19mR3V9p3i5dGZugt3FQ4DNOamVgIG82I1qaspn83aBefdbpUtznN9fJxwPNoRhYinVgIXGdsTWnBuQ57U7s/cDoHosvV5+J3oZj8ffjLInzsI05IrRBiOTmqU3caEP/e+6N5nzHg/9+aS6TCWjCIzjL0mHtclBBQ7k/dijrg/5vTVFh8UGakcJL3SV6gaCHj0k6BUzEii529nwBTItq6/QISV8wfGNLQJOPDB5P3zoQkHjkpoWCEh1p0oc4hEwki8F7NutXNrg14W+"
 },
 "AssumedRoleUser": {
 "AssumedRoleId": "AROA3SQXSP6SGOWFHHJ7B:test",
 "Arn": "arn:aws:sts::[YOUR_AWS_ACCOUNT_ID]:assumed-role/Spinnaker-Managed-Role/test"
 }
}

Congratulations

You have completed the 1st step in setting up the Spinnaker AWS Provider. For Step 2, see AWS Quick Start Step 2.

Continuous-Deployment: AWS QuickStart Step 2

Mon, 01 Jan 0001 00:00:00 +0000

Need help setting this up? - For a guided tutorial, see the video walkthrough at the bottom of this page.

Note

This guide assumes that Spinnaker is installed with Halyard, not Operator.

Prerequisites

Before you start, ensure that have completed the following requirements:

Finish AWS QuickStart Step 1.
Have access to the Kubernetes cluster you would like to deploy to, and you need cluster admin permissions on that Kubernetes cluster.
Have kubectl installed on your local workstation have the context set to the EKS cluster you want to deploy to.

Running the following command from your local machine should return the namespaces for the EKS cluster you want to deploy to.
```
kubectl get ns
```
Have a way to copy files from your local workstation to the Minnaker VM, such as scp.

First: Configure the AWS Provider for Spinnaker

Adding AWS Role to Spinnaker through Halyard configuration. Note AWS account name is within Spinnaker and will appear in UI

NOTE: You MUST configure the regions that Spinnaker can deploy to in the hal command below.

The Account name is arbitrary and should be a name that is an identifiable. The name is visable in Spinnaker UI. The following examples use aws-dev-1.

Set environment variables for halyard command:

export AWS_ACCOUNT_NAME=aws-dev-1 \
export ACCOUNT_ID=[YOUR_ACCOUNT_ID] \
export ROLE_NAME=role/Spinnaker-Managed-Role

Add the AWS provider account to Spinnaker:

hal config provider aws account add ${AWS_ACCOUNT_NAME} \
 --account-id ${ACCOUNT_ID} \
 --assume-role ${ROLE_NAME} \
 --regions us-east-1,us-west-2

Enable the AWS provider:
```
hal config provider aws enable
```

Add an account to the ECS provider:

hal config provider ecs account add ecs-account-name --aws-account aws-dev-1

Enable the ECS provider:
```
hal config provider ecs enable
```
Apply the new configurations and redeploy Spinnaker:
```
hal deploy apply
```

Tag AWS Subnets for Spinnaker Auto Discovery

If subnets do not appear in Deck (the Spinnaker UI), perform AWS Subnet tagging. “example-purpose” should be a descriptor of the subnet and will appear in the Spinnaker UI dropdown.

For more information about AWS Subnet tagging, see AWS: Configuring AWS Networking.

Key Value
immutable_metadata {"purpose":"example-purpose"}

Replace example-purpose with your subnet identifier. The subnet shows up in Deck as a dropdown option.

Example:

Key: immutable_metadata
Value: {"purpose":"us-west-2-dev-subnet"}

Second: Connect Spinnaker to an Amazon EKS cluster

For the tasks in this section, complete them on your local workstation, not from the Minnaker VM.

Using spinnaker-tools

spinnaker-tools is a wrapper that performs a series of kubectl commands for you to automate creating a service account.

On your local workstation (where you currently have access to Kubernetes), download the spinnaker-tools binary:

If you’re on a Mac:

curl -L https://github.com/armory/spinnaker-tools/releases/download/0.0.7/spinnaker-tools-darwin -o spinnaker-tools
chmod +x spinnaker-tools

If you’re on Linux:

curl -L https://github.com/armory/spinnaker-tools/releases/download/0.0.7/spinnaker-tools-linux -o spinnaker-tools
chmod +x spinnaker-tools

Then, run it:

./spinnaker-tools create-service-account

Provide the following information:

Select the Kubernetes cluster to deploy to (this helps if you have multiple Kubernetes clusters configured in your local kubeconfig)
Select the namespace (choose the kube-system namespace, or select some other namespace or select the option to create a new namespace). This is the namespace that the Kubernetes ServiceAccount will be created in.
Enter a name for the service account. You can use the default spinnaker-service-account, or enter a new (unique) name.
Enter a name for the output file. You can use the default kubeconfig-sa, or you can enter a unique name. You should use something that identifies the Kubernetes cluster you are deploying to (for example, if you are setting up Spinnaker to deploy to your us-west-2 dev cluster, then you could do something like kubeconfig-us-west-2-dev)

spinnaker-tools uses this information to create the service account (and namespace, if applicable) and the ClusterRoleBinding. It then creates the kubeconfig file with the specified name.

Copy this file from your local workstation to your Minnaker VM. You can use scp or some other copy mechanism.

Add the kubeconfig to Spinnaker’s Halyard configuration

On the Minnaker VM, move or copy the file to /etc/spinnaker/.hal/.secret. Make sure you are creating a new file, not overwriting an existing one.

Then, run this command:

hal config provider kubernetes account add kubeconfig-sa-eks \
 --provider-version v2 \
 --kubeconfig-file /home/spinnaker/.hal/.secret/kubeconfig-sa-eks \
 --only-spinnaker-managed true

Note:

Update the --kubeconfig-file path with the correct filename. Note that the path will be /home/spinnaker/... not /etc/spinnaker/.... This is because this command runs inside the Halyard container, which has local volumes mounted into it.

Apply your changes

Run this command to apply your changes to Spinnaker:

hal deploy apply --wait-for-completion

Congratulations

You have configured the Spinnaker AWS Provider and Kubernetes Account for EKS. You can now deploy to EC2, ECS, Fargate, and EKS. Lets build some pipelines in AWS QuickStart Step 3.

Continuous-Deployment: AWS QuickStart Step 3

Mon, 01 Jan 0001 00:00:00 +0000

Need help setting this up? - For a guided tutorial, see the video walkthrough at the bottom of this page.

Note

This guide assumes that Spinnaker is installed with Halyard, not Operator.

Prerequisite

Before you start, ensure that have completed the following requirements:

Finish AWS QuickStart Step 2

Deploy to EC2 and EKS

Before you start, you need to log in to Deck, the Spinnaker UI.

You can access it by navigating to the Public IP address of your instance in a browser. You can get the Public IP address from your AWS Console.

If you have forgotten the password to your Minnaker instance you can recover your password with the following steps:

SSH to the Minnaker host VM. Do not exec into the Halyard pod though.
Run the following command:

cat /etc/spinnaker/.hal/.secret/spinnaker_password

The command returns the password for Minnaker.

After you log in to Deck, perform the following steps:

Create an Application called QuickStart by clicking “Applications” tab > “Action” (top right) > “Create New App” with the following Settings

Go into Application QuickStart and create your first pipeline. This pipeline will deploy to an EC2 instance.
Click Add Stage + and search for a Bake stage to bake an AMI.
Select the AWS Region you want to deploy to.
Click Add Server Group and configure basic AMI bake settings: Account, Region, Subnet, Instance Type, and AWS SSH key. Note: For more information about setting up your Bake Stage, please check out configuring AWS networks, which includes guides about requirements regarding subnet configuration.
Click Done and then Save Changes in the bottom right corner.
Click Add Stage and add another stage called Deploy for AWS EC2.
Click the “Back to Execution” button on the top left of the Pipeline Name
Run your Pipeline and Validate! The end result will be an Auto Scaling Group build within your AWS subnet.

EC2 Pipeline and deployment

Note - Don’t mind the red dot in the Bake Stage. It’s an informational tip suggesting a CI Trigger should be configured for a Bake Stage to ensure you are deploying the latest code and artifacts.

EKS deployment

Note As a prerequisite, create a “quickstart” namespace in EKS:

kubectl create ns quickstart

Navigate to the pipeline page within your QuickStart application.
Click Create button in top right corner.
Give the name Deploy-to-EKS.
Click Add Stage and Search / Select Deploy(Manifest).
Select the kubeconfig-sa-eks account created in Step 2.
Select the quickstart namespace.
Scroll down and paste in the Deployment yaml below.
Click Save Changes in the bottom right corner.
Now create another stange after the Deployment stage. Again select Deploy(Manifest).
Select the kubeconfig-sa-eks account and the quickstart namespace for deployment.
Scroll down and paste in the Service yaml below.
Click Save Changes.

Time to run your EKS pipeline and validate

Click back to the pipeline page using the Back to Executions to the left of the pipeline name.
Click on the Start Manual Execution on the new pipeline. Then, click Execution Details to see pipeline in action.

Deployment yaml definition

Copy and paste the following example into the text field in the 1st Deploy Manifest stage.

apiVersion: apps/v1
kind: Deployment
metadata:
 name: my-nginx
spec:
 replicas: 2
 selector:
 matchLabels:
 run: my-nginx
 template:
 metadata:
 labels:
 run: my-nginx
 spec:
 containers:
 - image: nginx
 name: my-nginx
 ports:
 - containerPort: 80

Service yaml for last Deployment Stage

Copy and paste the following example into the text field in the 2nd Deploy Manifest stage.

apiVersion: v1
kind: Service
metadata:
 labels:
 run: my-nginx
 name: my-nginx
spec:
 ports:
 - port: 80
 protocol: TCP
 targetPort: 80
 selector:
 run: my-nginx
 type: LoadBalancer

Validation in EKS and in Spinnaker

In EKS run the following commands to see nginx pods being created: kubectl get pods -n quickstart.
In Deck, the Spinnaker UI, navigate to the Applications page and see the deployment and containers there.

Under Load Balancers, click on Apps to view the status of your service.
In the Status section on the right of the page, locate the Ingress address that was created to allow public access to your new deployment.

Copy and paste the FQDN from the load balancer status section into a web browser to test the NGINX landing page.

Congratulations

You completed the QuickStart exercise! You can now deploy to AWS using Spinnaker. What’s Next?

Connect your Spinnaker instance to your repositories / artifacts (Github, Sonatype, Artifactory, DockerHub, ECR, GCR, etc).
Build in a automated trigger from your CI systems (Jenkins, Bamboo, CircleCI, TravisCI, Nexus, Git, Generic Webhook, etc).
Integrate with 3rd party systems (OKTA, Sumo Logic, Splunk, Datadog, Newrelic, Slack, etc).
Integrate with DevSecOps tools (Xray, ChaosMonkey, Artifactory, etc).

To get expert help in any of the areas above you can contact Armory.io at https://go.armory.io/needs-analysis

Continuous-Deployment: Canary Config

Mon, 01 Jan 0001 00:00:00 +0000

spec.spinnakerConfig.config.canary

canary:
 enabled: true
 reduxLoggerEnabled:
 defaultMetricsAccount:
 defaultStorageAccount:
 defaultJudge:
 defaultMetricsStore:
 stagesEnabled:
 atlasWebComponentsUrl:
 templatesEnabled:
 showAllConfigsEnabled:
 serviceIntegrations:

enabled: true or false
reduxLoggerEnabled: true or false; whether or not to enable redux logging in the canary module in deck (Default: true).
defaultMetricsAccount: Name of metrics account to use by default.
defaultStorageAccount: Name of storage account to use by default.
defaultJudge: Name of canary judge to use by default (Default: NetflixACAJudge-v1.0).
defaultMetricsStore: Name of metrics store to use by default (e.g. atlas, datadog, prometheus, stackdriver).
stagesEnabled: true or false; whether or not to enable canary stages in deck (Default: true).
atlasWebComponentsUrl: Location of web components to use for Atlas metric configuration.
templatesEnabled: true or false; whether or not to enable custom filter templates for canary configs in deck (Default: true).
showAllConfigsEnabled: true or false; whether or not to show all canary configs in deck, or just those scoped to the current application (Default: true).
serviceIntegrations: list of configured canary services

Service Integrations

spec.spinnakerConfig.config.canary.serviceIntegrations

canary:
 enabled:
 serviceIntegrations:
 - name:
 enabled:
 accounts:
 - name:
 enabled:
 accounts:

Datadog

- name:
 enabled:
 accounts:
 - name:
 endpoint:
 baseUrl:
 apiKey:
 applicationKey:
 supportedTypes:
 - METRICS_STORE
 - CONFIGURATION_STORE
 - OBJECT_STORE

name: datadog
- enabled: true or false
- accounts:
  - name: account name
    - endpoint:
      - baseUrl: (Required) The base URL to the Datadog server.
    - apiKey: (Required) Your org’s unique Datadog API key. See https://app.datadoghq.com/account/settings#api. Supports encrypted value.
    - applicationKey: (Required) Your Datadog application key. See https://app.datadoghq.com/account/settings#api. Supports encrypted value.
    - supportedTypes: One of: METRICS_STORE, METRICS_STORE, OBJECT_STORE
      - METRICS_STORE
      - CONFIGURATION_STORE
      - OBJECT_STORE

Google

- name:
 enabled:
 accounts:
 - name:
 project:
 jsonPath:
 bucket:
 bucketLocation:
 rootFolder:
 supportedTypes:
 - METRICS_STORE
 - CONFIGURATION_STORE
 - OBJECT_STORE
 gcsEnabled:
 stackdriverEnabled:
 metadataCachingIntervalMS:

name: google
- enabled: true or false
- accounts:`
  - name: account name
    - project: (Required) The Google Cloud Platform project the canary service will use to consume GCS and Stackdriver.
    - jsonPath: The path to a JSON service account that Spinnaker will use as credentials. This is only needed if Spinnaker is not deployed on a Google Compute Engine VM, or needs permissions not afforded to the VM it is running on. See https://cloud.google.com/compute/docs/access/service-accounts for more information. File needs to be present on the machine running Spinnaker. Supports encrypted file.
    - bucket: The name of a storage bucket that your specified account has access to. If you specify a globally unique bucket name that doesn’t exist yet, Kayenta will create that bucket for you.
    - bucketLocation: This is only required if the bucket you specify doesn’t exist yet. In that case, the bucket will be created in that location. See https://cloud.google.com/storage/docs/managing-buckets#manage-class-location.
    - rootFolder: The root folder in the chosen bucket to place all of the canary service’s persistent data in (Default: kayenta).
    - supportedTypes: One of: METRICS_STORE, CONFIGURATION_STORE, OBJECT_STORE
      - METRICS_STORE
      - CONFIGURATION_STORE
      - OBJECT_STORE
- gcsEnabled: true or false. Whether or not to enable GCS as a persistent store (Default: false).
- stackdriverEnabled: true or false. Whether or not to enable Stackdriver as a metrics service (Default: false).
- metadataCachingIntervalMS: Number of milliseconds to wait in between caching the names of available metric types (for use in building canary configs; default: 60000).

New Relic

- name:
 enabled:
 accounts:
 - name:
 endpoint:
 baseUrl:
 apiKey:
 applicationKey:
 supportedTypes:
 - METRICS_STORE
 - CONFIGURATION_STORE
 - OBJECT_STORE

name: newrelic
- enabled: true or false
- accounts:`
  - name: account name
    - endpoint:
      - baseUrl: (Required) The base URL to the New Relic Insights server.
    - apiKey: (Required) Your account’s unique New Relic Insights API key. See https://docs.newrelic.com/docs/insights/insights-api/get-data/query-insights-event-data-api. Supports encrypted value.
    - applicationKey: (Required) Your New Relic account id. See https://docs.newrelic.com/docs/accounts/install-new-relic/account-setup/account-id. Supports encrypted value.
    - supportedTypes: One of: METRICS_STORE, CONFIGURATION_STORE, OBJECT_STORE
      - METRICS_STORE
      - CONFIGURATION_STORE
      - OBJECT_STORE

Prometheus

- name:
 enabled:
 accounts:
 - name:
 endpoint:
 baseUrl:
 username:
 password:
 usernamePasswordFile:
 supportedTypes:
 - METRICS_STORE
 - CONFIGURATION_STORE
 - OBJECT_STORE
 metadataCachingIntervalMS:

name: prometheus
- enabled: true or false
- accounts: account name
  - name:
    - endpoint:
      - baseUrl: (Required) The base URL to the Prometheus server.
    - username: A basic auth username.
    - password: A basic auth password.
    - usernamePasswordFile: The path to a file containing “username:password”. File needs to be present on the machine running Spinnaker. Supports encrypted file.
    - supportedTypes: One of: METRICS_STORE, CONFIGURATION_STORE, OBJECT_STORE
      - METRICS_STORE
      - CONFIGURATION_STORE
      - OBJECT_STORE
- metadataCachingIntervalMS: Number of milliseconds to wait in between caching the names of available metric types (for use in building canary configs; Default: 60000).

SignalFX

- name: signalfx
 enabled:
 accounts:
 - name:
 endpoint:
 baseUrl:
 accessToken:
 defaultScopeKey:
 defaultLocationKey:
 supportedTypes:
 - METRICS_STORE
 - CONFIGURATION_STORE
 - OBJECT_STORE

name: signalfx
- enabled: true or false
- accounts:
  - name: account name
    - endpoint:
      - baseUrl: The base URL to the SignalFx server. Defaults to https://stream.signalfx.com
    - accessToken: (Required) The SignalFx access token. Supports encrypted value.
    - defaultScopeKey: Scope key is used to distinguish between base and canary deployments. If omitted every request must supply the _scope_key param in extended scope params
    - defaultLocationKey: Location key is used to filter by deployment region. If omitted requests must supply the _location_key if it is needed.
    - supportedTypes: One of: METRICS_STORE, CONFIGURATION_STORE, OBJECT_STORE
      - METRICS_STORE
      - CONFIGURATION_STORE
      - OBJECT_STORE

Kustomize patch examples

You can see examples in the spinnaker-kustomize-patches repo’s canary folder.

Continuous-Deployment: CI Config

Mon, 01 Jan 0001 00:00:00 +0000

AWS CodeBuild

spec.spinnakerConfig.config.ci.codebuild

codebuild:
 enabled:
 accounts:
 - name:
 permissions:
 READ:
 accountId:
 assumeRole:
 region:

enabled: whether this CI tool is enabled
accounts: list of configured accounts

Account parameters

name: (Required) account name
permissions:
- READ:
- read1
accountId: The AWS account ID that will be used to trigger CodeBuild build.
assumeRole: If set, Operator will configure a credentials provider that uses AWS Security Token Service to assume the specified role.
region: (Required) The AWS region in which your CodeBuild projects live.

Concourse

spec.spinnakerConfig.config.ci.concourse

concourse:
 enabled:
 masters:
 - name:
 permissions:
 READ:
 WRITE:
 url:
 username:
 password:

enabled: whether this CI tool is enabled
masters: list of configured masters

Master parameters

name: master’s name
permissions: []
- READ: A user must have at least one of these roles in order to view this build master or use it as a trigger source.
- WRITE: A user must have at least one of these roles in order to be able to run jobs on this build master.
url: (Required) The url your concourse search is reachable at.
username: (Required) The username of the concourse user to authenticate as.
password: (Required) The password of the concourse user to authenticate as. Supports encrypted value.

Google CloudBuild (gcb)

spec.spinnakerConfig.config.ci.gcb

gcb:
 enabled:
 accounts:
 - name:
 permissions:
 READ:
 - read1
 project:
 subscriptionName:
 jsonKey:

enabled: whether this CI tool is enabled
accounts: list of configured masters

Account parameters

name: (Required) account name
permissions: []
- READ: A user must have at least one of these roles in order to view this build master or use it as a trigger source.
project: (Required) The name of the GCP project in which to trigger and monitor builds.
subscriptionName: The name of the PubSub subscription on which to listen for build changes.
jsonKey: The path to a JSON service account that Spinnaker will use as credentials. File needs to be present on the machine running Spinnaker. Supports encrypted file.

Jenkins

spec.spinnakerConfig.config.ci.jenkins

jenkins:
 enabled:
 masters:
 - name:
 permissions:
 READ:
 - read1
 address:
 username:
 password:
 csrf:
 trustStore:
 trustStoreType:
 trustStorePassword:

enabled: whether this CI tool is enabled
masters: list of configured masters

Master parameters

name: master’s name
permissions: []
- READ: A user must have at least one of these roles in order to view this build master or use it as a trigger source.
address: (Required) The address your Jenkins master is reachable at.
username: The username of the Jenkins user to authenticate as.
password: The password of the Jenkins user to authenticate as. Supports encrypted value.
csrf: Whether or not to negotiate CSRF tokens when calling Jenkins.
trustStore: File needs to be present on the machine running Spinnaker. Supports encrypted file.
trustStoreType:
trustStorePassword: Supports encrypted value.

Travis

spec.spinnakerConfig.config.ci.travis

travis:
 enabled:
 masters:
 - name:
 permissions:
 READ:
 - read1
 WRITE:
 - write1
 address:
 baseUrl:
 githubToken:
 numberOfRepositories:

enabled: whether this CI tool is enabled
masters: list of configured masters

Master parameters

name: master’s name
permissions: []
- READ: A user must have at least one of these roles in order to view this build master or use it as a trigger source.
- WRITE: A user must have at least one of these roles in order to be able to run jobs on this build master.
address: (Required) The address of the Travis API.
baseUrl: (Required) The base URL to the Travis UI.
githubToken: The github token to authenticate against Travis with. Supports encrypted value.
numberOfRepositories: How many repositories the Travis integration should fetch from the api each time the poller runs. Should be set a bit higher than the expected maximum number of repositories built within the poll interval.

Wercker

spec.spinnakerConfig.config.ci.wercker

wercker:
 enabled:
 masters:
 - name:
 permissions:
 READ:
 - read1
 WRITE:
 - write1
 address:
 user:
 token:

enabled: whether this CI tool is enabled
masters: list of configured masters

Master parameters

name: master’s name
permissions: []
- READ: A user must have at least one of these roles in order to view this build master or use it as a trigger source.
- WRITE: A user must have at least one of these roles in order to be able to run jobs on this build master.
address: (Required) The address your Wercker master is reachable at.
user: The username of the Wercker user to authenticate as.
token: The personal token of the Wercker user to authenticate as. Supports encrypted value.

Kustomize patch examples

You can see examples in the spinnaker-kustomize-patches repo’s ci folder.

Continuous-Deployment: Deployment Environment Config

Mon, 01 Jan 0001 00:00:00 +0000

deploymentEnvironment

deploymentEnvironment:
 size:
 type:
 accountName:
 imageVariant:
 bootstrapOnly:
 updateVersions:
 consul:
 enabled:
 address:
 vault:
 enabled:
 address:
 location:
 customSizing:
 clouddriver:
 replicas:
 requests:
 memory:
 cpu:
 limits:
 memory:
 cpu:
 sidecars:
 clouddriver:
 - name:
 dockerImage:
 port:
 env:
 abc:
 args:
 - arg1
 command:
 - arg1
 configMapVolumeMounts:
 - configMapName:
 mountPath:
 secretVolumeMounts:
 - secretName:
 mountPath:
 mountPath:
 securityContext:
 privileged:
 initContainers: {}
 hostAliases: {}
 nodeSelectors:
 abc:
 affinity: {}
 tolerations:
 clouddriver:
 - key:
 operator:
 value:
 effect:
 gitConfig:
 upstreamUser:
 originUser:
 livenessProbeConfig:
 enabled:
 initialDelaySeconds:
 haServices:
 clouddriver:
 enabled:
 disableClouddriverRoDeck:
 redisMasterEndpoint:
 redisSlaveEndpoint:
 redisSlaveDeckEndpoint:
 echo:
 enabled:

size: SMALL
type: Distributed, LocalDebian, or LocalGit; Distributed: Deploy Spinnaker with one server group per microservice, and a single shared Redis. LocalDebian: Download and run the Spinnaker debians on the machine running the Daemon. LocalGit: Download and run the Spinnaker git repos on the machine running the Daemon.
accountName: The Spinnaker account that Spinnaker will be deployed to, assuming you are running a deployment of Spinnaker that requires an active cloud provider.
imageVariant: The container image variant type to use when deploying a distributed installation of Spinnaker. SLIM: Based on an Alpine image ubuntu: Based on Canonical’s ubuntu:bionic image. JAVA8: A variant of slim that uses the Java 8 runtime. UBUNTU-JAVA8: A variant of ubuntu that uses the Java 8 runtime Default value: SLIM
bootstrapOnly: true or false; a bootstrap-only account is the account in which Spinnaker itself is deployed. When true, this account will not be included the accounts managed by Spinnaker.
updateVersions: true or false; when set to “false”, any local version of Spinnaker components will be used instead of attempting to update. This does not work for distributed installations of Spinnaker, where no local version exists.
consul:
- enabled: true or false; whether or not to use Consul as a service discovery mechanism to deploy Spinnaker.
- address: The address of a running Consul cluster. This is only required when Spinnaker is being deployed in non-Kubernetes clustered configuration.
vault:
- enabled: true or false; whether or not to use Vault as a secret storage mechanism to deploy Spinnaker.
- address: The address of a running Vault datastore. This is only required when Spinnaker is being deployed in non-Kubernetes clustered configuration.
location: This is the location spinnaker will be deployed to. When deploying to Kubernetes, use this flag to specify the namespace to deploy to (defaults to spinnaker)
customSizing: Configure, validate, and view the component sizings for the Spinnaker services. Example above only lists clouddriver as an option, but other services can be defined, e.g. echo. Note that if you want to define the sizing for the entire service including sidecars, the definition should be in the spin-$SERVICE format. If only the main container should be defined, use $SERVICE for the definition instead.
- spin-clouddriver:
  - replicas: Set the number of replicas (pods) to be created for this service.
  - requests:
    - memory: Sets the memory request for the container running the spinnaker service. Examples: 512Mi, 8Gi
    - cpu: Sets the cpu request for the container running the spinnaker service. Example: 250m.
- limits:
  - memory: example: 8Gi
  - cpu: example: 250m
sidecars:
- clouddriver:
  - name:
  - dockerImage:
  - port:
  - env:
    - key: definition
  - args:
    - arg1
  - command:
    - arg1
  - configMapVolumeMounts:
    - configMapName:
    - mountPath:
  - secretVolumeMounts:
    - secretName:
    - mountPath:
  - mountPath:
  - securityContext:
    - privileged: true or false.
initContainers: {}
hostAliases: {}
nodeSelectors:
- key: definition
affinity: {}
tolerations:
- clouddriver:`
  - key:
  - operator: Exists, Equal, or DoesNotExist
  - value:
  - effect:
gitConfig:
- upstreamUser: This is the upstream git user you are configuring to pull changes from & push PRs to.
- originUser: This is the git user your github fork exists under.
livenessProbeConfig:
- enabled: true or false; when true, enable Kubernetes liveness probes on Spinnaker services deployed in a Distributed installation. See docs for more information.
- initialDelaySeconds: The number of seconds to wait before performing the first liveness probe. Should be set to the longest service startup time. See docs for more information.
haServices:
- clouddriver:
  - enabled: true or false.
  - disableClouddriverRoDeck: true or false.
  - redisMasterEndpoint: Set external Redis endpoint for clouddriver-rw and clouddriver-caching. The Redis URI schema is described here. clouddriver-rw and clouddriver-caching are configured to use the shared Redis, by default.
  - redisSlaveEndpoint: Set external Redis endpoint for clouddriver-ro. The Redis URI schema is described here. clouddriver-ro is configured to use the shared Redis, by default.
  - redisSlaveDeckEndpoint: Set external Redis endpoint for clouddriver-ro-deck. The Redis URI schema is described here. clouddriver-ro-deck is configured to use the shared Redis, by default.
- echo:
  - enabled: true or false.

Kustomize patch examples

You can see examples in the spinnaker-kustomize-patches repo’s spinnaker_deployment folder.

Continuous-Deployment: Features Config

Mon, 01 Jan 0001 00:00:00 +0000

spec.spinnakerConfig.config.features

features:
 artifacts:
 auth:
 fiat:
 chaos:
 entityTags:
 pipelineTemplates:
 artifactsRewrite:
 mineCanary:
 appengineContainerImageUrlDeployments:
 infrastructureStages:
 travis:
 wercker:
 managedPipelineTemplatesV2UI:
 gremlin:

artifacts: true or false. Enable artifact support.
auth: true or false.
fiat: true or false.
chaos: true or false. Enable Chaos Monkey support. For this to work, you’ll need a running Chaos Monkey deployment. Currently, Halyard doesn’t configure Chaos Monkey for you.
entityTags: true or false.
pipelineTemplates: true or false. Enable pipeline template support.
artifactsRewrite: true or false. Enable new artifact support.
mineCanary: true or false. Enable Canary support. For this to work, you’ll need a Canary judge configured. Currently, Halyard does not configure Canary judge for you.
appengineContainerImageUrlDeployments: true or false. Enable appengine deployments using a container image URL from gcr.io.
infrastructureStages: true or false. Enable infrastructure stages. Allows for creating Load Balancers as part of pipelines.
travis: true or false. Enable the Travis CI stage.
wercker: true or false. Enable the Wercker CI stage.
managedPipelineTemplatesV2UI: true or false. Enable managed pipeline templates v2 UI support.
gremlin: true or false. Enable Gremlin fault-injection support.

Continuous-Deployment: Install Armory Continuous Deployment from the AWS Container Marketplace

Mon, 01 Jan 0001 00:00:00 +0000

Note

This document is intended for users who have purchased Armory’s AWS Container Marketplace offering. It will not work if you have not subscribed to the Armory Container Marketplace offering.

Please contact Armory if you’re interested in an AWS Marketplace Private Offer.

Overview of the Armory Operator

The Armory Operator is a Kubernetes Operator for Spinnaker^TM that makes it easier to install, deploy, and upgrade Spinnaker or Armory. The AWS Container Marketplace offering for Armory installs a version of the Armory Operator in an EKS cluster. After that, Armory can be installed in any namespace in your EKS cluster; this document assumes that Armory will be installed in the spinnaker namespace.

AWS Resources

Before you install Armory on AWS, it is essential that you familiarize yourself with relevant AWS services.

Prerequisites for using the Armory Operator

To use the Marketplace’s Armory offering, make sure you meet the following requirements:

You have reviewed and met the Armory Continuous Deployment system requirements.
You have access to an EKS cluster configured with IAM roles for service accounts.
You have an ingress controller for your EKS cluster. This document assumes the EKS cluster is using the NGINX Ingress Controller.
You have cluster-admin access on the EKS cluster.
You have An AWS S3 bucket to store Armory application and pipeline configuration.

Installation summary

This document covers the following high-level steps:

Creating and configuring the necessary AWS IAM roles for your Kubernetes cluster
Installing the Armory Operator Custom Resource Definitions (CRDs) for Armory into your Kubernetes cluster
Installing the Armory Operator
Creating a SpinnakerService Custom Resource
Exposing your Armory instance

Create an AWS bucket

If you do not already have an AWS S3 bucket, create one with these settings:

Versioning turned on (“Keep all versions of an object in the same bucket”)
Default encryption turned on
All public access blocked

Create and configure the AWS IAM roles for your Kubernetes cluster

AWS IAM permissions are granted to Armory through the use of AWS’s IAM roles for Kubernetes Service Accounts. This feature must be enabled at a cluster level. You need to create three IAM roles:

An IAM role for the Armory Operator (spinnaker-operator ServiceAccount in spinnaker-operator namespace) that has these permissions:
- aws-marketplace:RegisterUsage
- s3:* on your AWS Bucket
An IAM role for the Front50 service (front50 ServiceAccount in the spinnaker namespace), that has these permissions:
- s3:* on your AWS Bucket
An IAM role for the Clouddriver service (clouddriver ServiceAccount in the spinnaker namespace). This IAM role does not require any explicit permissions. If you want Armory to deploy AWS resources (AWS EC2, AWS ECS, AWS Lambda, or other AWS EKS clusters), you can add these permissions later.
- AWS permissions are not needed to deploy to the EKS cluster where Spinnaker is installed.

Upon completion of this section, you should have these three IAM roles:

arn:aws:iam::AWS_ACCOUNT_ID:role/eks-spinnaker-operator granted to the Kubernetes Service Account system:serviceaccount:spinnaker-operator:spinnaker-operator
arn:aws:iam::AWS_ACCOUNT_ID:role/eks-spinnaker-front50 granted to the Kubernetes Service Account system:serviceaccount:spinnaker:front50
arn:aws:iam::AWS_ACCOUNT_ID:role/eks-spinnaker-clouddriver granted to the Kubernetes Service Account system:serviceaccount:spinnaker:clouddriver

IAM role for Armory Operator Pod

Create an IAM role for the Armory Operator pod (call it eks-spinnaker-operator) and configure it for use by EC2. You will replace the trust relationship later.

Grant the role the AWS managed policy AWSMarketplaceMeteringRegisterUsage.

Grant the role an inline policy granting permissions on your S3 bucket (replace BUCKET_NAME with the name of your bucket):

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": "s3:*",
 "Resource": [
 "arn:aws:s3:::BUCKET_NAME",
 "arn:aws:s3:::BUCKET_NAME/*"
 ]
 }
 ]
}

For example:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": "s3:*",
 "Resource": [
 "arn:aws:s3:::my-spinnaker-bucket",
 "arn:aws:s3:::my-spinnaker-bucket/*"
 ]
 }
 ]
}

Create this trust relationship on the IAM role, with these fields replaced:

replace AWS_ACCOUNT_ID with your AWS account ID
replace OIDC_PROVIDER with the “OpenID Connect provider URL” for your Kubernetes cluster (with the https:// removed)

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Principal": {
 "Federated": "arn:aws:iam::AWS_ACCOUNT_ID:oidc-provider/OIDC_PROVIDER"
 },
 "Action": "sts:AssumeRoleWithWebIdentity",
 "Condition": {
 "StringEquals": {
 "OIDC_PROVIDER:sub": "system:serviceaccount:spinnaker-operator:spinnaker-operator"
 }
 }
 }
 ]
}

For example:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Principal": {
 "Federated": "arn:aws:iam::111222333444:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/AAAABBBBCCCCDDDDEEEEFFFF00001111"
 },
 "Action": "sts:AssumeRoleWithWebIdentity",
 "Condition": {
 "StringEquals": {
 "oidc.eks.us-east-1.amazonaws.com/id/AAAABBBBCCCCDDDDEEEEFFFF00001111:sub": "system:serviceaccount:spinnaker-operator:spinnaker-operator"
 }
 }
 }
 ]
}

IAM role for Front50 Pod

Create an IAM role for the Armory Operator pod (call it eks-spinnaker-front50) and configure it for use by EC2. You will replace the trust relationship later.

Grant the role an inline policy granting permissions on your S3 bucket (replace BUCKET_NAME with the name of your bucket):

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": "s3:*",
 "Resource": [
 "arn:aws:s3:::BUCKET_NAME",
 "arn:aws:s3:::BUCKET_NAME/*"
 ]
 }
 ]
}

For example:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": "s3:*",
 "Resource": [
 "arn:aws:s3:::my-spinnaker-bucket",
 "arn:aws:s3:::my-spinnaker-bucket/*"
 ]
 }
 ]
}

Create this trust relationship on the IAM role, with these fields replaced:

Replace AWS_ACCOUNT_ID with your AWS account ID
Replace OIDC_PROVIDER with the “OpenID Connect provider URL” for your Kubernetes cluster (with the https:// removed)

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Principal": {
 "Federated": "arn:aws:iam::AWS_ACCOUNT_ID:oidc-provider/OIDC_PROVIDER"
 },
 "Action": "sts:AssumeRoleWithWebIdentity",
 "Condition": {
 "StringEquals": {
 "OIDC_PROVIDER:sub": "system:serviceaccount:spinnaker:front50"
 }
 }
 }
 ]
}

For example:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Principal": {
 "Federated": "arn:aws:iam::111222333444:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/AAAABBBBCCCCDDDDEEEEFFFF00001111"
 },
 "Action": "sts:AssumeRoleWithWebIdentity",
 "Condition": {
 "StringEquals": {
 "oidc.eks.us-east-1.amazonaws.com/id/AAAABBBBCCCCDDDDEEEEFFFF00001111:sub": "system:serviceaccount:spinnaker:front50"
 }
 }
 }
 ]
}

IAM role for Clouddriver pod

Create an IAM role for the Armory Operator pod (call it eks-spinnaker-clouddriver) and configure it for use by EC2. You will replace the trust relationship later. It does not need explicit AWS permissions.

Create this trust relationship on the IAM role, with these fields replaced:

Replace AWS_ACCOUNT_ID with your AWS account ID
Replace OIDC_PROVIDER with the “OpenID Connect provider URL” for your Kubernetes cluster (with the https:// removed)

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Principal": {
 "Federated": "arn:aws:iam::AWS_ACCOUNT_ID:oidc-provider/OIDC_PROVIDER"
 },
 "Action": "sts:AssumeRoleWithWebIdentity",
 "Condition": {
 "StringEquals": {
 "OIDC_PROVIDER:sub": "system:serviceaccount:spinnaker:clouddriver"
 }
 }
 }
 ]
}

For example:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Principal": {
 "Federated": "arn:aws:iam::111222333444:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/AAAABBBBCCCCDDDDEEEEFFFF00001111"
 },
 "Action": "sts:AssumeRoleWithWebIdentity",
 "Condition": {
 "StringEquals": {
 "oidc.eks.us-east-1.amazonaws.com/id/AAAABBBBCCCCDDDDEEEEFFFF00001111:sub": "system:serviceaccount:spinnaker:clouddriver"
 }
 }
 }
 ]
}

Install the Armory Operator Custom Resource Definitions (CRDs)

Download the Kubernetes manifest for Armory Operator and install it into your Kubernetes cluster:

mkdir -p spinnaker-operator && cd spinnaker-operator
bash -c 'curl -L https://github.com/armory/marketplace/releases/latest/download/marketplace.tgz | tar -xz'

# Install or update CRDs cluster wide
kubectl apply -f manifests/crds/

Install the Armory Operator

Update the manifest for the Armory Operator with your AWS Account ID:

You must update AWS_ACCOUNT_ID (in the ServiceAccount annotation) with your account ID, so the ServiceAccount can access your AWS IAM roles.

export AWS_ACCOUNT_ID=111122223333

sed -i.bak "s|AWS_ACCOUNT_ID|${AWS_ACCOUNT_ID}|g" manifests/operator/ServiceAccount.yaml
rm manifests/operator/ServiceAccount.yaml.bak

# Install the armory operator
kubectl apply -f manifests/operator

Deploying the Armory Operator may take a little bit of time. You can monitor its status by running this command:

kubectl -n spinnaker-operator get pod -owide

You’re looking for the deployment to be completely up (READY of 2/2 and STATUS of Running).

Creating a SpinnakerService Custom Resource

Update the manifest for the SpinnakerService object with these:

AWS_ACCOUNT_ID (in both ServiceAccount annotations) - your account ID, so the ServiceAccount can access your AWS IAM roles
BUCKET_NAME (in the SpinnakerService) - the name of your AWS S3 Bucket

export AWS_ACCOUNT_ID=111122223333
export BUCKET_NAME=my-spinnaker-bucket

sed -i.bak "s|AWS_ACCOUNT_ID|${AWS_ACCOUNT_ID}|g" manifests/spinnaker/ServiceAccount-clouddriver.yaml
sed -i.bak "s|AWS_ACCOUNT_ID|${AWS_ACCOUNT_ID}|g" manifests/spinnaker/ServiceAccount-front50.yaml
rm manifests/spinnaker/ServiceAccount-clouddriver.yaml.bak
rm manifests/spinnaker/ServiceAccount-front50.yaml.bak

sed -i.bak "s|BUCKET_NAME|${BUCKET_NAME}|g" manifests/spinnaker/SpinnakerService.yaml
rm manifests/spinnaker/SpinnakerService.yaml.bak

# Install the operator
kubectl apply -f manifests/spinnaker

If everything is configured properly, the Armory Operator should see the SpinnakerService custom resource, and start creating Kubernetes Deployments, ServiceAccounts, and Secrets in the spinnaker Namespace. You can monitor this with the following:

kubectl -n spinnaker get all -owide

Exposing your Armory instance

Once your Armory instance is running, you need to configure it so that it is accessible. There are two main parts to this:

Expose the spin-deck and spin-gate services so that they can be reached by your end users (and client services)
Configure Armory so that it knows about the endpoints it is exposed on

Given a domain name (or IP address) (such as spinnaker.domain.com or 55.55.55.55), you should be able to:

Reach the spin-deck service at the root of the domain (http://spinnaker.domain.com or http://55.55.55.55)
Reach the spin-gate service at the root of the domain (http://spinnaker.domain.com/api/v1 or http://55.55.55.55/api/v1)

You can use either http or https, as long as you use the same for both. Additionally, you have to configure Armory to be aware of its endpoints.

This section assumes the following:

You have installed the NGINX Ingress Controller in the EKS cluster
You can set up a DNS CNAME Record pointing at the AWS Load Balancer in front of your NGINX Ingress Controller

Set up an Ingress for `spin-deck` and `spin-gate`

First, determine a DNS name that you can use for Armory, and set up a CNAME pointing that DNS name at your AWS Load Balancer. For example:

NGINX Ingress Controller has created an NLB at abcd1234abcd1234abcd1234abcd1234-1234567812345678.elb.us-east-1.amazonaws.com
Desired domain name for Armory is spinnaker.domain.com
Create a CNAME DNS Record pointing spinnaker.domain.com at abcd1234abcd1234abcd1234abcd1234-1234567812345678.elb.us-east-1.amazonaws.com (you may also use an ALIAS Record in Route 53)

Then, create a Kubernetes Ingress to expose spin-deck and spin-gate. Create a file called spin-ingress.yml with the following content:

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
 name: spin-ingress
 namespace: spinnaker
 labels:
 app: spin
 cluster: spin-ingress
 annotations:
 kubernetes.io/ingress.class: "nginx"
spec:
 rules:
 -
 host: spinnaker.domain.com # Make sure to update this field
 http:
 paths:
 - backend:
 serviceName: spin-deck
 servicePort: 9000
 path: /
 - backend:
 serviceName: spin-gate
 servicePort: 8084
 path: /api/v1

Make sure the host field is updated with the correct DNS record.

Apply the ingress file you just created:

kubectl -n spinnaker apply -f spin-ingress.yml

Configure Armory to be aware of its endpoints

Update the spec.spinnakerConfig.config.security section of manifests/spinnaker/SpinnakerService.yaml:

spec:
 spinnakerConfig:
 config:
 # ... more configuration
 security:
 uiSecurity:
 overrideBaseUrl: http://spinnaker.domain.com # Replace this with the IP address or DNS that points to our nginx ingress instance
 apiSecurity:
 overrideBaseUrl: http://spinnaker.domain.com/api/v1 # Replace this with the IP address or DNS that points to our nginx ingress instance
 # ... more configuration

Make sure to specify http or https according to your environment

Apply the changes:

kubectl apply -f manifests/spinnaker/SpinnakerService.yaml

If you encounter an error, delete and recreate the SpinnakerService.

Configure TLS certificates

Configuring TLS certificates for ingresses is environment-specific. In general, you want to do the following:

Add certificate(s) so that our ingress controller can use them
Configure the ingress(es) so that NGINX (or the load balancer in front of NGINX, or your alternative ingress controller) terminates TLS using the certificate(s)
Update Spinnaker to be aware of the new TLS endpoints, by replacing http by https to override the base URLs in the previous section.

Next steps

Now that Armory is running, here are potential next steps:

Configure certificates to secure our cluster (see this section for notes on this)
Configure authentication/authorization (see the Open Source Spinnaker documentation)
Add external Kubernetes accounts to deploy applications to (see Creating and Adding a Kubernetes Account to Spinnaker (Deployment Target))
Add AWS accounts to deploy applications to (see the Open Source Spinnaker documentation)

Continuous-Deployment: Metric Stores Config

Mon, 01 Jan 0001 00:00:00 +0000

spec.spinnakerConfig.config.metricStores

Metrics stores are used to store metrics for the various Spinnaker micro-services. These metrics are not related in any way to Canary deployments. The technologies backing both are similar, but metric stores are places to push metrics regarding Spinnaker metrics, whereas Canary metrics stores are used to pull metrics to analyze deployments. This configuration only affects the publishing of metrics against whichever metric stores you enable (it can be more than one).

metricStores:
 enabled:
 period:
 prometheus:
 push_gateway:
 add_source_metalabels:
 enabled:
 datadog:
 enabled:
 api_key:
 app_key:
 tags:
 - tag1
 stackdriver:
 enabled:
 credentials_path:
 project:
 instance_id:
 newrelic:
 enabled:
 insert_key:
 host:
 tags:
 - tag1

enabled: true or false.
period: Set the polling period for the monitoring daemon, e.g. 30
prometheus: Prometheus configuration
datadog: Datadog configuration
stackdriver: Stackdriver configuration
newrelic: New Relic configuration

Prometheus

push_gateway: The endpoint the monitoring Daemon should push metrics to. If you have configured Prometheus to automatically discover all your Spinnaker services and pull metrics from them this is not required.
add_source_metalabels: true or false.
enabled: true or false.

Datadog

enabled: true or false.
api_key: Your datadog API key. Supports encrypted value.
app_key: Your datadog app key. This is only required if you want Spinnaker to push preconfigured Spinnaker dashboards to your Datadog account. Supports encrypted value.
tags: Your datadog custom tags. Please delimit the KVP with colons, e.g. app:test env:dev

Stackdriver

enabled: true or false.
credentials_path: A path to a Google JSON service account that has permission to publish metrics. File needs to be present on the machine running Spinnaker. Supports encrypted file.
project: The project Spinnaker’s metrics should be published to.
zone: The zone Spinnaker’s metrics should be associated with.
instance_id:

New Relic

enabled: true or false.
insert_key: Your New Relic Insights insert key. Supports encrypted value.
host: The URL to post metric data to. In almost all cases, this is set correctly by default and should not be used.
tags: Your custom tags. Please delimit the KVP with colons, e.g. app:test env:dev

Kustomize patch examples

You can see examples in the spinnaker-kustomize-patches repo’s metric-stores folder.

Continuous-Deployment: Notification Config

Mon, 01 Jan 0001 00:00:00 +0000

spec.spinnakerConfig.config.notifications

notifications:
 slack:
 enabled:
 botName:
 token:
 baseUrl:
 forceUseIncomingWebhook:
 twilio:
 enabled:
 account:
 baseUrl:
 from:
 token:
 github-status:
 enabled:
 token:
 enabled:

Slack parameters

enabled: true or false.
botName: The name of your Slack bot.
token: Your Slack bot token. Supports encrypted value.
baseUrl: Slack endpoint. Optional, only set if using a compatible API.
forceUseIncomingWebhook: true or false. Force usage of incoming webhooks endpoint for Slack. Optional, only set if using a compatible API.

Twilio parameters

enabled: true or false.
account: Your Twilio account SID.
baseUrl: Twilio REST API base url
from: The phone number from which the SMS will be sent (e.g. +1234-567-8910).
token: Your Twilio auth token. Supports encrypted value.

GitHub status parameters

enabled: true or false.
token: Your GitHub account token. Supports encrypted value.

Kustomize patch examples

You can see examples in the spinnaker-kustomize-patches repo’s notifications folder.

Continuous-Deployment: Persistent Storage Config

Mon, 01 Jan 0001 00:00:00 +0000

spec.spinnakerConfig.config.persistentStorage

persistentStorage:
 persistentStoreType: s3
 azs:
 gcs:
 oracle:
 s3:

persistentStorageType: one of azs, gcs, oracle, s3; the configured storage type for Spinnaker to use
azs: Azure persistent storage configuration
gcs: Google Cloud persistent storage configuration
oracle: Oracle persistent storage configuration
s3: Amazon s3 persistent storage configuration

Azure

azs:
 storageAccountName:
 storageAccountKey:
 storageContainerName:

storageAccountName: The name of an Azure Storage Account used for Spinnaker’s persistent data.
storageAccountKey: The key to access the Azure Storage Account used for Spinnaker’s persistent data. Supports encrypted value.
storageContainerName: (Default: spinnaker) The container name in the chosen storage account to place all of Spinnaker’s persistent data.

GCS

gcs:
 jsonPath:
 project:
 bucket:
 rootFolder:
 bucketLocation:

jsonPath: A path to a JSON service account with permission to read and write to the bucket to be used as a backing store. File needs to be present on the machine running Spinnaker. Supports encrypted file.
project: The Google Cloud Platform project you are using to host the GCS bucket as a backing store.
bucket: The name of a storage bucket that your specified account has access to. If not specified, a random name will be chosen. If you specify a globally unique bucket name that doesn’t exist yet, Halyard will create that bucket for you.
rootFolder: The root folder in the chosen bucket to place all of Spinnaker’s persistent data in.
bucketLocation: This is only required if the bucket you specify doesn’t exist yet. In that case, the bucket will be created in that location. See https://cloud.google.com/storage/docs/managing-buckets#manage-class-location.

Oracle

oracle:
 bucketName:
 namespace:
 compartmentId:
 region:
 userId:
 fingerprint:
 sshPrivateKeyFilePath:
 privateKeyPassphrase:
 tenancyId:

bucketName: The bucket name to store persistent state object in
namespace: The namespace the bucket and objects should be created in
compartmentId: Provide the OCID of the Oracle Compartment to use.
region: An Oracle region (e.g., us-phoenix-1)
userId: Provide the OCID of the Oracle User you’re authenticating as
fingerprint: Fingerprint of the public key
sshPrivateKeyFilePath: Path to the private key in PEM format. File needs to be present on the machine running Spinnaker. Supports encrypted file.
privateKeyPassphrase: Passphrase used for the private key, if it is encrypted. Supports encrypted value.
tenancyId: Provide the OCID of the Oracle Tenancy to use.

S3

s3:
 bucket:
 rootFolder:
 region:
 pathStyleAccess:
 endpoint:
 accessKeyId:
 serverSideEncryption:
 secretAccessKey:

bucket: The name of a storage bucket that your specified account has access to. If not specified, a random name will be chosen. If you specify a globally unique bucket name that doesn’t exist yet, Operator will create that bucket for you.
rootFolder: The root folder in the chosen bucket to place all of Spinnaker’s persistent data in.
region: This is only required if the bucket you specify doesn’t exist yet. In that case, the bucket will be created in that region. See http://docs.aws.amazon.com/general/latest/gr/rande.html#s3_region.
pathStyleAccess: true or false; when true, use path-style to access bucket; when false, use virtual hosted-style to access bucket. See
endpoint: An alternate endpoint that your S3-compatible storage can be found at. This is intended for self-hosted storage services with S3-compatible APIs, e.g. Minio. If supplied, this storage type cannot be validated.
accessKeyId: Your AWS Access Key ID. If not provided, Halyard/Spinnaker will try to find AWS credentials as described at http://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/credentials.html#credentials-default
serverSideEncryption: Use Amazon Server-Side Encryption (‘x-amz-server-side-encryption’ header). Supports ‘AES256’ (for Amazon S3-managed encryption keys, equivalent to a header value of ‘AES256’) and ‘AWSKMS’ (for AWS KMS-managed encryption keys, equivalent to a header value of ‘aws:kms’.
secretAccessKey: Your AWS Secret Key. Supports encrypted value.

Kustomize patch examples

You can see examples in the spinnaker-kustomize-patches repo’s persistence folder.

Continuous-Deployment: Plugins Config

Mon, 01 Jan 0001 00:00:00 +0000

Warning

Please see Spinnaker’s Plugins User Guide for a detailed explanation of plugins.

Parameters

spec.spinnakerConfig.profiles

Put configuration in the service that the plugin extends. Only the impacted service will restart when you apply the manifest.

Example:

spec:
 # spec.spinnakerConfig - This section is how to specify configuration spinnaker
 spinnakerConfig:
 # spec.spinnakerConfig.config - This section contains the contents of a deployment found in a halconfig .deploymentConfigurations[0]
 profiles:
 orca:
 spinnaker:
 extensibility:
 plugins:
 <plugin-name>:
 enabled: <true-or-false>
 version: <version>
 config: {}
 repositories:
 <repository-name>:
 id:
 url:

plugins:
- <plugin-name>: suggested format is creator.plugin
  - id: plugin ID as defined in plugins.json
  - enabled: true or false
  - version: version of the plugin to use
  - config: {} - configuration for this specific plugin
repositories:
- <repository-name>:
  - id: same as
  - url: URL to repositories.json or plugins.json

See the Plugin Users Guide Add a plugin repository section for when you can use plugins.json instead of repositories.json.

Deck proxy

You need to configure a deck-proxy in Gate if your plugin has a Deck component. Locate the profiles section in your SpinnakerService.yml and add the proxy information to the gate section.

# spec.spinnakerConfig.profiles - This section contains the YAML of each service's profile
profiles:
clouddriver: {} # is the contents of ~/.hal/default/profiles/clouddriver.yml
# deck has a special key "settings-local.js" for the contents of settings-local.js
deck:
 # settings-local.js - contents of ~/.hal/default/profiles/settings-local.js
 # Use the | YAML symbol to indicate a block-style multiline string
 settings-local.js: |
 window.spinnakerSettings.feature.kustomizeEnabled = true;
 window.spinnakerSettings.feature.artifactsRewrite = true;
echo: {} # is the contents of ~/.hal/default/profiles/echo.yml
fiat: {} # is the contents of ~/.hal/default/profiles/fiat.yml
front50: {} # is the contents of ~/.hal/default/profiles/front50.yml
gate:
 spinnaker:
 extensibility:
 deck-proxy:
 enabled: true
 plugins:
 <plugin-name>:
 enabled: true
 version: <version>
 repositories:
 <repository-name>:
 url: <url-to-repositories.json-or-plugins.json>
igor: {} # is the contents of ~/.hal/default/profiles/igor.yml
kayenta: {} # is the contents of ~/.hal/default/profiles/kayenta.yml
orca: {} # is the contents of ~/.hal/default/profiles/orca.yml

Example

The example below configures the pf4jStagePlugin. The configured repository is a plugins.json file rather than a repositories.json file.

spec:
 spinnakerConfig:
 # spec.spinnakerConfig.profiles - This section contains the YAML of each service's profile
 profiles:
 gate:
 spinnaker:
 extensibility:
 deck-proxy: # you need this for plugins with a Deck component
 enabled: true
 plugins:
 Armory.RandomWaitPlugin:
 enabled: true
 version: 1.1.17
 repositories:
 examplePluginsRepo:
 url: https://raw.githubusercontent.com/spinnaker-plugin-examples/examplePluginRepository/master/plugins.json
 orca:
 spinnaker:
 extensibility:
 plugins:
 Armory.RandomWaitPlugin:
 enabled: true
 version: 1.1.17
 config:
 defaultMaxWaitTime: 15
 repositories:
 examplePluginsRepo:
 id: examplePluginsRepo
 url: https://raw.githubusercontent.com/spinnaker-plugin-examples/examplePluginRepository/master/plugins.json

Kustomize patch examples

You can see examples in the spinnaker-kustomize-patches repo’s plugins folder.

Continuous-Deployment: Providers Config

Mon, 01 Jan 0001 00:00:00 +0000

spec.spinnakerConfig.config.providers

providers:
 appengine:
 aws:
 ecs:
 dcos:
 dockerRegistry:
 google:
 huaweicloud:
 kubernetes:
 tencentcloud:
 oracle:
 cloudfoundry:

App Engine

spec.spinnakerConfig.config.providers.appengine

The App Engine provider is used to deploy resources to any number of App Engine applications. To get started with App Engine, visit the App Engine docs. An account in the App Engine provider refers to a single App Engine application. Spinnaker assumes that your App Engine application already exists.

appengine:
 enabled: false
 gcloudPath:
 accounts:
 - name: prod-1
 cachingIntervalSeconds:
 environment:
 gcloudReleaseTrack:
 gitHttpsUsername:
 gitHttpsPassword:
 githubOAuthAccessToken:
 jsonPath:
 localRepositoryDirectory:
 omitServices:
 omitVersions:
 permissions:
 READ:
 WRITE:
 EXECUTE:
 CREATE:
 project:
 providerVersion:
 requiredGroupMembership:
 sshPrivateKeyFilePath:
 sshPrivateKeyPassphrase:
 sshKnownHostsFilePath:
 sshTrustUnknownHosts:
 services:
 versions:
 primaryAccount:

enabled:
accounts:
gCloudPath: The path to the gcloud executable on the machine running clouddriver. Ex: /root
primaryAccount:

Account parameters

cachingIntervalSeconds: The interval in seconds at which Spinnaker will poll for updates in your AppEngine clusters.
environment: The environment name for the account. Many accounts can share the same environment (e.g. dev, test, prod)
gcloudReleaseTrack: The gcloud release track (ALPHA, BETA, or STABLE) that Spinnaker will use when deploying to App Engine.
gitHttpsPassword: A password to be used when connecting with a remote git repository server over HTTPS. Supports encrypted value.
gitHttpsUsername: A username to be used when connecting with a remote git repository server over HTTPS.
githubOAuthAccessToken: An OAuth token provided by Github for connecting to a git repository over HTTPS. See Creating an Access Token for Command Line Use for more information. Supports encrypted value.
json-path: The path to a JSON service account that Spinnaker will use as credentials. This is only needed if Spinnaker is not deployed on a Google Compute Engine VM, or needs permissions not afforded to the VM it is running on. See Service Accounts for more information.
localRepositoryDirectory: A local directory to be used to stage source files for App Engine deployments within Spinnaker’s Clouddriver microservice.
omitServices: A list of regular expressions. Any service matching one of these regexes will be ignored by Spinnaker.
omitVersions: A list of regular expressions. Any version matching one of these regexes will be ignored by Spinnaker.
permissions:
- READ: [] A user must have at least one of these roles in order to view this account’s cloud resources.
- WRITE: [] A user must have at least one of these roles in order to make changes to this account’s cloud resources.
- EXECUTE:
- CREATE:
project: (Required) The Google Cloud Platform project this Spinnaker account will manage.
providerVersion:
requiredGroupMembership: (Default: []) A user must be a member of at least one specified group in order to make changes to this account’s cloud resources.
services: A list of regular expressions. Any service matching one of these regexes will be indexed by Spinnaker.
sshKnownHostsFilePath: The path to a known_hosts file to be used when connecting with a remote git repository over SSH. File needs to be present on the machine running Spinnaker. Supports encrypted file.
sshPrivateKeyFilePath: The path to an SSH private key to be used when connecting with a remote git repository over SSH. File needs to be present on the machine running Spinnaker. Supports encrypted file.
sshPrivateKeyPassphrase: The passphrase to an SSH private key to be used when connecting with a remote git repository over SSH. Supports encrypted value.
sshTrustUnknownHosts: (Default: false) Enabling this flag will allow Spinnaker to connect with a remote git repository over SSH without verifying the server’s IP address against a known_hosts file.
versions: A list of regular expressions. Any version matching one of these regexes will be indexed by Spinnaker.

AWS

spec.spinnakerConfig.config.providers.aws

aws:
 enabled: false
 accessKeyId:
 defaults:
 iamRole: BaseIAMRole
 defaultAssumeRole:
 defaultKeyPairTemplate:
 defaultRegions:
 - name:
 primaryAccount:
 secretAccessKey:
 accounts:
 - name: aws-dev
 accountId:
 assumeRole:
 edda:
 environment:
 defaultKeyPair:
 discovery:
 lifecycleHooks:
 - defaultResult:
 heartbeatTimeout:
 lifecycleTransition:
 notificationTargetARN:
 roleARN:
 permissions:
 READ:
 WRITE:
 EXECUTE:
 CREATE:
 providerVersion: V1
 regions:
 - name:
 requiredGroupMembership:
 externalId:
 bakeryDefaults:
 awsAccessKey:
 awsAssociatePublicIpAddress:
 awsSecretKey:
 awsSubnetId:
 awsVpcId:
 defaultVirtualizationType:
 baseImages:
 - baseImage:
 id:
 shortDescription:
 detailedDescription:
 packageType:
 templateFile:
 virtualizationSettings:
 - region:
 virtualizationType:
 instanceType:
 sourceAmi:
 sshUserName:
 winRmUserName:
 spotPrice:
 spotPriceAutoProduct:
 templateFile:
 features:
 cloudFormation:
 enabled:

The AWS provider requires a central “Managing Account” to authenticate on behalf of other AWS accounts, or act as your sole, credential-based account.

enabled: whether the provider is enabled
accessKeyId: AWS Access Key ID; note that if you are baking AMIs via Rosco, you may also need to set the access key on the AWS bakery default options.
accounts: list of configured accounts
bakeryDefaults: configuration for Spinnaker’s image bakery.Configuration for Spinnaker’s image bakery.
defaults: array with single entry:
- iamRole: BaseIAMRole
defaultKeyPairTemplate: “{{name}}-keypair”
defaultRegions: array of name: <region-name> items
features: configuration for AWS-specific features
primaryAccount: the account you want to be primary of the configured accounts
secretAccessKey: AWS Secret Key; note that if you are baking AMIs via Rosco, you may also need to set the secret key on the AWS bakery default options. Supports encrypted value.

Account parameters

accountId: (Required) Your AWS account ID to manage. See the AWS IAM User Guide for more information.
assumeRole: (Required) If set, will configure a credentials provider that uses AWS Security Token Service to assume the specified role. Example: “user/spinnaker” or “role/spinnakerManaged”
defaultKeyPair: The name of the AWS key-pair to use. See http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html for more information.
discovery: The endpoint at which your Eureka discovery system is reachable. See https://github.com/Netflix/eureka for more information. Example: http://.eureka.url.to.use:8080/eureka-server/v2. Using will make Spinnaker use AWS regions in the hostname to access discovery so that you can have discovery for multiple regions.
edda: The endpoint at which Edda is reachable. Edda is not a hard dependency of Spinnaker, but is helpful for reducing the request volume against AWS. See https://github.com/Netflix/edda for more information.
environment: The environment name for the account. Many accounts can share the same environment (e.g. dev, test, prod)
lifecycleHooks: Configuration for AWS Auto Scaling Lifecycle Hooks. For more information, see: https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html
- defaultResult: Defines the action the Auto Scaling group should take when the lifecycle hook timeout elapses or if an unexpected failure occurs. Acceptable values: CONTINUE, ABANDON.
- heartbeatTimeout: Set the heartbeat timeout in seconds for the lifecycle hook. Instances can remain in a wait state for a finite period of time. Must be greater than or equal to 30 and less than or equal to 7200. The default is 3600 (one hour).
- lifecycleTransition: Type of lifecycle transition. Acceptable values: autoscaling:EC2_INSTANCE_LAUNCHING, autoscaling:EC2_INSTANCE_TERMINATING
- notificationTargetARN: The ARN of the notification target that Amazon EC2 Auto Scaling uses to notify you when an instance is in the transition state for the lifecycle hook. This target can be either an SQS queue or an SNS topic.
- roleARN: The ARN of the IAM role that allows the Auto Scaling group to publish to the specified notification target, for example, an Amazon SNS topic or an Amazon SQS queue.
permissions:
- READ: [] A user must have at least one of these roles in order to view this account’s cloud resources.
- WRITE: [] A user must have at least one of these roles in order to make changes to this account’s cloud resources.
- EXECUTE: A user must have at least one of these roles in order to execute pipelines.
- CREATE:
providerVersion:
regions: (Default: []) The AWS regions this Spinnaker account will manage.
requiredGroupMemberships: (Deprecated): Configure permissions instead.
externalId: Optional parameter used to identify and control access to AWS resources. Set this to the same value as the ExternalID parameter in the trust policy for the role you want to assume.

Bakery parameters

awsAccessKey: The default access key used to communicate with AWS.
awsAssociatePublicIpAddress: If using a non-default VPC, public IP addresses are not provided by default. If this is enabled, your new instance will get a Public IP.
awsSecretKey: The secret key used to communicate with AWS. Supports encrypted value.
awsSubnetId: If using VPC, the default ID of the subnet, such as subnet-12345def, where Packer will launch the EC2 instance. This field is required if you are using a non-default VPC.
awsVpcId: If launching into a VPC subnet, Packer needs the VPC ID in order to create a temporary security group within the VPC. Requires subnet_id to be set. If this default value is left blank, Packer will try to get the VPC ID from the subnet_id.
baseImages: []
defaultVirtualizationType: The default type of virtualization for the AMI you are building. This option must match the supported virtualization type of source_ami. Can be pv or hvm.
templateFile: This is the name of the packer template that will be used to bake images from this base image. The template file must be found in this list, or supplied as described in the bakery docs

Bakery base image parameters

detailedDescription: A long description to help human operators identify the image.
id:This is the identifier used by AWS to find this base image.
shortDescription:A short description to help human operators identify the image.
detailedDescription:A long description to help human operators identify the image.
packageType:This is used to help Spinnaker’s bakery download the build artifacts you supply it with. For example, specifying deb indicates that your artifacts will need to be fetched from a debian repository.
templateFile: The name of the Packer template that will be used to bake images from this base image. The template file must be found in this list: https://github.com/spinnaker/rosco/tree/master/rosco-web/config/packer, or supplied as described here: https://spinnaker.io/setup/bakery/.
virtualizationSettings:
- region:The name of the region in which to launch the EC2 instance to create the AMI.
- virtualizationType: The type of virtualization for the AMI you are building. This option must match the supported virtualization type of sourceAmi. Acceptable values: pv, hvm.
- instanceType: The EC2 instance type to use while building the AMI, such as t2.small.
- sourceAmi:The source AMI whose root volume will be copied and provisioned on the currently running instance. This must be an EBS-backed AMI with a root volume snapshot that you have access to.
- sshUserName:The username to connect to SSH with. Required if using SSH.
- winRmUserName:The username to use to connect to WinRM.
- spotPrice:The maximum hourly price to pay for a spot instance to create the AMI. Spot instances are a type of instance that EC2 starts when the current spot price is less than the maximum price you specify. Spot price will be updated based on available spot instance capacity and current spot instance requests. It may save you some costs. You can set this to auto for Packer to automatically discover the best spot price or to “0” to use an on demand instance (default).
- spotPriceAutoProduct:Required if spotPrice is set to auto. This tells Packer what sort of AMI you are launching to find the best spot price. This must be one of: Linux/UNIX, SUSE Linux, Windows, Linux/UNIX (Amazon VPC), SUSE Linux (Amazon VPC), Windows (Amazon VPC).

Features parameters

cloud-formation: (Required) Enable CloudFormation support for AWS.

Azure

spec.spinnakerConfig.config.providers.azure

azure:
 enabled: false
 primaryAccount: azure-dev
 accounts:
 - name: azure-dev
 appKey:
 clientId:
 defaultKeyVault:
 defaultResourceGroup:
 environment:
 objectId:
 packerResourceGroup:
 packerStorageAccount:
 permissions:
 READ:
 WRITE:
 EXECUTE:
 CREATE:
 providerVersion: V1
 regions:
 - name:
 requiredGroupMembership:
 subscriptionId:
 tenantId:
 useSshPublicKey:
 bakeryDefaults:
 templateFile:
 baseImages:
 - baseImage:
 id:
 detailedDescription:
 packageType:
 publisher:
 offer:
 shortDescription:
 templateFile:
 sku:
 version:
 virtualizationSettings: {}

enabled: whether the provider is enabled
primaryAccount: name of primary account
accounts: list of configured accounts
bakeryDefaults: configuration for Spinnaker’s image bakery

Account parameters

appKey: (Required) The appKey (password) of your service principal. Supports encrypted value.
clientId: (Required) The clientId (also called appId) of your service principal.
defaultKeyVault: (Required) The name of a KeyVault that contains the user name, password, and ssh public key used to create VMs
defaultResourceGroup: (Required) The default resource group to contain any non-application specific resources.
environment: The environment name for the account. Many accounts can share the same environment (e.g. dev, test, prod)
objectId: The objectId of your service principal. This is only required if using Packer to bake Windows images.
packerResourceGroup: The resource group to use if baking images with Packer.
packerStorageAccount: The storage account to use if baking images with Packer.
permissions:
- READ: [] A user must have at least one of these roles in order to view this account’s cloud resources.
- WRITE: [] A user must have at least one of these roles in order to make changes to this account’s cloud resources.
- EXECUTE:
- CREATE:
regions: The Azure regions this Spinnaker account will manage.
requiredGroupMembership: (Deprecated): Configure permissions instead.
subscriptionId: (Required) The subscriptionId that your service principal is assigned to.
tenantId: (Required) The tenantId that your service principal is assigned to.
useSshPublicKey: Whether to use SSH public key to provision the linux vm. The default value is true which means using the ssh public key. Setting it to false means using the password instead.

Bakery parameters

templateFile: his is the name of the packer template that will be used to bake images from this base image. The template file must be found in this list, or supplied as described in the bakery docs

Bakery base image parameters

detailedDescription: A long description to help human operators identify the image.
offer: (Required) The offer for your base image. See https://aka.ms/azspinimage to get a list of images.
packageType: This is used to help Spinnaker’s bakery download the build artifacts you supply it with. For example, specifying ‘deb’ indicates that your artifacts will need to be fetched from a debian repository.
publisher: (Required) The Publisher name for your base image. See https://aka.ms/azspinimage to get a list of images.
shortDescription: A short description to help human operators identify the image.
sku: (Required) The SKU for your base image. See https://aka.ms/azspinimage to get a list of images.
templateFile: This is the name of the packer template that will be used to bake images from this base image. The template file must be found in this list https://github.com/spinnaker/rosco/tree/master/rosco-web/config/packer, or supplied as described here: https://spinnaker.io/setup/bakery/
version: The version of your base image. This defaults to ’latest’ if not specified.

Cloud Foundry

spec.spinnakerConfig.config.providers.cloudfoundry

cloudfoundry:
 enabled: false
 accounts:
 - name: cf-dev
 apiHost:
 appsManagerUrl:
 environment:
 metricsUrl:
 providerVersion: V1
 password:
 permissions:
 READ:
 WRITE:
 EXECUTE:
 CREATE:
 requiredGroupMembership:
 skipSslValidation:
 user:
 primaryAccount: cf-dev

enabled: whether the provider is enabled
primaryAccount: name of primary account
accounts: list of configured accounts

Account parameters

apiHost: (Required) Host of the CloudFoundry Foundation API endpoint ie. api.sys.somesystem.com
appsManagerUrl: HTTP(S) URL of the Apps Manager application for the CloudFoundry Foundation. Example: https://apps.sys.somesystem.com
environment: The environment name for the account. Many accounts can share the same environment (e.g. dev, test, prod)
metricsUrl: HTTP(S) URL of the metrics application for the CloudFoundry Foundation. Example https://metrics.sys.somesystem.com
password: (Required) Password for the account to use on for this CloudFoundry Foundation. Supports encrypted value.
permissions:
- READ: [] A user must have at least one of these roles in order to view this account’s cloud resources.
- WRITE: [] A user must have at least one of these roles in order to make changes to this account’s cloud resources.
- EXECUTE:
- CREATE:
requiredGroupMembership: [] (Deprecated): Configure permissions instead.
skipSslValidation: (Default: false) Skip SSL server certificate validation of the API endpoint
user: (Required) User name for the account to use on for this CloudFoundry Foundation

DC/OS

spec.spinnakerConfig.config.providers.dcos

dcos:
 enabled: false
 accounts:
 - name: dcos-dev
 clusters:
 - name:
 password:
 serviceKeyFile:
 uid:
 dockerRegistries:
 - accountName:
 namespaces:
 environment:
 permissions:
 READ:
 WRITE:
 EXECUTE:
 CREATE:
 providerVersion: V1
 requiredGroupMembership:
 clusters:
 - name:
 caCertFile:
 dcosUrl:
 insecureSkipTlsVerify:
 loadBalancer:
 image:
 serviceAccountSecret:
 primaryAccount:

enabled: Whether the provider is enabled.
accounts: the list of configured accounts
primaryAccount: The name of the primary account.
clusters: the list of configured clusters

Accounts parameters

clusters: (Required) The clusters against which this account will authenticate.
- name: (Required) The name of the account.
- password: Password for a user account. If set, serviceKeyFile should not be set. Supports encrypted value.
- serviceKeyFile: Path to a file containing the secret key for service account authentication. If set, password should not be set. File needs to be present on the machine running Spinnaker. Supports encrypted file.
- uid: (Required) User or service account identifier.
dockerRegistries: []; (Required) Provide the list of docker registries to use with this DC/OS account
environment: The environment name for the account. Many accounts can share the same environment (e.g. dev, test, prod)
requiredGroupMembership: (Deprecated): Configure permissions instead.
serviceKeyFile: Path to a file containing the secret key for service account authentication
uid: (Required) User or service account identifier

Clusters parameters

name: (Required) The name of the cluster.
caCertFile: Root certificate file to trust for connections to the cluster. File needs to be present on the machine running Spinnaker. Supports encrypted file.
dcosUrl: (Required) URL of the endpoint for the DC/OS cluster’s admin router.
insecureSkipTlsVerify: If true, disables verification of certificates from the cluster (insecure).
loadBalancer: Configuration for a DC/OS load balancer
- image: Marathon-lb image to use when creating a load balancer with Spinnaker.
- serviceAccountSecret: Name of the secret to use for allowing marathon-lb to authenticate with the cluster. Only necessary for clusters with strict or permissive security. Supports encrypted value.

Docker Registry

spec.spinnakerConfig.config.providers.dockerRegistry

dockerRegistry:
 enabled: true
 primaryAccount: dockerhub
 accounts:
 - name: dockerhub
 environment:
 requiredGroupMembership:
 providerVersion: V1
 permissions:
 READ:
 WRITE:
 EXECUTE:
 CREATE:
 address:
 username:
 password:
 passwordCommand:
 email:
 cacheIntervalSeconds:
 clientTimeoutMillis:
 cacheThreads:
 paginateSize:
 sortTagsByDate:
 trackDigests:
 insecureRegistry:
 repositories:
 passwordFile:
 dockerconfigFile:

enabled: Whether the provider is enabled.
accounts: the list of configured accounts
primaryAccount: The name of the primary account.

Account parameters

name: name of the account
address: (Default: gcr.io) (Required) The registry address you want to pull and deploy images from; e.g. https://index.docker.io
cacheIntervalSeconds: (Default: 30) How many seconds elapse between polling your docker registry. Certain registries are sensitive to over-polling, and larger intervals (e.g. 10 minutes = 600 seconds) are desirable if you’re seeing rate limiting.
cacheThreads: (Default: 1) How many threads to cache all provided repos on. Really only useful if you have a ton of repos.
clientTimeoutMillis: (Default: 60000) Timeout time in milliseconds for this repository.
email: Your docker registry email (often this only needs to be well-formed, rather than be a real address)
environment: The environment name for the account. Many accounts can share the same environment (e.g. dev, test, prod)
insecureRegistry: (Default: false) Treat the docker registry as insecure (don’t validate the ssl cert).
paginateSize: (Default: 100) Paginate size for the docker repository _catalog endpoint.
password: Your docker registry password. Supports encrypted value.
passwordCommand: Command to retrieve docker token/password, commands must be available in environment
passwordFile: The path to a file containing your docker password in plaintext (not a docker/config.json file). File needs to be present on the machine running Spinnaker. Supports encrypted file.
permissions:
- READ: [] A user must have at least one of these roles in order to view this account’s cloud resources.
- WRITE: [] A user must have at least one of these roles in order to make changes to this account’s cloud resources.
- EXECUTE:
- CREATE:
requiredGroupMembership: [] (Deprecated): Configure permissions instead.
repositories: (Default: []) An optional list of repositories to cache images from. If not provided, Spinnaker will attempt to read accessible repositories from the registries _catalog endpoint
sortTagsByDate: (Default: false) Sort tags by creation date.
trackDigests: (Default: false) Track digest changes. This is not recommended as it consumes a high QPM, and most registries are flaky.
username: Your docker registry username

ECS

spec.spinnakerConfig.config.providers.ecs

ecs:
 enabled: false
 accounts:
 - name: aws-dev
 environment:
 awsAccount:
 requiredGroupMembership:
 permissions:
 READ:
 WRITE:
 EXECUTE:
 CREATE:
 providerVersion: v1
 primaryAccount: aws-dev

enabled: Whether the provider is enabled.
accounts: the list of configured accounts
primaryAccount: The name of the primary account.

Account parameters

name: name of the account
awsAccount: (Required) Provide the name of the AWS account associated with this ECS account.See https://github.com/spinnaker/clouddriver/blob/master/clouddriver-ecs/README.md for more information.
environment: The environment name for the account. Many accounts can share the same environment (e.g. dev, test, prod)
permissions:
- READ: [] A user must have at least one of these roles in order to view this account’s cloud resources.
- WRITE: [] A user must have at least one of these roles in order to make changes to this account’s cloud resources.
- EXECUTE:
- CREATE:
requiredGroupMembership: [] (Deprecated): Configure permissions instead.

Google

spec.spinnakerConfig.config.providers.google

google:
 enabled:
 accounts:
 - name:
 environment:
 requiredGroupMembership:
 - readers
 providerVersion: V1
 permissions:
 READ:
 - read1
 - read2
 WRITE:
 - write1
 - write2
 EXECUTE:
 - exec1
 - exec2
 CREATE:
 - create1
 - create2
 project:
 jsonPath:
 alphaListed:
 imageProjects:
 - abc
 consul:
 enabled:
 agentEndpoint:
 agentPort:
 datacenters:
 - abc
 userDataFile:
 regions:
 - abc
 primaryAccount: google-dev
 bakeryDefaults:
 templateFile:
 baseImages:
 - baseImage:
 id:
 shortDescription:
 detailedDescription:
 packageType:
 templateFile:
 isImageFamily:
 virtualizationSettings:
 sourceImage:
 sourceImageFamily:
 zone:
 network:
 networkProjectId:
 useInternalIp:
 defaultKeyPairTemplate:
 defaultRegions:
 - name:

enabled: Whether the provider is enabled.
accounts: the list of configured accounts
primaryAccount: The name of the primary account.
bakeryDefaults: configuration for Spinnaker’s image bakery

Account parameters

name: name of the account
alphaListed: (Default: false) Enable this flag if your project has access to alpha features and you want Spinnaker to take advantage of them.
environment: The environment name for the account. Many accounts can share the same environment (e.g. dev, test, prod)
imageProjects: (Default: []) A list of Google Cloud Platform projects Spinnaker will be able to cache and deploy images from. When this is omitted, it defaults to the current project. Each project must have granted the IAM role compute.imageUser to the service account associated with the json key used by this account, as well as to the ‘Google APIs service account’ automatically created for the project being managed (should look similar to 12345678912@cloudservices.gserviceaccount.com). See Sharing Images Across Projects for more information about sharing images across GCP projects.
jsonPath: The path to a JSON service account that Spinnaker will use as credentials. This is only needed if Spinnaker is not deployed on a Google Compute Engine VM, or needs permissions not afforded to the VM it is running on. See https://cloud.google.com/compute/docs/access/service-accounts for more information. File needs to be present on the machine running Spinnaker. Supports encrypted file.
permissions:
- READ: [] A user must have at least one of these roles in order to view this account’s cloud resources.
- WRITE: [] A user must have at least one of these roles in order to make changes to this account’s cloud resources.
- EXECUTE:
- CREATE:
requiredGroupMembership: [] (Deprecated): Configure permissions instead.
project: (Required) The Google Cloud Platform project this Spinnaker account will manage.
readPermissions: (Default: []) A user must have at least one of these roles in order to view this account’s cloud resources.
regions: A list of regions for caching and mutating calls. This overwrites any default-regions set on the provider.
userDataFile: The path to user data template file. Spinnaker has the ability to inject userdata into generated instance templates. The mechanism is via a template file that is token replaced to provide some specifics about the deployment. See https://github.com/spinnaker/clouddriver/blob/master/clouddriver-aws/UserData.md for more information. File needs to be present on the machine running Spinnaker.
consul: Configuration for Consul.
- enabled: Whether Consul is enabled.
- agentEndpoint: Reachable Consul node endpoint connected to the Consul cluster. Defaults to localhost.
- agentPort: Port consul is running on for every agent.
- datacenters: List of data centers to cache and keep updated.

Bakery parameters

network: Set the default network your images will be baked in.
networkProjectId: Set the default project id for the network and subnet to use for the VM baking your image.
templateFile: This is the name of the packer template that will be used to bake images from this base image. The template file must be found in this list https://github.com/spinnaker/rosco/tree/master/rosco-web/config/packer, or supplied as described here: https://spinnaker.io/setup/bakery/
useInternalIp: Use the internal rather than external IP of the VM baking your image.
zone: Set the default zone your images will be baked in.

Bakery base image parameters

detailedDescription: A long description to help human operators identify the image.
isImageFamily: (Default: false)
packageType: This is used to help Spinnaker’s bakery download the build artifacts you supply it with. For example, specifying ‘deb’ indicates that your artifacts will need to be fetched from a debian repository.
shortDescription: A short description to help human operators identify the image.
templateFile: This is the name of the packer template that will be used to bake images from this base image. The template file must be found in this list https://github.com/spinnaker/rosco/tree/master/rosco-web/config/packer, or supplied as described here: https://spinnaker.io/setup/bakery/
virtualizationSettings:
- sourceImage: The source image. If both source image and source image family are set, source image will take precedence.
- source-image-family: The source image family to create the image from. The newest, non-deprecated image is used.

Huawei Cloud

spec.spinnakerConfig.config.providers.huawei

huaweicloud:
 enabled:
 accounts:
 - name: huawei-dev
 environment:
 requiredGroupMembership:
 providerVersion: V1
 permissions:
 READ:
 - read1
 - read2
 WRITE:
 - write1
 - write2
 EXECUTE:
 - exec1
 - exec2
 CREATE:
 - create1
 - create2
 accountType:
 authUrl:
 username:
 password:
 projectName:
 domainName:
 insecure:
 regions:
 primaryAccount: huawei-dev
 bakeryDefaults:
 templateFile:
 baseImages:
 - baseImage:
 id:
 shortDescription:
 detailedDescription:
 packageType:
 templateFile:
 virtualizationSettings:
 - region:
 instanceType:
 sourceImageId:
 sshUserName:
 eipType:
 authUrl:
 username:
 password:
 projectName:
 domainName:
 insecure:
 vpcId:
 subnetId:
 securityGroup:
 eipBandwidthSize:

enabled: Whether the provider is enabled.
accounts: the list of configured accounts
primaryAccount: The name of the primary account.
bakeryDefaults: configuration for Spinnaker’s image bakery

Account parameters

name: name of the account
accountType: The type of account.
authUrl: (Required) The auth url of cloud.
domainName: (Required) The domain name of the cloud.
environment: The environment name for the account. Many accounts can share the same environment (e.g. dev, test, prod)
insecure: (Default: false) Disable certificate validation on SSL connections. Needed if certificates are self signed. Default false.
password: (Required) The password used to access cloud. Supports encrypted value.
projectName: (Required) The name of the project within the cloud.
regions: (Default: []) (Required) The region(s) of the cloud.
username: (Required) The username used to access cloud.
permissions:
- READ: [] A user must have at least one of these roles in order to view this account’s cloud resources.
- WRITE: [] A user must have at least one of these roles in order to make changes to this account’s cloud resources.
- EXECUTE:
- CREATE:
requiredGroupMembership: [] (Deprecated): Configure permissions instead.

Bakery parameters

authUrl: (Required) Set the default auth URL your images will be baked in.
domainName: (Required) Set the default domainName your images will be baked in.
eipBandwidthSize: (Required) Set the bandwidth size of EIP your images will be baked in.
insecure: (Required) The security setting (true/false) for connecting to the HuaweiCloud account.
password: (Required) Set the default password your images will be baked with.
projectName: Set the default project name your images will be baked in.
domainName: (Required) Set the default project name your images will be baked in.
securityGroup: (Required) Set the default security group your images will be baked in.
subnetId: (Required) Set the subnet your images will be baked in.
templateFile: This is the name of the packer template that will be used to bake images from this base image. The template file must be found in this list https://github.com/spinnaker/rosco/tree/master/rosco-web/config/packer, or supplied as described here: https://spinnaker.io/setup/bakery/
username: (Required) Set the default username your images will be baked with.
vpcId: (Required) Set the vpc your images will be baked in.

Bakery base image parameters

detailedDescription: A long description to help human operators identify the image.
packageType: This is used to help Spinnaker’s bakery download the build artifacts you supply it with. For example, specifying ‘deb’ indicates that your artifacts will need to be fetched from a debian repository.
shortDescription: A short description to help human operators identify the image.
templateFile: This is the name of the packer template that will be used to bake images from this base image. The template file must be found in this list https://github.com/spinnaker/rosco/tree/master/rosco-web/config/packer, or supplied as described here: https://spinnaker.io/setup/bakery/

Kubernetes

spec.spinnakerConfig.config.providers.kubernetes

The Kubernetes provider is used to deploy Kubernetes resources to any number of Kubernetes clusters. Spinnaker assumes you have a Kubernetes cluster already running. If you don’t, you must configure one: https://Kubernetes.io/docs/getting-started-guides/.

Before proceeding, please visit https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/ to make sure you’re familiar with the authentication terminology.

kubernetes:
 enabled: true
 accounts:
 - name: spinnaker
 context:
 cluster:
 user:
 configureImagePullSecrets:
 cacheThreads:
 namespaces:
 omitNamespaces:
 kinds:
 omitKinds:
 customResources:
 versioned:
 - kubernetesKind:
 - spinnakerKind:
 cachingPolicies:
 - kubernetesKind:
 maxEntriesPerAgent:
 kubeconfigFile:
 kubeconfigContents:
 kubectlPath:
 kubectlRequestTimeoutSeconds:
 liveManifestCalls:
 oAuthServiceAccount:
 oAuthScopes:
 namingStrategy:
 skin:
 onlySpinnakerManaged:
 debug:
 dockerRegistries:
 - accountName:
 namespaces:
 providerVersion: V2
 requiredGroupMembership:
 permissions:
 READ:
 WRITE:
 EXECUTE:
 CREATE:
 primaryAccount: spinnaker

enabled: Whether the provider is enabled.
accounts: the list of configured accounts
primaryAccount: The name of the primary account.

Account parameters

An account in the Kubernetes provider refers to a single Kubernetes context. In Kubernetes, a context is the combination of a Kubernetes cluster and some credentials. If no context is specified, the default context in in your kubeconfig is assumed. You must also provide a set of Docker Registries for each account. Spinnaker will automatically upload that Registry’s credentials to the specified Kubernetes cluster allowing you to deploy those images without further configuration.

name: spinnaker
context: The kubernetes context to be managed by Spinnaker. See http://kubernetes.io/docs/user-guide/kubeconfig-file/#context for more information. When no context is configured for an account the ‘current-context’ in your kubeconfig is assumed.
cluster: Used with V1 provider (deprecated)
user: Used with V1 provider (deprecated)
configureImagePullSecrets: Used with V1 provider. When true, Spinnaker will create & manage your image pull secrets for you; when false, you will have to create and attach them to your pod specs by hand.
serviceAccount: When true, Spinnaker attempt to authenticate against Kubernetes using a Kubernetes service account. This only works when Halyard & Spinnaker are deployed in Kubernetes. Read more about service accounts here: https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/.
cacheThreads: Number of caching agents for this kubernetes account. Each agent handles a subset of the namespaces available to this account. By default, only 1 agent caches all kinds for all namespaces in the account.
namespaces: A list of namespaces this Spinnaker account can deploy to and will cache. When no namespaces are configured, this defaults to ‘all namespaces’.
omitNamespaces: A list of namespaces this Spinnaker account cannot deploy to or cache. This can only be set when –namespaces is empty or not set.
kinds: (V2 Only) A list of resource kinds this Spinnaker account can deploy to and will cache. When no kinds are configured, this defaults to all kinds described in the Kubernetes Provider docs.
omitKinds: (V2 Only) A list of resource kinds this Spinnaker account cannot deploy to or cache. This can only be set when –kinds is empty or not set.
customResources: (V2 Only) List of Kubernetes custom resources to managed by clouddriver and made available for use in patch and delete manifest stages.
- versioned: true or false
- kubernetesKind: Fully qualified name of the Kubernetes CRD
- spinnakerKind: One of instances, configs, serverGroups, loadBalancers, securityGroups, serverGroupManagers, unclassified
cachingPolicies:
- kubernetesKind:
- maxEntriesPerAgent:
kubeconfigFile: The path to your kubeconfig file. By default, it will be under the Spinnaker user’s home directory in the typical .kube/config location. File needs to be present on the machine running Spinnaker. Supports encrypted file.
kubeconfigContents: Inline kubeconfig file contents
kubectlPath: Alternate path inside clouddriver pod of the kubectl binary
kubectlRequestTimeoutSeconds: Timeout in seconds of kubectl calls
checkPermissionsOnStartup: When false, clouddriver will skip the permission checks for all Kubernetes Kinds at startup. This can save a great deal of time during clouddriver startup when you have many Kubernetes accounts configured. This disables the log messages at startup about missing permissions.
liveManifestCalls: When true, clouddriver will query manifest status during pipeline executions using live data rather than the cache. This eliminates all time spent in the “force cache refresh” task in pipelines, greatly reducing execution time.
oAuthServiceAccount: File needs to be present on the machine running Spinnaker. Supports encrypted file.
oAuthScopes:
namingStrategy:
skin:
onlySpinnakerManaged: (V2 Only) When true, Spinnaker only caches and displays applications that have been created by Spinnaker. Before placing in a false state, you should review the Kubernetes cluster configuration. When false, Spinnaker analyzes the cluster and automatically attempts to configure and populate applications for resources already present in Kubernetes, unless limited with omitNamespaces. You should note the increased possibilities of misconfigured Autogenerated Application Placeholders in the deployments.
debug: true or false
dockerRegistries:
- accountName: dockerhub
- namespaces:
providerVersion: V2
permissions:
- READ: [] A user must have at least one of these roles in order to view this account’s cloud resources.
- WRITE: [] A user must have at least one of these roles in order to make changes to this account’s cloud resources.
- EXECUTE:
- CREATE:
requiredGroupMembership: [] (Deprecated): Configure permissions instead.

Oracle

spec.spinnakerConfig.config.providers.oracle

oracle:
 enabled:
 accounts:
 - name: oracle-dev
 environment:
 requiredGroupMembership:
 providerVersion: V1
 permissions:
 READ:
 - read1
 - read2
 WRITE:
 - write1
 - write2
 EXECUTE:
 - exec1
 - exec2
 CREATE:
 - create1
 - create2
 compartmentId:
 userId:
 fingerprint:
 sshPrivateKeyFilePath:
 privateKeyPassphrase:
 tenancyId:
 region:
 primaryAccount: oracle-dev
 bakeryDefaults:
 templateFile:
 baseImages:
 - baseImage:
 id:
 shortDescription:
 detailedDescription:
 packageType:
 templateFile:
 virtualizationSettings:
 baseImageId:
 sshUserName:
 availabilityDomain:
 subnetId:
 instanceShape:

Account parameters

compartmentId: (Required) Provide the OCID of the Oracle Compartment to use.
deployment: If supplied, use this Halyard deployment. This will not create a new deployment.
environment: The environment name for the account. Many accounts can share the same environment (e.g. dev, test, prod)
fingerprint: (Required) Fingerprint of the public key
privateKeyPassphrase: Passphrase used for the private key, if it is encrypted.Supports encrypted value.
permissions:
- READ: [] A user must have at least one of these roles in order to view this account’s cloud resources.
- WRITE: [] A user must have at least one of these roles in order to make changes to this account’s cloud resources.
- EXECUTE:
- CREATE:
requiredGroupMembership: [] (Deprecated): Configure permissions instead.
region: (Required) An Oracle region (e.g., us-phoenix-1)
sshPrivateKeyFilePath: (Required) Path to the private key in PEM format. File needs to be present on the machine running Spinnaker. Supports encrypted file.
tenancyId: (Required) Provide the OCID of the Oracle Tenancy to use.
userI: (Required) Provide the OCID of the Oracle User you’re authenticating as

Bakery parameters

availabilityDomain: (Required) The name of the Availability Domain within which a new instance is launched and provisioned.
deployment: If supplied, use this Halyard deployment. This will not create a new deployment.
instanceShape: (Required) The shape for allocated to a newly created instance.
subnetId: (Required) The name of the subnet within which a new instance is launched and provisioned.
templateFile: This is the name of the packer template that will be used to bake images from this base image. The template file must be found in this list https://github.com/spinnaker/rosco/tree/master/rosco-web/config/packer, or supplied as described here: https://spinnaker.io/setup/bakery/

Bakery base image parameters

baseImageId: (Required) The OCID of the base image ID for the baking configuration.
deployment: If supplied, use this Halyard deployment. This will not create a new deployment.
detailedDescription: A long description to help human operators identify the image.
packageType: This is used to help Spinnaker’s bakery download the build artifacts you supply it with. For example, specifying ‘deb’ indicates that your artifacts will need to be fetched from a debian repository.
shortDescription: A short description to help human operators identify the image.
sshUserName: (Required) The ssh username for the baking configuration.
templateFile: This is the name of the packer template that will be used to bake images from this base image. The template file must be found in this list https://github.com/spinnaker/rosco/tree/master/rosco-web/config/packer, or supplied as described here: https://spinnaker.io/setup/bakery/

Tencent Cloud

spec.spinnakerConfig.config.providers.tencentcloud

tencentcloud:
 enabled:
 accounts:
 - name: tencent-dev
 environment: dev
 requiredGroupMembership:
 providerVersion: V1
 permissions:
 READ:
 - read1
 - read2
 WRITE:
 - write1
 - write2
 EXECUTE:
 - exec1
 - exec2
 CREATE:
 - create1
 - create2
 secretId:
 secretKey:
 regions:
 primaryAccount: tencent-dev
 bakeryDefaults:
 templateFile:
 baseImages:
 - baseImage:
 id:
 shortDescription:
 detailedDescription:
 packageType:
 templateFile:
 virtualizationSettings:
 - region:
 zone:
 instanceType:
 sourceImageId:
 sshUserName:
 secretId:
 secretKey:

enabled: true or false
accounts: account configuration list
primaryAccount: primary account to use
bakeryDefaults: image baking configuration

Account parameters

deployment: If supplied, use this Halyard deployment. This will not create a new deployment.
environment: The environment name for the account. Many accounts can share the same environment (e.g. dev, test, prod)
permissions:
- READ: [] A user must have at least one of these roles in order to view this account’s cloud resources.
- WRITE: [] A user must have at least one of these roles in order to make changes to this account’s cloud resources.
- EXECUTE:
- CREATE:
requiredGroupMembership: [] (Deprecated): Configure permissions instead.
regions: The Tencent CLoud regions this Spinnaker account will manage.
secretId: (Required) The secret id used to access Tencent Cloud.
secretKey: (Required) The secret key used to access Tencent Cloud. Supports encrypted value.

Bakery parameters

secretId: (Required) The default access key used to communicate with AWS.
secretKey: (Required) The secret key used to communicate with AWS. Supports encrypted value.
templateFile: This is the name of the packer template that will be used to bake images from this base image. The template file must be found in this list https://github.com/spinnaker/rosco/tree/master/rosco-web/config/packer, or supplied as described here: https://spinnaker.io/setup/bakery/

Bakery base image parameters

detailedDescription: A long description to help human operators identify the image.
instanceType: (Required) The instance type for the baking configuration.
packageType: This is used to help Spinnaker’s bakery download the build artifacts you supply it with. For example, specifying ‘deb’ indicates that your artifacts will need to be fetched from a debian repository.
region: (Required) The region for the baking configuration.
shortDescription: A short description to help human operators identify the image.
sourceImageId: (Required) The source image ID for the baking configuration.
sshUserName: (Required) The ssh username for the baking configuration.
templateFile: This is the name of the packer template that will be used to bake images from this base image. The template file must be found in this list https://github.com/spinnaker/rosco/tree/master/rosco-web/config/packer, or supplied as described here: https://spinnaker.io/setup/bakery/
zone: (Required) The zone for the baking configuration.

Kustomize patch examples

You can see examples in the spinnaker-kustomize-patches repo’s accounts folder.

Continuous-Deployment: PubSub Config

Mon, 01 Jan 0001 00:00:00 +0000

spec.spinnakerConfig.config.pubsub

pubsub:
 enabled:
 google:
 enabled:
 subscriptions:
 - name:
 project:
 subscriptionName:
 jsonPath:
 templatePath:
 ackDeadlineSeconds:
 messageFormat:
 publishers:
 - name:
 project:
 topicName:
 jsonPath:
 content:

enabled: true or false.
google:

Google

enabled: true or false.
subscriptions:
- name: subscription name
- project: The name of the GCP project your subscription lives in.
- subscriptionName: The name of the subscription to listen to. This identifier does not include the name of the project, and must already be configured for Spinnaker to work.
- jsonPath: The path to a JSON service account that Spinnaker will use as credentials. This is only needed if Spinnaker is not deployed on a Google Compute Engine VM, or needs permissions not afforded to the VM it is running on. See https://cloud.google.com/compute/docs/access/service-accounts for more information. File needs to be present on the machine running Spinnaker. Supports encrypted file.
- templatePath: A path to a jinja template that specifies how artifacts from this pubsub system are interpreted and transformed into Spinnaker artifacts. See spinnaker.io/reference/artifacts for more information. File needs to be present on the machine running Spinnaker.
- ackDeadlineSeconds: Time in seconds before an outstanding message is considered unacknowledged and is re-sent. Configurable in your Google Cloud Pubsub subscription. See the docs here`: https://cloud.google.com/pubsub/docs/subscriber
- messageFormat: One of ‘GCB’, ‘GCS’, ‘GCR’, or ‘CUSTOM’. This can be used to help Spinnaker translate the contents of the Pub/Sub message into Spinnaker artifacts.
publishers:
- name: name of publisher
  - project:
  - topicName:
  - jsonPath: File needs to be present on the machine running Spinnaker. Supports encrypted file.

Kustomize patch examples

You can see examples in the spinnaker-kustomize-patches repo’s pubsub folder.

Continuous-Deployment: Repository Config

Mon, 01 Jan 0001 00:00:00 +0000

spec.spinnakerConfig.config.repository

repository:
 artifactory:
 enabled:
 searches:
 - name:
 baseUrl:
 permissions:
 READ:
 WRITE:
 repo:
 groupId:
 repoType:
 username:
 password:

Artifactory

enabled: true or false.
searches:
- - name: The name of the account
  - baseUrl: The base url your artifactory search is reachable at.
  - permissions:
    - READ: [] A user must have at least one of these roles in order to view this account’s cloud resources.
    - WRITE: [] A user must have at least one of these roles in order to make changes to this account’s cloud resources.
  - repo: The repo in your artifactory to be searched.
  - groupId: The group id in your artifactory to be searched.
  - repoType: The package type of repo in your artifactory to be searched: maven (default).
  - username: The username of the artifactory user to authenticate as.
  - password: The password of the artifactory user to authenticate as. Supports encrypted value.

Continuous-Deployment: Security Config

Mon, 01 Jan 0001 00:00:00 +0000

spec.spinnakerConfig.config.security

Configure Spinnaker’s security. This includes external SSL, authentication mechanisms, and authorization policies.

security:
 apiSecurity:
 uiSecurity:
 authn:
 authz:

apiSecurity
uiSecurity
authn
authz

API

spec.spinnakerConfig.config.security.apiSecurity

apiSecurity:
 ssl:
 enabled:
 keyAlias:
 keyStore:
 keyStoreType:
 keyStorePassword:
 trustStore:
 trustStoreType:
 trustStorePassword:
 clientAuth:
 overrideBaseUrl:
 corsAccessPattern:

ssl:
overrideBaseUrl: If you are accessing the API server remotely, provide the full base URL (including protocol) of whatever proxy or load balancer is fronting the API requests.
corsAccessPattern: ^.*$ If you have authentication enabled, are accessing Spinnaker remotely, and are logging in from sources other than the UI, provide a regex matching all URLs authentication redirects may come from.

SSL parameters

enabled: true or false.
keyAlias: Name of your keystore entry as generated with your keytool.
keyStore: Path to the keystore holding your security certificates. File needs to be present on the machine running Spinnaker. Supports encrypted file.
keyStoreType: The type of your keystore. Examples include JKS, and PKCS12.
keyStorePassword: The password to unlock your keystore. Due to a limitation in Tomcat, this must match your key’s password in the keystore. Supports encrypted value.
trustStore: Path to the truststore holding your trusted certificates. File needs to be present on the machine running Spinnaker. Supports encrypted file.
trustStoreType: The type of your truststore. Examples include JKS, and PKCS12.
trustStorePassword: The password to unlock your truststore. Supports encrypted value.
clientAuth: Declare WANT when client auth is wanted but not mandatory or NEED when client auth is mandatory.

Authentication

spec.spinnakerConfig.config.security.authn

authn:
 oauth2:
 saml:
 ldap:
 x509:
 iap:

enabled: true or false.
oauth2:
saml:
ldap:
x509:
iap

OAUTH2

spec.spinnakerConfig.config.security.authn.oauth2

oauth2:
 enabled:
 client:
 clientId:
 clientSecret:
 accessTokenUri:
 userAuthorizationUri:
 clientAuthenticationScheme:
 scope:
 preEstablishedRedirectUri:
 useCurrentUri:
 userInfoRequirements:
 resource:
 userInfoUri:
 userInfoMapping:
 email:
 firstName:
 lastName:
 username:
 provider:

enabled: true or false.
client:
- clientId: The OAuth client ID you have configured with your OAuth provider.
- clientSecret: The OAuth client secret you have configured with your OAuth provider. Supports encrypted value.
- accessTokenUri: The access token uri for your OAuth provider.
- userAuthorizationUri: The user authorization uri for your OAuth provider.
- clientAuthenticationScheme: The client authentication scheme for your OAuth provider.
- scope: The scope for your OAuth provider, e.g. user:email
- preEstablishedRedirectUri: The externally accessible URL for Gate. For use with load balancers that do any kind of address manipulation for Gate traffic, such as an SSL terminating load balancer.
- useCurrentUri: false
userInfoRequirements: {} The map of requirements the userInfo request must have. This is used to restrict user login to specific domains or having a specific attribute. Use equal signs between key and value, and additional key/value pairs need to repeat the flag. Example: ‘–user-info-requirements foo=bar –userInfoRequirements baz=qux’.
resource:
- userInfoUri: The user info uri for your OAuth provider.
userInfoMapping:
- email: The email field returned from your OAuth provider.
- firstName: The first name field returned from your OAuth provider.
- lastName: The last name field returned from your OAuth provider.
- username: The username field returned from your OAuth provider.
provider: One of azure, github, oracle, other, google

SAML

spec.spinnakerConfig.config.security.authn.saml

saml:
 enabled:
 metadataLocal:
 metadataRemote:
 issuerId:
 keyStore:
 keyStorePassword:
 keyStoreAliasName:
 serviceAddress:
 userAttributeMapping:
 firstName:
 lastName:
 roles:
 lastName:
 username:
 email:

enabled: true or false.
metadataLocal: The address to your identity provider’s metadata XML file. File needs to be present on the machine running Spinnaker. Supports encrypted file.
metadataRemote: The address to your identity provider’s metadata XML file. This is a URL.
issuerId: The identity of the Spinnaker application registered with the SAML provider.
keyStore: Path to the keystore that contains this server’s private key. This key is used to cryptographically sign SAML AuthNRequest objects. File needs to be present on the machine running Spinnaker. Supports encrypted file.
keyStorePassword: The password used to access the file specified in –keystore. Supports encrypted value.
keyStoreAliasName: The name of the alias under which this server’s private key is stored in the –keystore file.
serviceAddress: The address of the Gate server that will be accesible by the SAML identity provider. This should be the full URL, including port, e.g. https://gate.org.com:8084/. If deployed behind a load balancer, this would be the load balancer’s address.
userAttributeMapping:
- firstName: The first name field returned from your SAML provider.
- lastName: The last name field returned from your SAML provider.
- roles: The roles field returned from your SAML provider.
- lastName: The last name field returned from your SAML provider.
- username: aThe username field returned from your SAML provider.
- email: The email field returned from your SAML provider.

LDAP

spec.spinnakerConfig.config.security.authn.ldap

ldap:
 enabled:
 url:
 userDnPattern:
 userSearchBase:
 userSearchFilter:
 managerDn:
 managerPassword:
 groupSearchBase:

enabled: true or false.
url: ldap:// or ldaps:// url of the LDAP server
userDnPattern: The pattern for finding a user’s DN using simple pattern matching. For example, if your LDAP server has the URL ldap://mysite.com/dc=spinnaker,dc=org, and you have the pattern ‘uid={0},ou=members’, ‘me’ will map to a DN uid=me,ou=members,dc=spinnaker,dc=org. If no match is found, will try to find the user using user-search-filter, if set.
userSearchBase: The part of the directory tree under which user searches should be performed. If user-search-base isn’t supplied, the search will be performed from the root.
userSearchFilter: The filter to use when searching for a user’s DN. Will search either from user-search-base (if specified) or root for entires matching the filter, then attempt to bind as that user with the login password. For example, the filter ‘uid={0}’ would apply to any user where uid matched the user’s login name. If –user-dn-pattern is also specified, will attempt to find a match using the specified pattern first, before searching with the specified search filter if no match is found from the pattern.
managerDn: An LDAP manager user is required for binding to the LDAP server for the user authentication process. This property refers to the DN of that entry. I.e. this is not the user which will be authenticated when logging into DHIS2, rather the user which binds to the LDAP server in order to do the authentication.
managerPassword: The password for the LDAP manager user.
groupSearchBase: The part of the directory tree under which group searches should be performed.

x509

spec.spinnakerConfig.config.security.authn.x509

x509:
 enabled:
 roleOid:
 subjectPrincipalRegex:

enabled: true or false.
roleOid: The OID that encodes roles that the user specified in the x509 certificate belongs to
subjectPrincipalRegex: EMAILADDRESS=(.*?)(?:,|$) The regex used to parse the subject principal name embedded in the x509 certificate if necessary

IAP

spec.spinnakerConfig.config.security.authn.iap

iap:
 enabled:
 jwtHeader:
 issuerId:
 audience:
 iapVerifyKeyUrl:

enabled: true or false.
jwtHeader: The HTTP request header that contains the JWT token.
issuerId: The Issuer from the ID token payload.
audience: The Audience from the ID token payload. You can retrieve this field from the IAP console.
iapVerifyKeyUrl: The URL containing the Cloud IAP public keys in JWK format.

Authorization

spec.spinnakerConfig.config.security.authz

authz:
 enabled:
 groupMembership:

enabled: true or false.
groupMembership:

Group Membership

groupMembership:
 service:
 google:
 roleProviderType: GOOGLE
 credentialPath:
 adminUsername:
 domain:
 github:
 roleProviderType: GITHUB
 baseUrl:
 accessToken:
 organization:
 file:
 roleProviderType: FILE
 path:
 ldap:
 roleProviderType: LDAP
 url:
 managerDn:
 managerPassword:
 userDnPattern:
 userSearchBase:
 groupSearchBase:
 userSearchFilter:
 groupSearchFilter:
 groupRoleAttributes:

service: One of EXTERNAL, FILE, GOOGLE, GITHUB, LDAP
google:
- roleProviderType: GOOGLE
- credentialPath: A path to a valid json service account that can authenticate against the Google role provider. File needs to be present on the machine running Spinnaker. Supports encrypted file.
- adminUsername: Your role provider’s admin username e.g. admin@myorg.net
- domain: The domain your role provider is configured for e.g. myorg.net.
github:
- roleProviderType: GITHUB
- baseUrl: Used if using GitHub enterprise some other non github.com GitHub installation.
- accessToken: A personal access token of an account with access to your organization’s GitHub Teams structure. Supports encrypted value.
- organization: The GitHub organization under which to query for GitHub Teams.
file:
- roleProviderType: FILE
- path: A path to a file describing the roles of each user.
ldap:
- roleProviderType: LDAP
- url: ldap:// or ldaps:// URL of the LDAP server
- managerDn: The manager user’s distinguished name (principal) to use for querying ldap groups.
- managerPassword: The manager user’s password to use for querying ldap groups. Supports encrypted value.
- userDnPattern: The pattern for finding a user’s DN using simple pattern matching. For example, if your LDAP server has the URL ldap://mysite.com/dc=spinnaker,dc=org, and you have the pattern ‘uid={0},ou=members’, ‘me’ will map to a DN uid=me,ou=members,dc=spinnaker,dc=org. If no match is found, will try to find the user using –user-search-filter, if set.
- userSearchBase: The part of the directory tree under which user searches should be performed. If –user-search-base isn’t supplied, the search will be performed from the root.
- groupSearchBase: The part of the directory tree under which group searches should be performed.
- userSearchFilter: The filter to use when searching for a user’s DN. Will search either from –user-search-base (if specified) or root for entires matching the filter.
- groupSearchFilter: The filter which is used to search for group membership. The default is uniqueMember={0}, corresponding to the groupOfUniqueMembers LDAP class. In this case, the substituted parameter is the full distinguished name of the user. The parameter ‘{1}’ can be used if you want to filter on the login name.
- groupRoleAttributes: The attribute which contains the name of the authority defined by the group entry. Defaults to cn.

UI

spec.spinnakerConfig.config.security.uiSecurity

uiSecurity:
 ssl:
 overrideBaseUrl:

overrideBaseUrl: If you are accessing the UI server remotely, provide the full base URL (including protocol) of whatever proxy or load balancer is fronting the UI requests.
ssl:

SSL

uiSecurity:
 ssl:
 enabled:
 sslCertificateFile:
 sslCertificateKeyFile:
 sslCertificatePassphrase:
 sslCACertificateFile:

enabled: true or false.
sslCertificateFile: Path to your .crt file. File needs to be present on the machine running Spinnaker. Supports encrypted file.
sslCertificateKeyFile: Path to your .key file. File needs to be present on the machine running Spinnaker. Supports encrypted file.
sslCertificatePassphrase: The passphrase needed to unlock your SSL certificate. This will be provided to Apache on startup. Supports encrypted value.
sslCACertificateFile: Path to the .crt file for the CA that issued your SSL certificate. This is only needed for localgitdeployments that serve the UI using webpack dev server. File needs to be present on the machine running Spinnaker. Supports encrypted file.

Kustomize patch examples

You can see examples in the spinnaker-kustomize-patches repo’s security folder.

Continuous-Deployment: Stats Config

Mon, 01 Jan 0001 00:00:00 +0000

spec.spinnakerConfig.config.stats

stats:
 enabled: true
 endpoint: # Set the endpoint for stats metrics.

enabled: true or false.
endpoint: Set the endpoint for stats metrics, such as https://stats.spinnaker.io

Continuous-Deployment: Webhook Config

Mon, 01 Jan 0001 00:00:00 +0000

spec.spinnakerConfig.config.webhook

webhook:
 trust:
 enabled: false
 trustStore:
 trustStorePassword:

trust:
- enabled: false
- trustStore: The path to a key store in JKS format containing certification authorities that should be trusted by webhook stages. File needs to be present on the machine running Spinnaker.
- trustStorePassword: The password for the supplied trustStore.

Continuous-Deployment: Install Spinnaker on Lightweight Kubernetes using Minnaker

Mon, 01 Jan 0001 00:00:00 +0000

Install Spinnaker in 10 minutes using Minnaker

Armory Minnaker is an easy to use installation script that leverages the power of Kubernetes with the simplicity of a Virtual Machine. Minnaker makes it easy to install Spinnaker and lets you scale your deployment into a medium to large deployment down the road.

The Kubernetes environment that gets installed on your behalf is based on Rancher’s K3s. You do not need to know how to set up Kubernetes. Minnaker takes care of the hard parts for you, allowing you to get Spinnaker up and running in under 10 minutes.

Watch Spinnaker in 10 minutes or less with Project Minnaker for a demo of using Minnaker to install Spinnaker on cloud platforms as well as VMWare Fusion running locally.

Prerequisites for running Minnaker

Your VM should have 4 vCPUs, 16G of memory and 30G of HDD space.

Getting started

Check out the GitHub project for more information. After you install Minnaker, use the AWS Quick Start to learn how to configure Armory to deploy to AWS.

Continuous-Deployment: Configure Armory Continuous Deployment Using Kustomize

Mon, 01 Jan 0001 00:00:00 +0000

This guide is for both the Armory Operator and the Spinnaker Operator. Armory Continuous Deployment and Spinnaker configuration is the same except for features only in Armory Continuous Deployment. Those features are marked .

Why use Kustomize patches for Spinnaker configuration

Even though you can configure Armory Continuous Deployment or Spinnaker in a single manifest file, the advantage of using Kustomize patch files is readability, consistency across environments, and maintainability.

How Kustomize works

kubectl versions up to and including v1.20 come bundled with Kustomize v2.0.3. kubectl 1.21 comes bundled with Kustomize v4.0.5. Using Kustomize patches has been tested with kubectl v1.19.x. and standalone Kustomize v2 and v3. You may see a panic error if you use the spinnaker-kustomize-patches repo with Kustomize v4.0+ or kubectl v1.21+.

Kustomize resources

You should familiarize yourself with Kustomize before you create patch files to configure Armory Continuous Deployment.

Kubernetes requirements

You are familiar with Kubernetes Operators, which use custom resources to manage applications and their components.
You understand the concept of managing Kubernetes resources using manifests.
You have reviewed and met the Armory Continuous Deployment system requirements.

Spinnaker Kustomize patches repo

Configuration in this repository is meant for Armory Continuous Delivery. To make it compatible with Spinnaker instead, apply the utilities/switch-to-oss.yml patch.

To start, create your own copy of the spinnaker-kustomize-patches repository by clicking the Use this template button:

If you intend to update your copy from upstream, use Fork instead. See Creating a repository from a template for the difference between Use this template and Fork.

Once created, clone this repository to your local machine.

Configure Armory Continuous Deployment

Follow these steps to configure Armory Continuous Deployment:

Choose a kustomization.yml file.
(Optional) If you are deploying open source Spinnaker, change the apiVersion in each patch file.
Set the Armory Continuous Deployment (or Spinnaker) version.
Verify the content of each resource file.
Verify the configuration contents of each patch file.

Choose a `kustomization` file

Before you begin configuring Armory Continuous Deployment, you need to choose or create a kustomization.yml file. The kustomization.yml specifies the namespace for Armory Continuous Deployment, a list of Kubernetes resources, and a list of patch files to merge into the spinnakerservice.yml manifest file. For example, the recipes/kustomization-minimum.yml file contains the following:

#-----------------------------------------------------------------------------------------------------------------------
# Minimum Starting Point recipe
#
# Self contained Spinnaker installation with no external dependencies and no additional configuration needed.
# This is intended as a starting point for any kubernetes cluster.
# Not for production use.
#
# Features:
# - One Kubernetes account (Spinnaker's own cluster) for deployment targets
# - Spinnaker authentication disabled
# - Self hosted minio as a persistent storage
# - Self hosted redis backend for caching and temporal storage of services
#-----------------------------------------------------------------------------------------------------------------------
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: spinnaker

components:
 - core/base
 - core/persistence/in-cluster
 - targets/kubernetes/default

patchesStrategicMerge:
 - core/patches/version.yml

transformers:
 - utilities/unique-service-account.yml

The components section contains paths to directories that define collections of Kubernetes resources, such as: in-cluster Spinnaker persistence with Minio, Kubernetes Service Account and patches to enable the cluster in Spinnaker.
The patchesStrategicMerge section contains links to files that contain partial resource definitions. Kustomize uses these patch files to overwrite sections of components or resources, such as the SpinnakerService definition.

spinnaker-kustomize-patches/kustomization.yml is a symlink that points to spinnaker-kustomize-patches/recipes/kustomization-all.yml. There are multiple kustomization examples in the recipes directory. Choose the one that most closely resembles your use case and link to it. Alternately, you can delete the symlink, move your desired Kustomization file from recipes to the top-level directory, and rename the file to kustomization.yml.

Warning

If you are in an air-gapped environment and are using MinIO to host the Armory Continuous Deployment BOM, remove core/persistence/in-cluster/minio.yml from the list of resources to prevent the accidental deletion of the bucket when calling kubectl delete -k ..

Choose Open Source Spinnaker

This step is required only if you are deploying open source Spinnaker.

Add the following patch to your kustomization.yml file:

patches:
 - target:
 kind: SpinnakerService
 path: utilities/switch-to-oss.yml

Set the Armory Continuous Deployment version

In spinnaker-kustomize-patches/core/patches/version.yml, set the Armory CD version or Spinnaker version that you want to deploy, such as 2.34 (Armory Continuous Deployment) or 1.25.3 (Spinnaker).

1
2
3
4
5
6
7


kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 spinnakerConfig:
 config:
 version: 2.34

Verify resources

Read each file linked to from your chosen kustomization.yml file section to make sure that the Kubernetes resource as configured works with your environment.

Verify patches

Read each file linked to in the patchesStrategicMerge section. You may need to update each patch configuration with values specific to you and your environment. For example, the kustomization-quickstart.yml file described in the Choose a kustomization file section links to accounts/docker/patch-dockerhub.yml. You need to update that patch file with your own DockerHub credentials.

Explore the patches in various folders to see if there are any that you want to use. Remember to list additional patches in the patchesStrategicMerge section of your kustomization.yml file.

Secrets

If you want to store Spinnaker secrets in Kubernetes, we recommend using Kustomize generators.

Deploy Armory Continuous Deployment

Once you have configured your patch files, you can deploy Armory Continuous Deployment.

Create the spinnaker namespace:
```
kubectl create ns spinnaker
```
If you want to use a different namespace, you must update the namespace value in your kustomization.yml file.
(Optional) Verify the Kustomize build output:
```
kubectl kustomize <path-to-kustomization.yml>
```
This prints out the contents of the manifest file that Kustomize built based on your kustomization.yml file.

Apply the manifest:

kubectl apply -k <path-to-kustomization.yml>

Watch the install progress and see the pods being created:
```
kubectl -n spinnaker get spinsvc spinnaker -w
```

Help resources

Armory Operator and Armory Continuous Deployment: contact Armory Support or use the Spinnaker Slack #armory channel.
Spinnaker Operator and Spinnaker: Spinnaker Slack #kubernetes-operator channel.

What’s next

See the Manifest Reference for configuration options by section.
Learn how to manage your Spinnaker instance.
See the Errors and Troubleshooting guide if you encounter issues.

Continuous-Deployment: Install Armory Continuous Deployment in Amazon Web Services (AWS)

Mon, 01 Jan 0001 00:00:00 +0000

Armory Continuous Deployment (Armory CD) requires a license. For more information, contact Armory.

Overview of installing Armory in AWS

A running AWS EKS cluster.
An Amazon S3 (Simple Storage Service) bucket. You can use an existing one or create a new one.
An NGINX Ingress controller in your EKS cluster.

This document currently does not fully cover the following (see Next Steps for some links to achieve these)

TLS Encryption
Authentication/Authorization
Add K8s accounts to deploy to
Add cloud accounts to deploy to

AWS Resources

Before you install Armory on AWS, it is essential that you familiarize yourself with relevant AWS services.

Before you begin

You have reviewed and met the Armory Continuous Deployment system requirements.
You have a running EKS and can access the Kubernetes API. Either your user/role created the EKS cluster or your user/role has been added to the aws-auth configmap in the EKS cluster. See the AWS documentation for more details.
You have access to an S3 bucket or access to create an S3 bucket.
You have access to an IAM role or user with access to the S3 bucket or can create an IAM role or user with access to the S3 bucket.

This document is written with the following workflow in mind:

You have a machine (referred to as the workstation machine in this document) configured to use the aws CLI tool and a recent version of kubectl tool
You have a machine (referred to as the Halyard machine in this document) with the Docker daemon installed, and can run Docker containers on it
You can transfer files created on the workstation machine to the Halyard machine (to a directory mounted on a running Docker container)
These two machines can be the same machine

Furthermore:

On the Halyard machine:

Halyard (the tool used to install and manage Armory) is run in a Docker container on the Halyard machine
The Halyard container on the Halyard machine will be configured with the following volume mounts, which should be persisted or preserved to manage your Armory cluster
- .hal directory (mounted to /home/spinnaker/.hal) - stores all Halyard Armory configurations in a .hal/config YAML file and assorted subdirectories
- .secret directory (mounted to /home/spinnaker/.secret) stores all external secret keys and files used by Halyard
- resources directory (mounted to /home/spinnaker/resources) stores all Kubernetes manifests and other resources that help create Kubernetes resources
You will create kubeconfig files that will be added to the .secret directory

Note: If you are not using the Halyard Docker container, but sure to install kubectl before you install Halyard. Otherwise you will have to restart the Halyard daemon in order for hal to find kubectl in your $PATH. Execute hal shutdown and then any hal command to start the daemon.

On the workstation machine:

If using EKS, you can use the aws CLI tool to interact with the AWS API and configure/communicate with the following:
- EKS clusters (or, alternately, have a EKS cluster already built)
- S3 buckets (or, alternately, have an S3 bucket already built)
You have the kubectl (Kubernetes CLI tool) installed and are able to use it to interact with your Kubernetes cluster
You have a persistent working directory in which to work in. One option here is ~/aws-spinnaker
You will create AWS resources, such as service accounts, that will be permanently associated with your Armory cluster

Installation summary

In order to install Armory, this document covers the following:

Generating a kubeconfig file, which is a Kubernetes credential file that Halyard and Armory will use to communicate with the Kubernetes cluster where Armory will be installed
Creating an S3 bucket for Armory to store persistent configuration in
Creating an IAM user that Armory will use to access the S3 bucket
Running the Halyard daemon in a Docker container
- Persistent configuration directories from the workstation/host will be mounted into the container
Running the hal client interactively in the same Docker container, to:
- Build out the halconfig YAML file (.hal/config)
- Configure Armory/Halyard to use kubeconfig to install Armory
- Configure Armory with the IAM credentials and bucket information
- Turn on other recommended settings (artifacts and http artifact provider)
- Install Armory
- Expose Armory

Connect to the Kubernetes cluster

Armory needs a credential to talk to Kubernetes, so you must create a service account in your Kubernetes cluster.

Connecting to an EKS cluster

If you’re using an EKS cluster, you must be able to connect to the EKS cluster. This assumes you have already configured the aws CLI with credentials and a default region / availability zone (see installation directions here and configuration directions here)

Create the local working directory on your workstation. For the purposes of this document, we will be using ~/aws-spinnaker, but this can be any persistent directory on any Linux or OSX machine.
```
mkdir ~/aws-spinnaker
cd ~/aws-spinnaker
```
If you have access to the role that created the EKS cluster, you can create a kubeconfig with access to your Kubernetes cluster with this command:
```
aws eks update-kubeconfig --name <EKS_CLUSTER_NAME> --kubeconfig kubeconfig-aws
```
From here, you can validate access to the cluster with this command:
```
kubectl --kubeconfig kubeconfig-aws get namespaces
```

Connecting to other Kubernetes clusters

If you’ve stood up Kubernetes on AWS with KOPS or another Kubernetes tool, ensure that you can communicate with your Kubernetes cluster with kubectl.

Then, copy your kubeconfig file (this is typically located in ~/.kube/config) to your working directory:

cp ~/.kube/config ~/aws-spinnaker/kubeconfig-aws

Create a `kubeconfig` file for Halyard/Armory

Armory will be installed in its own namespace in your EKS or AWS-hosted Kubernetes cluster. For the purposes of this document, we will be installing Armory in the spinnaker-system namespace; you’re welcome to use a different namespace for this.

We’re going to create the following:

A namespace called spinnaker-system to install Armory in
A service account for that namespace
A role and rolebinding in that namespace, granting permissions to the service account
A kubeconfig containing credentials for the service account

This document uses the Armory spinnaker-tools Go CLI (available on Github) to create many of these resources. There are separate instructions to perform these steps manually.

Halyard uses this Kubeconfig file to create the Kubernetes deployment objects that create the microservices that compose Armory. This same Kubeconfig is passed to Armory so that Armory can see and manage its own resources.

Obtain the spinnaker-tools CLI tool. Go to https://github.com/armory/spinnaker-tools/releases, and download the latest release for your operating system (OSX and Linux available). You can also use curl:

# If you're not already in the directory
cd ~/aws-spinnaker
# If you're on Linux instead of OSX, use this URL instead:
# https://github.com/armory/spinnaker-tools/releases/download/0.0.6/spinnaker-tools-linux
curl -L https://github.com/armory/spinnaker-tools/releases/download/0.0.6/spinnaker-tools-darwin -o spinnaker-tools
chmod +x spinnaker-tools

Run the tool. Feel free to substitute other values for the parameters:

# The 'aws eks update-kubeconfig' command from above will create/update this file
SOURCE_KUBECONFIG=kubeconfig-aws
# Get the name of the context created by the aws tool)
CONTEXT=$(kubectl --kubeconfig ${SOURCE_KUBECONFIG} config current-context)
DEST_KUBECONFIG=kubeconfig-spinnaker-system-sa
SPINNAKER_NAMESPACE=spinnaker-system
SPINNAKER_SERVICE_ACCOUNT_NAME=spinnaker-service-account

./spinnaker-tools create-service-account \
 --kubeconfig ${SOURCE_KUBECONFIG} \
 --context ${CONTEXT} \
 --output ${DEST_KUBECONFIG} \
 --namespace ${SPINNAKER_NAMESPACE} \
 --service-account-name ${SPINNAKER_SERVICE_ACCOUNT_NAME}

You should be left with a file called kubeconfig-spinnaker-system-sa (or something similar, if you’re using a different namespace for spinnaker)

Create the S3 bucket and credentials

If you do not yet have an S3 bucket, create the S3 bucket:

Log into the AWS Console (web UI)
Navigate to the S3 Console (Click on “Services” at the top, and then on “S3” under “Storage”)
Click on “Create Bucket”
Specify a globally unique name for this bucket, in your AWS region of choice, following your organization’s naming convention (if applicable). For this document, we will use, spinnaker-jq6cqvmpro.
Click “Next”
Select the following two checkboxes:
- Keep all versions of an object in the same bucket
- Automatically encrypt objects when they are stored in S3
Click “Next”
Do not add any additional permissions, unless specified by your organization. Click “Next”
Click “Create bucket”

Armory (the front50 service, specifically) will need access to your newly-created bucket. There are a number of ways to achieve this. This document describes two mechanisms to do this.

By default, Armory will store all Armory information in a folder called front50 in your bucket. You can optionally specify a different directory (for example, if you’re using a pre-existing or shared S3 bucket).

Create an IAM user using an inline policy

You can create an IAM user with credentials, and provide that to Armory via Halyard

Log into the AWS Console (Web UI)
Navigate to the IAM Console (Click on “Services” at the top, and then on “IAM” under “Security, Identity, & Compliance”)
Click on “Users” on the left
Click on “Add user”
Give your user a distinct name, per your organization’s naming conventions. For this document, we will use s3-spinnaker-jq6cqvmpro
Click on “Programmatic access”
We will not be adding a distinct policy to this user. Click on “Next: Tags”. You may receive a warning about how there are no policies attached to this user - this warning can be ignored.
Optionally, add tags, then click on “Next: Review”
Click “Create user”
Save the Access Key ID and Secret Access Key - these will be used later, during Halyard configuration
Click “Close”

Then, add an inline policy to your IAM user:

Click on your newly-created IAM user
Click on “Add inline policy” (on the right)
Click on the “JSON” tab

Add this text (replace s3-spinnaker-jq6cqvmpro with the name of your bucket)

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": "s3:*",
 "Resource": [
 "arn:aws:s3:::spinnaker-jq6cqvmpro",
 "arn:aws:s3:::spinnaker-jq6cqvmpro/*"
 ]
 }
 ]
}

Click on “Review Policy”
Give your inline policy some name. For example s3-spinnaker-jq6cqvmpro
Click “Create Policy”

Create an IAM policy attached to the Kubernetes nodes using an inline policy

Alternately, you can attach an IAM policy to the role attached to your Kubernetes nodes.

Log into the AWS Console (Web UI)
Navigate to EC2 (Click on “Services” at the top, and then on “EC2” under “Compute”)
Click on one of your Kubernetes nodes
In the bottom section, look for “IAM role” and click on the role
Click on “Add inline policy” (on the right)
Click on the “JSON” tab

Add this text (replace s3-spinnaker-jq6cqvmpro with the name of your bucket)

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": "s3:*",
 "Resource": [
 "arn:aws:s3:::spinnaker-jq6cqvmpro",
 "arn:aws:s3:::spinnaker-jq6cqvmpro/*"
 ]
 }
 ]
}

Click on “Review Policy”
Give your inline policy some name. For example s3-spinnaker-jq6cqvmpro
Click “Create Policy”

Stage files on the Halyard machine

On the Halyard machine, choose a local working directory for Halyard. In it, we will create two folders:

WORKING_DIRECTORY/.hal
WORKING_DIRECTORY/.secret
WORKING_DIRECTORY/resources

# Feel free to use some other directory for this; make sure it is a persistent directory.
# Also, make sure this directory doesn't live on an NFS mount, as that can cause issues
WORKING_DIRECTORY=~/aws-spinnaker/
mkdir -p ${WORKING_DIRECTORY}/.hal
mkdir -p ${WORKING_DIRECTORY}/.secret
mkdir -p ${WORKING_DIRECTORY}/resources

You should have one files:

A kubeconfig file (kubeconfig-spinnaker-system-sa) with the credentials for a service account in your EKS cluster

Copy it into .secret so it is available to your Halyard docker container:

cp kubeconfig-spinnaker-system-sa ${WORKING_DIRECTORY}/.secret

Start the Halyard container

On the Halyard machine, start the Halyard container .

If you want to install open source Spinnaker instead, use gcr.io/spinnaker-marketplace/halyard:stable for the Docker Halyard image reference in substitution of armory/halyard-armory:<image_version> in the commands below

Before you execute the command below, you need to set permissions on the host (local) directories mapped to the Docker container. These directories must allow for modification from within the container. The ~/.hal folder within the host (local) system directory needs write permissions (chmod 777 ~/.hal), or you will encounter issues when attempting to execute a hal deploy apply from within the container.

docker run --name armory-halyard -it --rm \
 -v ${WORKING_DIRECTORY}/.hal:/home/spinnaker/.hal \
 -v ${WORKING_DIRECTORY}/.secret:/home/spinnaker/.secret \
 -v ${WORKING_DIRECTORY}/resources:/home/spinnaker/resources \
 armory/halyard-armory:1.12.1

The installer expects to find your kubeconfig named config in the .kube directory you map below. If you’ve named your config something else, you need to rename or symlink the file accordingly.

Enter the Halyard container

From a separate terminal session on your docker machine, create a second bash/shell session on the Docker container:

docker exec -it armory-halyard bash

# Also, once in the container, you can run these commands for a friendlier environment to:
# - prompt with information
# - alias for ls
# - cd to the home directory
export PS1="\h:\w \u\$ "
alias ll='ls -alh'
cd ~

Add the kubeconfig and cloud provider to Armory (via Halyard)

From the docker exec separate terminal session, add (re-export) the relevant environment variables

###### Use the same values as the start of the document
# Enter the namespace that you want to install Armory in. This should have been created in the previous step.
export NAMESPACE="spinnaker-system"

# Enter the name you want Armory to use to identify the cloud provider account
export ACCOUNT_NAME="spinnaker"

# Update this with the full path to your kubeconfig inside the container)
export KUBECONFIG_FULL=/home/spinnaker/.secret/kubeconfig-spinnaker-system-sa

Use the Halyard hal command line tool to add a Kubernetes account using your minified kubeconfig

Configure the kubeconfig:

# Enable the Kubernetes cloud provider
hal config provider kubernetes enable

Note: If you get an AccessDenied error, change permissions on the host machine’s .hal folder to allow read/write access by the Halyard container. Example: chmod 777 ~/.hal.

Next, configure the account:

# Add account
hal config provider kubernetes account add ${ACCOUNT_NAME} \
 --provider-version v2 \
 --kubeconfig-file ${KUBECONFIG_FULL} \
 --only-spinnaker-managed true \
 --namespaces ${NAMESPACE}

Configure Armory to install in Kubernetes

Important: This will by default limit your Armory to deploying to the namespace specified. If you want to be able to deploy to other namespaces, either add a second cloud provider target or remove the --namespaces flag.

Use the Halyard hal command line tool to configure Halyard to install Armory in your Kubernetes cluster

hal config deploy edit \
 --type distributed \
 --account-name ${ACCOUNT_NAME} \
 --location ${NAMESPACE}

Enable Artifacts

Within Armory, ‘artifacts’ are consumable references to items that live outside of Armory, such as a file in a git repository or a file in an S3 bucket. The Artifacts feature must be explicitly turned on.

Enable the “Artifacts” feature and the “http” artifact provider:

# Enable artifacts
hal config features edit --artifacts true
hal config artifact http enable

(In order to add specific types of artifacts, there are further configuration items that must be completed. For now, it is sufficient to just turn on the artifacts feature with the http artifact provider. This will allow Armory to retrieve files via unauthenticated http.)

Configure Armory to use your S3 bucket

Use the Halyard hal command line tool to configure Halyard to configure Armory to use your S3 bucket

If you are using an IAM user

# Update these with the information from the bucket that you created
export BUCKET_NAME=spinnaker-jq6cqvmpro
export REGION=us-west-2
export ACCESS_KEY_ID=<access-key>

# This will prompt for the secret key
hal config storage s3 edit \
 --bucket ${BUCKET_NAME} \
 --access-key-id ${ACCESS_KEY_ID} \
 --secret-access-key \
 --region ${REGION}

hal config storage edit --type s3

If you are using the IAM instance roles

# Update these with the information from the bucket that you created
export BUCKET_NAME=spinnaker-jq6cqvmpro
export REGION=us-west-2

# This will prompt for the secret key
hal config storage s3 edit \
 --bucket ${BUCKET_NAME} \
 --region ${REGION} \
 --no-validate

hal config storage edit --type s3

If you want to use a specific folder in the bucket

By default, Halyard will configure Armory to use the folder front50 in your S3 bucket. You can configure it to use a different folder with this command:

ROOT_FOLDER=not_front50
hal config storage s3 edit --root-folder ${ROOT_FOLDER}

Choose the Armory version

Before Halyard will install Armory, you should specify the version of Armory you want to use.

You can get a list of available versions of spinnaker with this command:

hal version list

If you are installing Armory, you will get a version that starts with 2.x.x

If you are installing open source Spinnaker and using gcr.io/spinnaker-marketplace/halyard:stable, you will get a version that starts with 1.x.x

And then you can select the version with this:

# Replace with version of choice:
export VERSION=$(hal version latest -q)
hal config version edit --version $VERSION

Install Armory

Now that your Halconfig is completely configured for the initial Armory deployment, you can tell Halyard to actually install Armory:

hal deploy apply

Once this is complete, congratulations! Armory Continuous Deployment is installed. Now, we have to access and expose it.

Connect to Armory Continuous Deployment using `kubectl port-forward`

If you have kubectl on a local machine with access to your Kubernetes cluster, you can test connecting to it with the following:

NAMESPACE=spinnaker-system
DECK_POD=$(kubectl -n ${NAMESPACE} get pod -l cluster=spin-deck -ojsonpath='{.items[0].metadata.name}')
GATE_POD=$(kubectl -n ${NAMESPACE} get pod -l cluster=spin-gate -ojsonpath='{.items[0].metadata.name}')
kubectl -n ${NAMESPACE} port-forward ${DECK_POD} 9000 &
kubectl -n ${NAMESPACE} port-forward ${GATE_POD} 8084 &

Then, you can access Armory at http://localhost:9000

(If you are doing this on a remote machine, this will not work because your browser attempts to access localhost on your local workstation rather than on the remote machine where the port is forwarded)

Note: Even if the hal deploy apply command returns successfully, the installation may not be complete yet. This is especially the case with distributed Kubernetes installs. If you see errors such as Connection refused, the containers may not be available yet. You can either wait or check the status of all of the containers using the command for your cloud provider (such as kubectl get pods --namespace spinnaker).

Install the NGINX ingress controller

In order to expose Armory to end users, you have perform the following actions:

Expose the spin-deck (UI) Kubernetes service on some URL endpoint
Expose the spin-gate (API) Kubernetes service on some URL endpoint
Update Armory (via Halyard) to be aware of the new endpoints

We’re going to install the NGINX ingress controller on AWS (this uses the Layer 4 ELB, as indicated in the NGINX ingress controller documentation - you can use other NGINX ingress controller configurations such as the Layer 7 load balancer per your organization’s ingress policy.)

(Both of these are configurable with Armory, but the NGINX ingress controller is also generally much more configurable)

From the workstation machine (where kubectl is installed):

Install the NGINX ingress controller components:

kubectl --kubeconfig kubeconfig-aws apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/aws/deploy.yaml

Install the NGINX ingress controller AWS-specific service:

kubectl --kubeconfig kubeconfig-aws apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/aws/service-l4.yaml
kubectl --kubeconfig kubeconfig-aws apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/aws/patch-configmap-l4.yaml

Set up the Ingress for `spin-deck` and `spin-gate`

Identify the URLs you will use to expose Armory’s UI and API.

# Replace with actual values
SPIN_DECK_ENDPOINT=spinnaker.some-url.com
SPIN_GATE_ENDPOINT=api.some-url.com
NAMESPACE=spinnaker-system

Create a Kubernetes Ingress manifest to expose spin-deck and spin-gate (change your hosts and namespace accordingly):

tee spin-ingress.yaml <<-'EOF'
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
 name: spinnaker-nginx-ingress
 namespace: NAMESPACE
 labels:
 app: spin
 cluster: spin-ingress
 annotations:
 kubernetes.io/ingress.class: "nginx"
spec:
 rules:
 - host: SPIN_DECK_ENDPOINT
 http:
 paths:
 - backend:
 serviceName: spin-deck
 servicePort: 9000
 path: /
 - host: SPIN_GATE_ENDPOINT
 http:
 paths:
 - backend:
 serviceName: spin-gate
 servicePort: 8084
 path: /
EOF

sed -i.bak \
 -e "s|NAMESPACE|${NAMESPACE}|g" \
 -e "s|SPIN_DECK_ENDPOINT|${SPIN_DECK_ENDPOINT}|g" \
 -e "s|SPIN_GATE_ENDPOINT|${SPIN_GATE_ENDPOINT}|g" \
 spin-ingress.yaml

Create the Ingress

kubectl apply -f spin-ingress.yaml

Configure Armory to be aware of its endpoints

Armory must be aware of its endpoints to work properly.

This should be done from the halyard container:

SPIN_DECK_ENDPOINT=spinnaker.some-url.com
SPIN_GATE_ENDPOINT=api.some-url.com
SPIN_DECK_URL=http://${SPIN_DECK_ENDPOINT}
SPIN_GATE_URL=http://${SPIN_GATE_ENDPOINT}

hal config security ui edit --override-base-url ${SPIN_DECK_URL}
hal config security api edit --override-base-url ${SPIN_GATE_URL}

hal deploy apply

Set up DNS

Once the ingress is up (this may take some time), you can get the IP address for the ingress:

$ kubectl describe -n spinnaker-system ingress spinnaker-nginx-ingress
Name: spinnaker-nginx-ingress
Namespace: spinnaker-system
Address: 35.233.216.189
Default backend: default-http-backend:80 (10.36.2.7:8080)
Rules:
 Host Path Backends
 ---- ---- --------
 spinnaker.some-url.com
 / spin-deck:9000 (<none>)
 api.some-url.com
 / spin-gate:8084 (<none>)
Annotations:
 kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"extensions/v1beta1","kind":"Ingress","metadata":{"annotations":{"kubernetes.io/ingress.class":"nginx"},"name":"spinnaker-nginx-ingress","namespace":"spinnaker"},"spec":{"rules":[{"host":"spinnaker.some-url.com","http":{"paths":[{"backend":{"serviceName":"spin-deck","servicePort":9000},"path":"/"}]}},{"host":"api.some-url.com","http":{"paths":[{"backend":{"serviceName":"spin-gate","servicePort":8084},"path":"/"}]}}]}}

 kubernetes.io/ingress.class: nginx
Events:
 Type Reason Age From Message
 ---- ------ ---- ---- -------
 Normal CREATE 28s nginx-ingress-controller Ingress spinnaker/spinnaker-nginx-ingress
 Normal UPDATE 20s nginx-ingress-controller Ingress spinnaker/spinnaker-nginx-ingress

Set up DNS so that your two URLs point to the IP address for the ingress (in the above, configure spinnaker.some-url.com and api.some-url.com to point to 35.233.216.189). This can be done via whatever your organization uses for DNS.

Configuring TLS certificates

Configuration of TLS certificates for ingresses is often very organization-specific. In general, you would want to do the following:

Add certificate(s) so that your ingress controller can use them
Configure the ingress(es) so that NGINX (or your ingress) terminates TLS using the certificate(s)
Update Armory to be aware of the new TLS endpoints (note https instead of http)

SPIN_DECK_ENDPOINT=spinnaker.some-url.com
SPIN_GATE_ENDPOINT=api.some-url.com
SPIN_DECK_URL=https://${SPIN_DECK_ENDPOINT}
SPIN_GATE_URL=https://${SPIN_GATE_ENDPOINT}
hal config security ui edit --override-base-url ${SPIN_DECK_URL}
hal config security api edit --override-base-url ${SPIN_GATE_URL}
hal deploy apply

Next steps

Now that you have Armory up and running, here are some of the next things you may want to do:

Configuration of certificates to secure your cluster (see this section for notes on this)
Configuration of Authentication/Authorization (see the Open Source Spinnaker documentation)
Add Kubernetes accounts to deploy applications to (see Creating and Adding a Kubernetes Account to Armory as a Deployment Target)
Add GCP accounts to deploy applications to (see the Open Source Spinnaker documentation)
Add AWS accounts to deploy applications to (see the Open Source Spinnaker documentation)

Continuous-Deployment: Spinnaker Nomenclature and Naming Conventions

Mon, 01 Jan 0001 00:00:00 +0000

Nomenclature

Application

An application inside Spinnaker represents what you would typically find in a single code repository - and in many cases, an application maps directly to a microservice.

Cluster

A server group is a regional view of servers, whereas a cluster is a world-wide view of server groups.

Execution

When a pipeline runs, the end result is called an execution.

Pipeline

A pipeline in Spinnaker is a series of stages linked together that can be executed serially or in parallel. All pipelines are defined in the context of an application. A typical pipeline will contain stages for “creating images”, “testing”, and “deploying”. The process of “creating images” is also commonly referred to as a “bake”.

Project

A project inside Spinnaker is a logical grouping of applications. For example, we might create a project called “Spinnaker” and its applications would be “Deck”, “Orca”, “Clouddriver”, etc. Spinnaker provides a helpful dashboard view for each project to visualize its applications and status of each application contained within it.

Server Group

From an Amazon Web Service (AWS) point of view, a server group is represented by an auto-scaling group (ASGs). All applications that are deployed by Spinnaker are deployed to server groups.

Stage

Within a pipeline, the tasks that pipeline performs are called stages.

Trigger

A trigger is the entry point to a pipeline.

Spinnaker Naming Conventions

Spinnaker has very specific naming conventions that help it identify resources in your cloud account.

Clusters and server groups follow the convention application_name-stack-detail-infrastructure_version

Application

The ‘Name’ is the name of your application in Spinnaker.

Stack

You can think of a ‘Stack’ as a tag you give to anything that you want to be integrated together. Environments are usually a good example of something you would tag with a Stack. If you have an app that has an ELB, a Cache, and an ASG, usually you would want to run integration tests on your staging environment separately from your production environment. In that case, you would give the staging ELB, Cache, and ASG all the “staging” stack, while prod ELB, Cache, and ASG would be the “prod” stack.

Note that Stack names are defined by the user in the Spinnaker configuration User Interface (UI).

Detail

Detail is also user-defined and can be any additional piece of information you want to label your cluster and server group with.

Infrastructure Version

The infrastructure’s version number; such as v011, v012, etc. This is automatically appended and is not user defined.

In AWS, Spinnaker will name your ASGs and Launch Configurations according to the naming convention mentioned above (ie. “armoryspinnaker-prod-polling-v015”).

Please note that if your user definition includes a hyphen, it will disrupt the naming convention.

Continuous-Deployment: Deploy and manage a Spinnaker Application with Quick Spin

Mon, 01 Jan 0001 00:00:00 +0000

Learning objectives

This tutorial demonstrates how to:

Create a Spinnaker application
Deploy and manage a Spinnaker pipeline for your application
Deploy updates to the application
Monitor the health of your application

Before you begin

Before you begin make sure you have installed Quick Spin and have an active instance running on locahost:9000 as described in Instructions for Trying Armory Continuous Deployment Self-Hosted.

Make sure you have installed Quick Spin and have an active instance running on locahost:9000. See Instructions for Trying Armory Continuous Deployment Self-Hosted.
You have an active GitHub account.
You have Javascript enabled in your favorite code editor.

Create a minikube or kind cluster

(Refer to topic explaining how to create these types of K8s)

Run the Spinnaker prep pipeline

Fork the tutorial repository:

Navigate to:

https://github.com/arnab-datta/counter-app

Create a fork to your personal GitHub account.
(Optional) Clone the fork.

Create an application

Navigate to the running Quick Spin instance:
```
http://localhost:9000
```
Select Create Application.

Update the application

Monitor the pipeline

Tear down an environment

Next steps

Continuous-Deployment: Spinnaker™ Architecture

Mon, 01 Jan 0001 00:00:00 +0000

Armory Continuous Deployment architecture

Armory Continuous Deployment is an enterprise version of open source Spinnaker. It is composed of several microservices for resiliency and follows the single-responsibility principle. It allows for faster iteration on each individual component and a more pluggable architecture for custom components. See the open source Spinnaker microservices overview for port mappings and a table of service interdependencies.

Armory Continuous Deployment microservices

Clouddriver

Clouddriver is a core component of Armory Continuous Deployment and facilitates the interaction between a given cloud provider such as AWS, GCP or Kubernetes. There is a common interface that is used so that additional cloud providers can be added.

Deck

Deck is the UI for interactive and visualizing the state of cloud resources. It depends on Gate to interact with the cloud providers.

Echo

Echo is the service for Spinnaker which manages notifications, alerts and scheduled pipelines (Cron). It can also propagate these events out to other REST endpoints such as an Elastic Search, Splunk’s HTTP Event Collector or a custom event collector/processor.

Fiat

Fiat is the microservice responsible for authorization (authz) for the other microservices. By default, it is not enabled, so users are able to perform any action in Armory Continuous Deployment.

Front50

Front50 is the persistent datastore for Spinnaker. Most notabily pipelines, configurations, and jobs.

Gate

Gate is the front-end API that is exposed to the users of your Spinnaker instance. It also manages authentication and authorization for sub-service APIs and resources with Spinnaker. All communication between the UI and the back-end services happen through Gate. You can find a list of the endpoints available through Swagger: http://${GATE_HOST}:8084/swagger-ui.html

Igor

Igor is a wrapper API which communicates with Jenkins. It is responsible for kicking-off jobs and reporting the state of running or completing jobs.

Kayenta

Kayenta is Spinnaker’s canary analysis service, integrating with 3rd party monitoring services such as Datadog or Prometheus.

Orca

Orca is responsible for the orchestration of pipelines, stages, and tasks within Armory Continuous Deployment. Orca acts as the “traffic cop” within Armory Continuous Deployment making sure that sub-services, their executions and states are passed along correctly.

The smallest atomic unit within Orca is a task - stages are composed of tasks and pipelines are composed of stages.

Rosco

Rosco is the “bakery” service. It is a wrapper around Hashicorp’s Packer command line tool which bakes images for AWS, GCP, Docker, Azure, and other builders.

Armory Continuous Deployment proprietary microservices

Armory Scale Agent for Spinnaker and Kubernetes

The Scale Agent for Spinnaker and Kubernetes is a lightweight, scalable service that monitors your Kubernetes infrastructure and streams changes back to the Clouddriver service.

Dinghy

Dinghy is the microservice used to manage Pipelines-as-Code. It supports two main capabilities:

Automatically synchronizing pipeline definitions from an external Github or BitBucket repository to Armory.
Creating a library of pipeline modules (components) that can be templatized and used in Dinghy-managed pipeline definitions.

Policy Engine

The Armory Policy Engine is designed to allow enterprises more complete control of their software delivery process by providing them with the hooks necessary to perform more extensive verification of their pipelines and processes in Spinnaker. This policy engine is backed by Open Policy Agent(OPA) and uses input style documents to perform validation of pipelines during save time and runtime

Terraformer

Terraformer is the microservice behind Armory’s Terraform Integration. It allows Armory to natively use your infrastructure-as-code Terraform scripts as part of a deployment pipeline.

Installation and management

Armory Operator

The Armory Operator is a Kubernetes Operator that makes it easy to install, deploy, and upgrade Armory Continuous Deployment.

Continuous-Deployment: Configure Armory Continuous Deployment Using a Manifest File

Mon, 01 Jan 0001 00:00:00 +0000

This guide is for both the Armory Operator and the Spinnaker Operator. Armory Continuous Deployment and Spinnaker configuration is the same except for features only in Armory Continuous Deployment. Those features are marked .

Before you begin

This guide assumes you want to expand the manifest file used in the Quickstart.
You know how to deploy Armory Continuous Deployment using a Kubernetes manifest file. See the Quickstart’s Single manifest file section.

Kubernetes manifest file

The structure of the manifest file is the same whether you are using the Armory Operator or the Spinnaker Operator. The value of certain keys, though, depends on whether you are deploying Armory Continuous Deployment or Spinnaker. The following snippet is the first several lines from a spinnakerservice.yml manifest that deploys Armory Continuous Deployment.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 spinnakerConfig:
 config:
 version: <version>
 persistentStorage:
 persistentStoreType: s3
 s3:
 bucket: <s3-bucket-name>
 rootFolder: front50

Line 1: apiVersion is the CRD version of the SpinnakerService custom resource.
- If you are deploying Armory Continuous Deployment, the value is spinnaker.armory.io/v1alpha2; if you change this value, the Armory Operator won’t process the manifest file.
- If you are deploying Spinnaker, the value is spinnaker.io/v1alpha2; if you change this value, the Spinnaker Operator won’t process the manifest file.
Line 8: spec.spinnakerConfig.config.version
- If you are using the Armory Operator, this is the version of Armory Continuous Deployment you want to deploy; for example, 2.34.
- If you are using the Spinnaker Operator, this is the version of Spinnaker you want to deploy; for example, 1.25.

Expand to see a skeleton manifest file

This file is from the public armory/spinnaker-operator repo. You use this file to configure and deploy Spinnaker. Note that the apiVersion is the SpinnakerService CRD used by the Spinnaker Operator.

apiVersion: spinnaker.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 # spec.spinnakerConfig - This section is how to specify configuration spinnaker
 spinnakerConfig:
 # spec.spinnakerConfig.config - This section contains the contents of a deployment found in a halconfig .deploymentConfigurations[0]
 config:
 version: 1.28.1 # the version of Spinnaker to be deployed
 persistentStorage:
 persistentStoreType: s3
 s3:
 bucket: <change-me> # Change to a unique name. Spinnaker stores application and pipeline definitions here
 rootFolder: front50

 # spec.spinnakerConfig.profiles - This section contains the YAML of each service's profile
 profiles:
 clouddriver: {} # is the contents of ~/.hal/default/profiles/clouddriver.yml
 # deck has a special key "settings-local.js" for the contents of settings-local.js
 deck:
 # settings-local.js - contents of ~/.hal/default/profiles/settings-local.js
 # Use the | YAML symbol to indicate a block-style multiline string
 settings-local.js: |
  window.spinnakerSettings.feature.kustomizeEnabled = true;
 echo: {} # is the contents of ~/.hal/default/profiles/echo.yml
 fiat: {} # is the contents of ~/.hal/default/profiles/fiat.yml
 front50: {} # is the contents of ~/.hal/default/profiles/front50.yml
 gate: {} # is the contents of ~/.hal/default/profiles/gate.yml
 igor: {} # is the contents of ~/.hal/default/profiles/igor.yml
 kayenta: {} # is the contents of ~/.hal/default/profiles/kayenta.yml
 orca: {} # is the contents of ~/.hal/default/profiles/orca.yml
 rosco: {} # is the contents of ~/.hal/default/profiles/rosco.yml

 # spec.spinnakerConfig.service-settings - This section contains the YAML of the service's service-setting
 # see https://www.spinnaker.io/reference/halyard/custom/#tweakable-service-settings for available settings
 service-settings:
 clouddriver: {}
 deck: {}
 echo: {}
 fiat: {}
 front50: {}
 gate: {}
 igor: {}
 kayenta: {}
 orca: {}
 rosco: {}

 # spec.spinnakerConfig.files - This section allows you to include any other raw string files not handle above.
 # The KEY is the filepath and filename of where it should be placed
 # - Files here will be placed into ~/.hal/default/ on halyard
 # - __ is used in place of / for the path separator
 # The VALUE is the contents of the file.
 # - Use the | YAML symbol to indicate a block-style multiline string
 # - We currently only support string files
 # - NOTE: Kubernetes has a manifest size limitation of 1MB
 files: {}
 # profiles__rosco__packer__example-packer-config.json: |
 # {
 # "packerSetting": "someValue"
 # }
 # profiles__rosco__packer__my_custom_script.sh: |
 # #!/bin/bash -e
 # echo "hello world!"

 # spec.expose - This section defines how Spinnaker should be publicly exposed
 expose:
 type: service # Kubernetes LoadBalancer type (service/ingress), note: only "service" is supported for now
 service:
 type: LoadBalancer

 # annotations to be set on Kubernetes LoadBalancer type
 # they will only apply to spin-gate, spin-gate-x509, or spin-deck
 annotations:
 service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
 # uncomment the line below to provide an AWS SSL certificate to terminate SSL at the LoadBalancer
 #service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:us-west-2:9999999:certificate/abc-123-abc

 # provide an override to the exposing KubernetesService
 overrides: {}
 # Provided below is the example config for the Gate-X509 configuration
# deck:
# annotations:
# service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:us-west-2:9999999:certificate/abc-123-abc
# service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
# gate:
# annotations:
# service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:us-west-2:9999999:certificate/abc-123-abc
# service.beta.kubernetes.io/aws-load-balancer-backend-protocol: https # X509 requires https from LoadBalancer -> Gate
# gate-x509:
# annotations:
# service.beta.kubernetes.io/aws-load-balancer-backend-protocol: tcp
# service.beta.kubernetes.io/aws-load-balancer-ssl-cert: null
# publicPort: 443

 validation: {}

 # Patching of generated service or deployment by Spinnaker service.
 # Like in Kustomize, several patch types are supported. See
 # https://github.com/armory/spinnaker-operator/blob/master/doc/options.md#speckustomize
 kustomize: {}
 # An example to change Gate's image name using a strategic merge patch
# gate:
# deployment:
# patchesStrategicMerge:
# - |
# spec:
# template:
# spec:
# containers:
# - name: gate
# image: gate:1.0.0

Manifest sections

metadata.name

apiVersion: apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker

metadata.name is the name of your Armory Continuous Deployment service. Use this name to view, edit, or delete Armory Continuous Deployment. The following example uses the name prod:

$ kubectl get spinsvc prod

Note that you can use spinsvc for brevity. You can also use spinnakerservices.spinnaker.armory.io (Armory Continuous Deployment) or spinnakerservices.spinnaker.io (Spinnaker).

spec.spinnakerConfig

Contains the same information as the deploymentConfigurations entry in a Halyard configuration.

For example, given the following ~/.hal/config file:

currentDeployment: default
deploymentConfigurations:
- name: default
 version: 2.17.1
 persistentStorage:
 persistentStoreType: s3
 s3:
 bucket: mybucket
 rootFolder: front50

The equivalent of that Halyard configuration is the following spec.spinnakerConfig:

apiVersion: apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 spinnakerConfig:
 config:
 version: 2.17.1
 persistentStorage:
 persistentStoreType: s3
 s3:
 bucket: mybucket
 rootFolder: front50

spec.spinnakerConfig.config contains the following sections:

spec.spinnakerConfig.profiles

Configuration for each service profile. This is the equivalent of ~/.hal/default/profiles/<service>-local.yml. For example the following profile is for Gate:

spec:
 spinnakerConfig:
 config:
 ...
 profiles:
 gate:
 default:
 apiPort: 8085

Note that for Deck, the profile is a string under the key settings-local.js:

spec:
 spinnakerConfig:
 config:
 ...
 profiles:
 deck:
 settings-local.js: |
  window.spinnakerSettings.feature.artifactsRewrite = true;

spec.spinnakerConfig.service-settings

Settings for each service. This is the equivalent of ~/.hal/default/service-settings/<service>.yml. For example the following settings are for Clouddriver:

spec:
 spinnakerConfig:
 config:
 ...
 service-settings:
 clouddriver:
 kubernetes:
 serviceAccountName: spin-sa

spec.spinnakerConfig.files

Contents of any local files that should be added to the services. For example to reference the contents of a kubeconfig file:

spec:
 spinnakerConfig:
 config:
 providers:
 kubernetes:
 enabled: true
 accounts:
 - name: cluster-1
 kubeconfigFile: cluster1-kubeconfig
 ...
 files:
 cluster1-kubeconfig: |
  <FILE CONTENTS HERE>

A double underscore (__) in the file name is translated to a path separator (/). For example to add custom packer templates:

 files: {}
 profiles__rosco__packer__example-packer-config.json: |
 {
 "packerSetting": "someValue"
 }
 profiles__rosco__packer__my_custom_script.sh: |
 #!/bin/bash -e
 echo "hello world!"

spec.expose

Optional. Controls how Armory Continuous Deploymentgets exposed. If you omit it, no load balancer gets created. If this section gets removed, the Load Balancer does not get deleted.

Use the following configurations:

spec.expose.type: How Armory Continuous Deploymentgets exposed. Currently, only service is supported, which uses Kubernetes services to expose Spinnaker.
spec.expose.service: Service configuration
spec.expose.service.type: Should match a valid Kubernetes service type (i.e. LoadBalancer, NodePort, or ClusterIP).
spec.expose.service.annotations: Map containing annotations to be added to Gate (API) and Deck (UI) services.
spec.expose.service.overrides: Map with key for overriding the service type and specifying extra annotations: Armory Continuous Deploymentservice name (Gate or Deck) and value. By default, all services receive the same annotations. You can override annotations for a Deck (UI) or Gate (API) services.

spec.validation

Currently these configurations are experimental. By default, the Operator always validates Kubernetes accounts when applying a SpinnakerService manifest.

Validation options that apply to all validations that Operator performs:

spec.validation.failOnError: Boolean. Defaults to true. If false, the validation runs and the results are logged, but the service is always considered valid.
spec.validation.failFast: Boolean. Defaults to false. If true, validation stops at the first error.
spec.validation.frequencySeconds: Optional. Integer. Define a grace period before a validation runs again. For example, if you specify a value of 120 and edit the SpinnakerService without changing an account within a 120 second window, the validation on that account does not run again.

Additionally, the following settings are specific to Kubernetes, Docker, AWS, AWS S3, CI tools, metric stores, persistent storage, or notification systems:

spec.validation.providers.kubernetes
spec.validation.providers.docker
spec.validation.providers.aws
spec.validation.providers.s3
spec.validation.providers.ci
spec.validation.providers.metricStores
spec.validation.providers.persistentStorage
spec.validation.providers.notifications

Supported settings are enabled (set to false to turn off validations), failOnError, and frequencySeconds.

The following example disables all Kubernetes account validations:

spec:
 validation:
 providers:
 kubernetes:
 enabled: false

spec.accounts

Support for SpinnakerAccount CRD (Experimental):

spec.accounts.enabled: Boolean. Defaults to false. If true, the SpinnakerService uses all SpinnakerAccount objects enabled.
spec.accounts.dynamic (experimental): Boolean. Defaults to false. If true, SpinnakerAccount objects are available to Armory Continuous Deployment as the account is applied (without redeploying any service).

Example Manifests for exposing Armory Continuous Deployment

Load balancer Services

spec:
 expose:
 type: service
 service:
 type: LoadBalancer
 annotations:
 "service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "http"
 "service.beta.kubernetes.io/aws-load-balancer-ssl-ports": "80,443"
 "service.beta.kubernetes.io/aws-load-balancer-ssl-cert": "arn:aws:acm:us-west-2:xxxxxxxxxxxx:certificate/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

The preceding manifest generates these two services:

spin-deck

apiVersion: v1
kind: Service
metadata:
 annotations:
 service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
 service.beta.kubernetes.io/aws-load-balancer-ssl-ports: 80,443
 service.beta.kubernetes.io/aws-load-balancer-ssl-cert": arn:aws:acm:us-west-2:xxxxxxxxxxxx:certificate/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 labels:
 app: spin
 cluster: spin-deck
 name: spin-deck
spec:
 ports:
 - name: deck-tcp
 nodePort: xxxxx
 port: 9000
 protocol: TCP
 targetPort: 9000
 selector:
 app: spin
 cluster: spin-deck
 sessionAffinity: None
 type: LoadBalancer

spin-gate

apiVersion: v1
kind: Service
metadata:
 annotations:
 service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
 service.beta.kubernetes.io/aws-load-balancer-ssl-ports: 80,443
 service.beta.kubernetes.io/aws-load-balancer-ssl-cert": arn:aws:acm:us-west-2:xxxxxxxxxxxx:certificate/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 labels:
 app: spin
 cluster: spin-gate
 name: spin-gate
spec:
 ports:
 - name: gate-tcp
 nodePort: xxxxx
 port: 8084
 protocol: TCP
 targetPort: 8084
 selector:
 app: spin
 cluster: spin-gate
 sessionAffinity: None
 type: LoadBalancer

Different service types for Deck (UI) and Gate (API)

spec:
 expose:
 type: service
 service:
 type: LoadBalancer
 annotations:
 "service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "http"
 "service.beta.kubernetes.io/aws-load-balancer-ssl-ports": "80,443"
 "service.beta.kubernetes.io/aws-load-balancer-ssl-cert": "arn:aws:acm:us-west-2:xxxxxxxxxxxx:certificate/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
 overrides:
 gate:
 type: NodePort

The preceding manifest generates these two services:

spin-deck

apiVersion: v1
kind: Service
metadata:
 annotations:
 service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
 service.beta.kubernetes.io/aws-load-balancer-ssl-ports: 80,443
 service.beta.kubernetes.io/aws-load-balancer-ssl-cert": arn:aws:acm:us-west-2:xxxxxxxxxxxx:certificate/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 labels:
 app: spin
 cluster: spin-deck
 name: spin-deck
 spec:
 ports:
 - name: deck-tcp
 nodePort: xxxxx
 port: 9000
 protocol: TCP
 targetPort: 9000
 selector:
 app: spin
 cluster: spin-deck
 sessionAffinity: None
 type: LoadBalancer

spin-gate

apiVersion: v1
kind: Service
metadata:
 annotations:
 service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
 service.beta.kubernetes.io/aws-load-balancer-ssl-ports: 80,443
 service.beta.kubernetes.io/aws-load-balancer-ssl-cert": arn:aws:acm:us-west-2:xxxxxxxxxxxx:certificate/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 labels:
 app: spin
 cluster: spin-gate
 name: spin-gate
spec:
 ports:
 - name: gate-tcp
 nodePort: xxxxx
 port: 8084
 protocol: TCP
 targetPort: 8084
 selector:
 app: spin
 cluster: spin-gate
 sessionAffinity: None
 type: NodePort

Different annotations for Deck (UI) and Gate (API)

spec:
 expose:
 type: service
 service:
 type: LoadBalancer
 annotations:
 "service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "http"
 "service.beta.kubernetes.io/aws-load-balancer-ssl-ports": "80,443"
 "service.beta.kubernetes.io/aws-load-balancer-ssl-cert": "arn:aws:acm:us-west-2:xxxxxxxxxxxx:certificate/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
 overrides:
 gate:
 annotations:
 "service.beta.kubernetes.io/aws-load-balancer-internal": "true"

The preceding manifest file generates these two services:

spin-deck

apiVersion: v1
kind: Service
metadata:
 annotations:
 service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
 service.beta.kubernetes.io/aws-load-balancer-ssl-ports: 80,443
 service.beta.kubernetes.io/aws-load-balancer-ssl-cert": arn:aws:acm:us-west-2:xxxxxxxxxxxx:certificate/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 labels:
 app: spin
 cluster: spin-deck
 name: spin-deck
spec:
 ports:
 - name: deck-tcp
 nodePort: xxxxx
 port: 9000
 protocol: TCP
 targetPort: 9000
 selector:
 app: spin
 cluster: spin-deck
 sessionAffinity: None
 type: LoadBalancer

spin-gate

apiVersion: v1
kind: Service
metadata:
 annotations:
 service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
 service.beta.kubernetes.io/aws-load-balancer-ssl-ports: 80,443
 service.beta.kubernetes.io/aws-load-balancer-ssl-cert": arn:aws:acm:us-west-2:xxxxxxxxxxxx:certificate/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 service.beta.kubernetes.io/aws-load-balancer-internal: true
 labels:
 app: spin
 cluster: spin-gate
 name: spin-gate
spec:
 ports:
 - name: gate-tcp
 nodePort: xxxxx
 port: 8084
 protocol: TCP
 targetPort: 8084
 selector:
 app: spin
 cluster: spin-gate
 sessionAffinity: None
 type: Loadbalancer

X509

spec:
 config:
 profiles:
 gate:
 default:
 apiPort: 8085
 expose:
 type: service
 service:
 type: LoadBalancer

 annotations:
 service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http

 overrides:
 # Provided below is the example config for the Gate-X509 configuration
 deck:
 annotations:
 service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:us-west-2:9999999:certificate/abc-123-abc
 service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
 gate:
 annotations:
 service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:us-west-2:9999999:certificate/abc-123-abc
 service.beta.kubernetes.io/aws-load-balancer-backend-protocol: https # X509 requires https from LoadBalancer -> Gate
 gate-x509:
 annotations:
 service.beta.kubernetes.io/aws-load-balancer-backend-protocol: tcp
 service.beta.kubernetes.io/aws-load-balancer-ssl-cert: null
 publicPort: 443

Help resources

Armory Operator and Armory Continuous Deployment: contact Armory Support or use the Spinnaker Slack #armory channel.
Spinnaker Operator and Spinnaker: Spinnaker Slack #kubernetes-operator channel.

What’s next

See the Manifest Reference for configuration options by section.
Configure Kubernetes accounts using the Spinnaker Accounts CRD (Experimental)
See advanced configuration using Kustomize in the Configure Armory Continuous Deployment Using Kustomize guide.

Continuous-Deployment: Configure Hashicorp's Vault for Kubernetes Auth

Mon, 01 Jan 0001 00:00:00 +0000

Configuration of Vault for the Kubernetes auth method requires configuring both Vault and Kubernetes.

Configure Kubernetes

Create a Kubernetes Service Account.

vault-auth-service-account.yml

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
 name: role-tokenreview-binding
 namespace: default
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: system:auth-delegator
subjects:
- kind: ServiceAccount
 name: vault-auth
 namespace: default

# Create a service account, 'vault-auth'
$ kubectl -n default create serviceaccount vault-auth

# Update the 'vault-auth' service account
$ kubectl -n default apply --filename vault-auth-service-account.yml

Configure Vault

This guide assumes that Key/Value version 1 secret engine is enabled at secret/.

Create a read-only policy spinnaker-kv-ro in Vault.

spinnaker-kv-ro.hcl

# For K/V v1 secrets engine
path "secret/spinnaker/*" {
 capabilities = ["read", "list"]
}
# For K/V v2 secrets engine
path "secret/data/spinnaker/*" {
 capabilities = ["read", "list"]
}

$ vault policy write spinnaker-kv-ro spinnaker-kv-ro.hcl

Set environment variables required for Vault configuration.

# Set VAULT_SA_NAME to the service account you created earlier
$ export VAULT_SA_NAME=$(kubectl -n default get sa vault-auth -o jsonpath="{.secrets[*]['name']}")

# Set SA_JWT_TOKEN value to the service account JWT used to access the TokenReview API
$ export SA_JWT_TOKEN=$(kubectl -n default get secret $VAULT_SA_NAME -o jsonpath="{.data.token}" | base64 --decode; echo)

# Set SA_CA_CRT to the PEM encoded CA cert used to talk to Kubernetes API
$ export SA_CA_CRT=$(kubectl -n default get secret $VAULT_SA_NAME -o jsonpath="{.data['ca\.crt']}" | base64 --decode; echo)

# Look in your cloud provider console for this value
$ export K8S_HOST=<https://your_API_server_endpoint>

NOTE on TTL and Token Renewal

The Kubernetes Vault Auth Secrets Engine does not currently support token renewal. As such the spinnaker role created below provides a TTL of two months.

Note By default, Vault has a max_ttl parameter set to 768h0m0s - that’s 32 days. If you want to set the TTL to a higher value, you need to modify this parameter.

Important: Spinnaker must be redeployed sometime during the defined TTL window – Armory recommends this be done by updating to a new version of Spinnaker and running kubectl -n <spinnaker namespace> apply -f <SpinnakerService manifest>.

Next, configure Vault’s Kubernetes auth method.

# Enable the Kubernetes auth method at the default path ("kubernetes")
$ vault auth enable kubernetes

# Tell Vault how to communicate with the Kubernetes cluster
$ vault write auth/kubernetes/config \
 token_reviewer_jwt="$SA_JWT_TOKEN" \
 kubernetes_host="$K8S_HOST" \
 kubernetes_ca_cert="$SA_CA_CRT"

# Create a role named, 'spinnaker' to map Kubernetes Service Account to
# Vault policies and default token TTL
$ vault write auth/kubernetes/role/spinnaker \
 bound_service_account_names=default \
 bound_service_account_namespaces='*' \
 policies=spinnaker-kv-ro \
 ttl=1440h

Verify Configuration

It is time verify that the Kubernetes auth method has been properly configured.

Deploy Armory’s debug container into your cluster – this container has the Vault cli pre-installed.

This should be deployed into the same namespace as your Spinnaker installation.

kubectl apply -f https://raw.githubusercontent.com/armory/troubleshooting-toolbox/master/docker-debugging-tools/deployment.yml

exec into the pod.

POD_NAME=$(kubectl get pod -l app=debugging-tools -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}' --sort-by=".status.startTime" | tail -n 1)

kubectl exec -it $POD_NAME bash

Test the auth method.

export VAULT_ADDR='http://your.vault.address:port'
SA_TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)

vault write auth/kubernetes/login role=spinnaker jwt=$SA_TOKEN

This command should return output like the following

Key Value
--- -----
token s.bKSSrYOcETCADGvGxhbDaaaD
token_accessor 0ybx2CEPZqxBEwFk8jUPkBk7
token_duration 24h
token_renewable true
token_policies ["default" "spinnaker-kv-ro"]
identity_policies []
policies ["default" "spinnaker-kv-ro"]
token_meta_role spinnaker
token_meta_service_account_name default
token_meta_service_account_namespace default
token_meta_service_account_secret_name default-token-h9knn
token_meta_service_account_uid 13cee6Dbc-0bc2-11e9-9fd2-0a32f8e530cc

Using the token from the output above allows for the following:

vault login s.bKSSrYOcETCADGvGxhbDaaaD

Once logged in you should be able to read secrets:

vault kv get secret/spinnaker/test

As a reminder, the policy we created provides RO access only so you will need to have written the secret using a separate authenticated client.

Continuous-Deployment: Store Spinnaker Secrets in HashiCorp Vault

Mon, 01 Jan 0001 00:00:00 +0000

In this example, you use the default KV secret engine called secret and store GitHub credentials, a kubeconfig file, and a Java keystore for SAML SSO.

Authentication with Vault servers

We currently support two methods of authentication with Vault servers.

1. Kubernetes service account (recommended)

You’ll need to configure Vault to authenticate with Kubernetes per our Vault Configuration Guide or HashiCorp’s documentation.

Note: If multiple clusters need to access the same Vault server, you’ll need to use the -path flag and give each cluster a different path name. This becomes <cluster auth path> in the example below. If using just one cluster, you can use the default vault auth enable kubernetes command, in which case your path will be kubernetes.

After configuring authentication on the Vault side, use the following configuration to enable Vault secrets in Spinnaker:

Add the following snippet to the SpinnakerService manifest:

apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 spinnakerConfig:
 config:
 armory:
 secrets:
 vault:
 enabled: true
 authMethod: KUBERNETES # Method used to authenticate with the Vault endpoint. Must be either KUBERNETES for Kubernetes service account auth or TOKEN for Vault token auth. The TOKEN method will require a VAULT_TOKEN environment variable set for Operator and the services. 
 url: <Vault server URL>:<port, if required> # URL of the Vault endpoint from Spinnaker services.
 role: <Vault role> # (Applies to KUBERNETES authentication method) Name of the role against which the login is being attempted.
 # path: <k8s cluster path> (Optional; default: kubernetes) Applies to KUBERNETES authentication method) Path of the kubernetes authentication backend mount. Default is "kubernetes"

2. Token authentication

This method is not recommended, but it is supported if you choose to use it. Armory recommends this for testing and development purposes only. For token authentication, you need to have a VAULT_TOKEN environment variable set in the Halyard container of the Operator pod as well as each of the services.

Use the following configuration to enable Vault secrets using token auth:

Add the following snippet to the SpinnakerService manifest:

apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 spinnakerConfig:
 config:
 armory:
 secrets:
 vault:
 enabled: true
 authMethod: TOKEN # Method used to authenticate with the Vault endpoint. Must be either KUBERNETES for Kubernetes service account auth or TOKEN for Vault token auth. The TOKEN method will require a VAULT_TOKEN environment variable set for Operator and the services. 
 url: <Vault server URL>:<port if required> # URL of the Vault endpoint from Spinnaker services.

Configuring the Operator to use Vault secrets

If you are using the Armory Operator, set up a custom Halyard configuration with this content:

secrets:
 vault:
 enabled: true
 url: <Vault server URL>
 authMethod: KUBERNETES
 role: <Vault role>
 path: <k8s cluster path>

Once you’ve mounted your ConfigMap to the spinnaker-operator deployment, it restarts the Halyard container with your Vault config.

Storing secrets

To store a file, simply prepend the file path with @. It accepts relative paths but cannot resolve ~:

vault kv put secret/spinnaker/kubernetes config=@path/to/kube/config

The command above stores a single key-value pair at the secret/spinnaker/kubernetes path. Any updates to that path will replace the existing values even if using a different key! In order to store multiple secrets at the same path, it must be done in a single command, like so:

vault kv put secret/spinnaker/github password=<password> token=<token>

Otherwise, just store different secrets at different paths, like we’re doing in these examples.

Make sure to base64 encode any binary files:

base64 -i saml.jks -o saml.b64
vault kv put secret/spinnaker/saml base64keystore=@saml.b64

Referencing secrets

Now that secrets are safely stored in Vault, reference them in config files with the following syntax:

encrypted:vault!e:<secret engine>!p:<path to secret>!k:<key>!b:<is base64 encoded?>

Parameters

Parameters can be provided in any order.

!: required is used as a delimiter between parameters
e: required Vault’s Secret Engine.
p: required Path to your secret, ex: spinnaker/github
k: required Key of the secret.
b: optional If the value is a base64 encoded value or file, set this to true

Example of how it’s used in your YAML configs

github:
 password: encrypted:vault!e:secret!p:spinnaker/github!k:password

kubernetes:
 kubeconfigFile: encrypted:vault!e:secret!p:spinnaker/kubernetes!k:config

gate:
 javaKeyStoreBinary: encrypted:vault!e:secret!p:spinnaker/saml!k:base64keystore!b:true

Continuous-Deployment: Upgrade Spinnaker to Armory Continuous Deployment

Mon, 01 Jan 0001 00:00:00 +0000

Armory Continuous Deployment (Armory CD) requires a license. For more information, contact Armory.

Overview of upgrading Spinnaker to Armory Continuous Deployment

Armory Continuous Deployment for Spinnaker is installed with Armory-extended Halyard, very similarly to the way Open Source Spinnaker^TM is installed with Open Source Halyard. These are the key differences:

Armory-extended Halyard installs Armory’s enterprise distribution of Spinnaker; Open Source Halyard installs Open Source Spinnaker.
Armory versions are one major version ahead of Open Source. For example, Armory 2.18.x maps to Open Source Spinnaker 1.18.x.
Armory has an extra subcommand block hal armory (mapping to an armory block in your .hal/config), which controls Armory-specific features.

This guide differentiates between the two by referring to them as Armory and open source Spinnaker, respectively.

If you are currently on open source Spinnaker and interested in upgrading to Armory, you can easily upgrade if you used Halyard to install your Spinnaker cluster.

This guide assumes the following:

Spinnaker is currently running in Kubernetes
Spinnaker is configured with some form of persistent storage (Minio, S3, GCS, or AZS)
Spinnaker was installed with Halyard in one of these forms:
- Halyard is running locally on a workstation
- Halyard is running in a Docker container in Docker daemon (in Linux, Windows, or OSX)
- Halyard is running in a Kubernetes pod

Depending on where Halyard is currently running, the detailed installation instructions will be slightly different, but the high level process is the same:

Start Armory-extended Halyard in a Docker container with your open source Halyard configuration directories available to Armory Halyard.
Enter the Armory-extended Halyard container.
Update the Spinnaker version to use an Armory version. Recall that Armory versions are ahead of open source Spinnaker by one major version.
Apply your changes.

Halyard running locally on a workstation

If Halyard is running locally on your workstation, then perform the following steps:

Make copies of any directores used by Halyard. These include~.hal and ~.kube and potentially ~/.aws, ~/.config/gcloud, ~/.azure). You can mount these directly into Halyard, but it may be safer to operate on copies.
```
mkdir -p ~/armory/.config
cp -rpv ~/.hal ~/armory/
cp -rpv ~/.aws ~/armory/
cp -rpv ~/.kube ~/armory/
cp -rpv ~/.azure ~/armory/
cp -rpv ~/.config/gcloud ~/armory/.config
```
Omit any directories that do not apply to you. For example, if you do not use Azure, omit it.
Start Halyard as a Docker container in daemon mode, with your directories mounted in (add/remove volume mounts as applicable):
```
docker run --name armory-halyard --rm \
 -v ${HOME}/armory/.hal:/home/spinnaker/.hal \
 -v ${HOME}/armory/.kube:/home/spinnaker/.kube \
 -v ${HOME}/armory/.aws:/home/spinnaker/.aws \
 -v ${HOME}/armory/.azure:/home/spinnaker/.azure \
 -v ${HOME}/armory/.config:/home/spinnaker/.config \
 -d \
 -u $(id -u) \
 index.docker.io/armory/halyard-armory:1.12.1
```
Omit any directories that do not apply to you. For example, if you do not use Azure, omit it.

The above specifies that Halyard will run as your local user id. Depending on how your Halyard daemon was initially run and what user id owns the various Halyard directories, you may need to specify some other user. For example, if user 1000 owns the .hal directory, replace “-u $(id -u)” with “-u 1000”
Exec into the Halyard container
```
docker exec -it armory-halyard bash
```
Update the version of Spinnaker
```
hal config version edit --version $(hal version latest -q)
```
This will use the latest stable version; If you want to use a different version, use hal version list to get a list of available versions. Then, run hal config version edit --version X.X.X to specify a version.
Apply your changes
```
hal deploy apply
```

Halyard running in a Docker container in Docker daemon

If Halyard is already running in a Docker container in your Docker daemon, you can do an in-place upgrade.

First, do a backup of your existing Halyard configuration. Exec into the Docker container, then run hal backup create.
Stop the Halyard docker container, and re-start it with the Armory-extended Halyard image (index.docker.io/armory/halyard-armory:1.12.1) instead of the open source Halyard image (gcr.io/spinnaker-marketplace/halyard:stable). Also, change the user id for Armory-extended Halyard to be 1000. For example, if you run the previous Docker image (open source Halyard) like this:
```
docker run --name halyard --rm \
 -v ${HOME}/armory/.hal:/home/spinnaker/.hal \
 -v ${HOME}/armory/.kube:/home/spinnaker/.kube \
 -d \
 gcr.io/spinnaker-marketplace/halyard:stable
```
Then run Armory-extended Halyard like this:
```
docker run --name armory-halyard --rm \
 -v ${HOME}/armory/.hal:/home/spinnaker/.hal \
 -v ${HOME}/armory/.kube:/home/spinnaker/.kube \
 -d \
 index.docker.io/armory/halyard-armory:1.12.1
```
Note the different Docker image and different container name.
Exec into the Halyard container:
```
docker exec -it armory-halyard bash
```
Update the version of Spinnaker:
```
hal config version edit --version $(hal version latest -q)
```
This will use the latest stable version. If you want to use a different version, use hal version list to get a list of available versions, and then hal config version edit --version X.X.X to specify a specific version.
Apply your changes
```
hal deploy apply
```

Halyard running in a Kubernetes pod

If Halyard is running in your Kubernetes cluster, either as a Kubernetes Deployment or a Kubernetes StatefulSet, then you can do an in-place upgrade:

First, update the image for your Halyard Deployment / StatefulSet from the open source Halyard image (gcr.io/spinnaker-marketplace/halyard:stable) to the Armory-extended Halyard image (index.docker.io/armory/halyard-armory:1.12.1)
Wait for the pod to start up.
Exec into your Kubernetes pod (insert your namespace and pod name, accordingly):
```
kubectl exec -it spinnaker bash
```
Update the version of Spinnaker:
```
hal config version edit --version $(hal version latest -q)
```
This will use the latest stable version. If you want to use a different version, use hal version list to get a list of available versions, and then hal config version edit --version X.X.X to specify a specific version.
Apply your changes:
```
hal deploy apply
```

Revert back to Spinnaker

If you want to go back to open source Spinnaker, you can repeat the same process as above with open source Halyard. Specifically, replace the Armory-extended Halyard image with the open source Halyard image, update Spinnaker version (from 2.x to 1.x), and run hal deploy apply

Troubleshooting

Depending on what version of Halyard / Armory-extended Halyard you’re moving to/from, there may be some fields in your Halyard configuration that are present in one version but not the other. You’ll see an Unrecognized field error like this:

$ hal deploy apply
- Get current deployment
 Failure
Problems in Global:
! ERROR Could not translate your halconfig: Unrecognized field
 "nodeSelectors" (class
 com.netflix.spinnaker.halyard.config.model.v1.node.DeploymentEnvironment), not
 marked as ignorable (14 known properties: "size", "initContainers",
 "updateVersions", "consul", "customSizing", "vault", "gitConfig", "location",
 "sidecars", "haServices", "accountName", "type", "hostAliases",
 "bootstrapOnly"])
at [Source: N/A; line: -1, column: -1] (through reference chain:
 io.armory.halyard.config.model.v1.node.ArmoryHalconfig["deploymentConfigurations"]->java.util.ArrayList[0]->com.netflix.spinnaker.halyard.config.model.v1.node.ArmoryDeploymentConfiguration["deploymentEnvironment"]->com.netflix.spinnaker.halyard.config.model.v1.node.DeploymentEnvironment["nodeSelectors"])

- Failed to get deployment name.

If you see the above error, go to the /home/spinnaker/.hal/config file in your Halyard container, search for the offending field, and remove the yaml block (comment it out or completely remove it).

For example, in the above case, find the deploymentEnvironment.nodeSelectors field, and remove it. Repeat as necessary.

Continuous-Deployment: Manage Armory Continuous Deployment using the Operator

Mon, 01 Jan 0001 00:00:00 +0000

This guide is for both the Armory Operator and the Spinnaker Operator. Armory Continuous Deployment and Spinnaker configuration is the same except for features only in Armory Continuous Deployment. Those features are marked .

Kubernetes tools

You use kubectl to manage the Armory Continuous Deployment or Spinnaker lifecycle like you do with other applications deployed to Kubernetes. For example:

List instances

kubectl get spinnakerservice --all-namespaces

Describe instances

You can use spinsvc instead of spinnakerservice:

kubectl -n <namespace> describe spinsvc spinnaker

Consult the kubectl docs for a list of commands.

Deploy Armory Continuous Deployment

kubectl -n <namespace> apply -f <path-to-manifest-file>

kubctl -n <namespace> apply -k <path-to-kustomize-directory>

You can watch the installation progress by executing:

kubectl -n <namespace> get spinsvc spinnaker -w

You can verify pod status by executing:

 kubectl -n <namespace> get pods

Upgrade Armory Continuous Deployment

Change the version field in your manifest file to the target version for the upgrade:

kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 spinnakerConfig:
 config:
 version: <version>

Apply the updated manifest:

kubectl -n <namespace> apply -f <path-to-manifest-file>

Change the version field in your Kustomize patch to the target version for the upgrade.

Apply the update:

kubctl -n <namespace> apply -k <path-to-kustomize-directory>

You can view the upgraded services starting up by executing describe:

kubectl -n <namespace> describe spinsvc spinnaker

Verify the upgraded version of Spinnaker:

kubectl -n <namespace> get spinsvc

The command returns information similar to the following:

NAME VERSION
spinnaker 2.20.2

VERSION should reflect the target version for your upgrade.

Rollback Armory Continuous Deployment

Change the version field in your manifest file to the target version for the rollback:

kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 spinnakerConfig:
 config:
 version: <version>

Apply the updated manifest:

kubectl -n <namespace> apply -f <path-to-manifest-file>

Change the version field in your Kustomize patch to the target version for the rollback.

Apply the update:

kubctl -n <namespace> apply -k <path-to-kustomize-directory>

You can view the rolled back services starting up by executing describe:

kubectl -n <namespace> describe spinsvc spinnaker

Verify the rolled back version of Spinnaker:

kubectl -n <namespace> get spinsvc

The command returns information similar to the following:

NAME VERSION
spinnaker 2.27.2

VERSION should reflect the target version for your rollback.

Delete Armory Continuous Deployment

kubectl -n <namespace> delete spinnakerservice spinnaker

Help resources

Armory Operator and Armory Continuous Deployment: contact Armory Support or use the Spinnaker Slack #armory channel.
Spinnaker Operator and Spinnaker: Spinnaker Slack #kubernetes-operator channel.

What’s next

See the Errors and Troubleshooting guide if you encounter issues.

Continuous-Deployment: Migrate from Halyard to the Operator

Mon, 01 Jan 0001 00:00:00 +0000

This guide is for both the Armory Operator and the Spinnaker Operator. Armory Continuous Deployment and Spinnaker configuration is the same except for features only in Armory Continuous Deployment. Those features are marked .

Before you begin

You need to decide if you want to overwrite the current Halyard deployment of Armory Continuous Deployment or create a test instance.

If you choose to overwrite your current instance, you need to take downtime to clean up the namespace that the Halyard-deployed Armory Continuous Deployment is in so Operator can deploy Armory Continuous Deployment without collision.

Alternately, you can use Operator to deploy Armory Continuous Deployment to a different namespace to test out the migration. You need to create a separate data store as well as separate Gate and Deck URLs for your test instance of Armory Continuous Deployment. Once you’ve verified that Operator has deployed your test configuration as you expected, decommission the Halyard-deployed instance of Armory Continuous Deployment. Change the data store config and URLs in the manifest that Operator used to deploy your test instance to match what your decommissioned instance used. Then redeploy.

The second method is preferred as it allows you to test everything before decommissioning Armory Continuous Deployment that you deployed using Halyard.

Migrate to Operator

This guide assumes you want to deploy Armory Continuous Deployment using a single SpinnakerSerivce.yml manifest file rather than Kustomize patches.

The migration process from Halyard to Operator can be completed in 7 steps:

Install the Operator.
Export configuration.

Copy the desired profile’s content from the config file

For example, if you want to migrate the default hal profile, use the following SpinnakerService manifest structure:
```
currentDeployment: default
deploymentConfigurations:
- name: default
 <CONTENT>
```
Add <CONTENT> in the spec.spinnakerConfig.config section in the SpinnakerService manifest as follows:
```
spec:
 spinnakerConfig:
 config:
 <<CONTENT>>
```
Note: config is under ~/.hal

You can see more details in spec.spinnakerConfig.config.
Export Armory Continuous Deployment profiles.

If you have configured Armory Continuous Deployment profiles, you need to migrate these profiles to the SpinnakerService manifest.

First, identify the current profiles under ~/.hal/default/profiles.

For each file, create an entry under spec.spinnakerConfig.profiles.

For example, you have the following profile:
```
$ ls -a ~/.hal/default/profiles | sort
echo-local.yml
```
Create a new entry with the name of the file without -local.yaml as follows:
```
spec:
 spinnakerConfig:
 profiles:
 echo:
 <CONTENT>
```
You can see more details in spec.spinnakerConfig.profiles.
Export Armory Continuous Deployment settings.

If you configured Armory settings, you need to migrate these settings to the SpinnakerService manifest also.

First, identify the current settings under ~/.hal/default/service-settings.

For each file, create an entry under spec.spinnakerConfig.service-settings.

For example, you have the following settings:
```
$ ls -a ~/.hal/default/service-settings | sort
echo.yml
```
Create a new entry with the name of the file without .yaml as follows:
```
spec:
 spinnakerConfig:
 service-settings:
 echo:
 <CONTENT>
```
You can see more details in spec.spinnakerConfig.service-settings.

Export local file references.

If you have references to local files in any part of the config, like kubeconfigFile, service account JSON files or others, you need to migrate these files to the SpinnakerService manifest.

For each file, create an entry under spec.spinnakerConfig.files.

For example, you have a Kubernetes account configured like this:

kubernetes:
 enabled: true
 accounts:
 - name: prod
 requiredGroupMembership: []
 providerVersion: V2
 permissions: {}
 dockerRegistries: []
 configureImagePullSecrets: true
 cacheThreads: 1
 namespaces: []
 omitNamespaces: []
 kinds: []
 omitKinds: []
 customResources: []
 cachingPolicies: []
 oAuthScopes: []
 onlySpinnakerManaged: false
 kubeconfigFile: /home/spinnaker/.hal/secrets/kubeconfig-prod
 primaryAccount: prod

The kubeconfigFile field is a reference to a physical file on the machine running Halyard. You need to create a new entry in files section like this:

spec:
 spinnakerConfig:
 files:
 kubeconfig-prod: |
  <CONTENT>

Then replace the path in the config to match the key in the files section:

kubernetes:
 enabled: true
 accounts:
 - name: prod
 requiredGroupMembership: []
 providerVersion: V2
 permissions: {}
 dockerRegistries: []
 configureImagePullSecrets: true
 cacheThreads: 1
 namespaces: []
 omitNamespaces: []
 kinds: []
 omitKinds: []
 customResources: []
 cachingPolicies: []
 oAuthScopes: []
 onlySpinnakerManaged: false
 kubeconfigFile: kubeconfig-prod # File name must match "files" key
 primaryAccount: prod

You can see more details in spec.spinnakerConfig.files.

Export Packer template files (if used).

If you are using custom Packer templates for baking images, you need to migrate these files to the SpinnakerService manifest.

First, identify the current templates under ~/.hal/default/profiles/rosco/packer.

For each file, create an entry under spec.spinnakerConfig.files.

For example, you have the following example-packer-config file:
```
$ tree -v ~/.hal/default/profiles
├── echo-local.yml
└── rosco
 └── packer
 └── example-packer-config.json

2 directories, 2 files
```
You need to create a new entry with the name of the file following these instructions:
- For each file, list the folder name starting with profiles, followed by double underscores (__) and at the very end the name of the file.
```
spec:
 spinnakerConfig:
 files:
 profiles__rosco__packer__example-packer-config.json: |
  <CONTENT>
```
You can see more details in spec.spinnakerConfig.files.
Validate your Armory configuration if you plan to run the Operator in cluster mode:
```
kubectl -n <namespace> apply -f <spinnaker service manifest> --dry-run=server
```
The validation service throws an error when something is wrong with your manifest.

Apply your SpinnakerService:

kubectl -n <namespace> apply -f <spinnaker service>

Help resources

Armory Operator and Armory Continuous Deployment: contact Armory Support or use the Spinnaker Slack #armory channel.
Spinnaker Operator and Spinnaker: Spinnaker Slack #kubernetes-operator channel.

Continuous-Deployment: Permissions in Spinnaker

Mon, 01 Jan 0001 00:00:00 +0000

Overview of Fiat

Fiat is the microservice in Spinnaker responsible for authorization (authz) for the other Spinnaker services. By default, it is not enabled, so users are able to perform any action in Spinnaker. This page describes how Fiat interacts with the following Spinnaker services:

Clouddriver for account permission
Front50 for application permissions
Igor for build services permissions

When Fiat is enabled, users start with no permissions and must be explicitly granted permissions.

For a deeper dive into how authz works for Spinnaker, see Authorization. Much of Spinnaker’s configuration is done through your Halconfig, which can be found in ~/.hal/config.

Requirements

To use Fiat, you need an external identity provider. Create the user roles and maintain them in the identity provider. Fiat controls what permissions are mapped to roles.

Fiat supports the following identity providers:

SAML groups (includes OAuth ONLY with OIDC)
LDAP
GitHub teams
Google Groups

In all these methods, users are referenced by a userId, which is determined by the authentication method of your choice.

Clouddriver accounts

Clouddriver is the Spinnaker service that interacts with the various providers. When Fiat is enabled, account permissions for Clouddriver determine whether a role or group can perform the following actions:

READ - See objects in a given cloud account.
WRITE - Deploy objects to a given account.

Note that for AWS, a role/group needs both read and write access to deploy an AMI from the AWS account that Rosco uses to build AMIs.

Front50 accounts

Front50 is the Spinnaker service that acts as the system of record for all the other Spinnaker services. In other words, all metadata for things such as applications and pipelines are stored in and served by Front50. Control access to Front50 by creating service accounts. This can be done through a series of cURL commands.

Service accounts are used to delegate authority to a pipeline to perform actions in Spinnaker. Users with ALL the roles defined in a service account can grant a pipeline “Run as” permission. The service accounts you create should map to roles/groups in your identity provider. Additionally, all pipelines configured to run off of a trigger must also be configured with “Run as” permission, or they will fail.

Armory recommends that you map one service account for each role/group in the identity provider that will be accessing Spinnaker. This prevents privilege escalation and makes it easier to figure out which roles/group ran which pipeline.

Example roles

The rest of this explanation uses the following example roles to illustrate how Fiat works:

fiat-admin
- Administrator for all of Spinnaker. Can do anything implicitly.
admin
- Administrator. Can do anything for all apps. Can read and execute build/ci jobs.
dev
- Full control of pipeline definition for app1 & app2
- Can deploy to dev-infra
- Can see qa-infra
- Can attach a build/ci trigger to a pipeline definition
qa
- Full control of pipeline definition for app1 & app3
- Can deploy to qa-infra
- Can see dev-infra
- Can attach a build/ci trigger to pipeline definitions
ops
- Can deploy to all accounts but cannot change the pipeline definitions. Can read and execute build/ci jobs.

Note that roles, as far as Fiat is concerned, are case insensitive. This means that admin is equivalent to Admin, ADMIN, or any other permutation.

Mapping exercise

Answer the following questions to figure out how to map roles and permissions in your deployment:

Which roles/groups have READ and/or WRITE access to which Clouddriver accounts
Which roles/groups have READ, WRITE, EXECUTE access to each Spinnaker Application
Which roles/groups have READ and/or WRITE/EXECUTE access to which CI/Build accounts

The following image shows an example result of this exercise based on the user roles described in Example Roles:

Example Configurations

The following sections describe some of the roles from the role matrix example in the Mapping exercise.

Superuser

fiat-admin is the superuser and has permissions across your whole Spinnaker deployment.

The configuration for fiat-admin in the fiat-local.yml file looks like the following snippet:

admin:
 roles:
 - fiat-admin

Infrastructure

dev-infra is one of the potential deployment targets (pictured in (Mapping exercise).

The Halconfig snippet for configuring access to dev-infra based on our mapping exercise looks similar to the following:

accounts:
- name: dev-infra
 permissions:
 READ:
 - admin
 - dev
 - qa
 - ops
 WRITE:
 - admin
 - dev
 - ops

Based on which roles have what access to other infrastructure accounts, the configuration looks different.

Note that fiat-admin does not need to be explicitly granted permissions. Every other user role must be granted permissions explicitly.

For information about how to configure permissions for Clouddriver accounts, see Accounts.

Continuous integration system

build1 is a Jenkins deployment used for CI in this example. The Halconfig for controlling access to build1 looks similar to the following snippet:

ci:
 jenkins:
 enabled: true
 masters:
 - name: build1
 permissions:
 READ:
 - admin
 - dev
 - qa
 - ops
 WRITE:
 - admin
 - ops

Applications

app1 is one of the applications that needs to be deployed. Configuring permissions for an application is done in Deck, Spinnaker’s UI, when you create or edit an application:

app2, app3, and app4 will look slightly different since they have different permissions based on the mapping exercise.

For information about how to configure permissions for applications, see Applications.

Applying changes

Whenever you make a change to permissions that involves modifying your Halconfig, run hal deploy apply to apply your changes to the Spinnaker deployment. Some permission changes do not require this, such as adding a service account.

Verifying permissions

You can verify what permissions are assigned to a role at any time.

Admin permissions

Check fiat-local.yml to see who is assigned an admin role.

Permissions in Halconfig

In your Halconfig, you can verify several sets of permissions.

For example, search for ci to find the continuous integration section. Look for the permissions key and examine the READ and WRITE subkeys. All the user roles that have read or write permission for the CI system are listed here. The same thing can be done for Clouddriver accounts.

Permissions for apps

Check the permissions for all applications in Spinnaker with a REST API call to Gate.

Headers

Header	Information
Request URL	`$GATE_URL/applications`
Request Method	`GET`
content-type	`application/json;charset=UTF-8`

The API call returns information about the apps. Refer to the name and permissions sections to find your applications and the corresponding permissions:

{
 ...
 "name": "app2",
 "permissions": {
 "EXECUTE": [
 "admin",
 "dev",
 "ops"
 ],
 "READ": [
 "admin",
 "dev",
 "ops"
 ],
 "WRITE": [
 "admin",
 "dev"
 ]
 },
 ...
}

Permissions for Spinnaker service accounts

Verifying the permissions for service accounts requires access to the Front50 and Fiat pods.

List all the service accounts with the following command (from the Front50 pod):

export FRONT50=http://spin-front50:8080
curl -s $FRONT50/serviceAccounts

Check user or service account permissions for all of Spinnaker (from the Fiat pod):

export FIAT=http://spin-fiat:7003
curl -s $FIAT/authorize/$user-or-service-account

The command returns JSON that lists the following information:

Roles the user/service account is part of
Spinnaker applications the user/service account has access to
Clouddriver accounts the user/service account has access to
Build services the user/service account has access to

Pub Sub and Webhooks

Fiat does not support Pub Sub triggers or authenticating webhooks with group permissions.

Permissions for Clouddriver accounts

Check Clouddriver’s current runtime context with a REST API call to Gate.

Headers

Header	Information
Request URL	`$GATE_URL/credentials`
Request Method	`GET`
content-type	`application/json;charset=UTF-8`

The API call returns JSON that lists the Clouddriver accounts.

[
 {
 "name": <account-name>,
 "type": <account-type>,
 "providerVersion": <version>,
 "requiredGroupMembership": [

 ],
 "skin": <version>,
 "permissions": {

 },
 "authorized": <true-or-false>
 },
 {
 "name": "my-docker-registry",
 "type": "dockerRegistry",
 "providerVersion": "v1",
 "requiredGroupMembership": [

 ],
 "skin": "v1",
 "permissions": {

 },
 "authorized": "true"
 }
]

Continuous-Deployment: Load Balancers in Spinnaker

Mon, 01 Jan 0001 00:00:00 +0000

What is a load balancer?

A load balancer is associated with an ingress protocol and port range. It balances traffic among instances in its server groups. Optionally, you can enable health checks for a load balancer, with flexibility to define health criteria and specify the health check endpoint.

Requirements

Before you create a load balancer, your Security Group will already need to exist.

Create a load balancer

Step 1: After you select your Application, click on the Load Balancers tab.

Step 2: Click the “Create Load Balancer” button.

Step 3: The Stack and Detail should be kept in mind when creating the pipeline because the pipeline’s deployment of server group should be using the same Stack and Detail.

Delete a load balancer

Note: You can only delete Load Balancers if they do not have any instances attached to them.

Step 1: Go to your Load Balancers in your Applications.

Step 2: Select a Load Balancer, then to the right a column with the Load Balancer’s details should appear. Select the drop down menu and press “Delete”.

Continuous-Deployment: Your First Application in Spinnaker

Mon, 01 Jan 0001 00:00:00 +0000

What is an application in Spinnaker?

Spinnaker™ is organized around the concept of applications. An application in Spinnaker is a collection of clusters, which in turn are collections of server groups. The application also includes firewalls and load balancers.

An application represents the service which you are going to deploy using Spinnaker, all configuration for that service, and all the infrastructure on which it will run.

The Spinnaker landing page

When you first log in to Spinnaker, the landing page should look like this:

The navigation bar at the top allows you to access Projects, Applications, and Infrastructure. The search bar allows you to search through your Infrastructure. (this search bar will find everything in all of your AWS Infrastructure)

Spinnaker should scan all of your infrastructure and create applications for anything that it finds. If you enter an application this way that was not configured by Spinnaker, it should state that the application has not been configured.

Note: The naming convention that you have been using is not necessarily the same one that Spinnaker uses, but accessing your applications through Spinnaker should allow you to configure it to your preferences. Remember that Spinnaker considers an application to be anything you would put into a single code repository.

Making an application

Enter Applications from your Navigation bar.
Click the “Create Application” button:
Fill out the pop-up form with desired user definitions.
- The name of the application cannot have hyphens. Using a hyphen in the application name interferes with the naming convention. This applies to all types of applications except for those that use the Kubernetes V2 provider to deploy.
- When you create an application in Spinnaker, consider it to be anything you would put into a single code repository.
After you fill out the form you should see this:
If you wish to modify the settings for the application, click “Config” for configurations.

Note that by now you should have created an application, but as you have not created a pipeline and executed it, nothing should show up yet.

Deleting an application

Go to your application, click on “Config” and scroll all the way down. There will be a prompt to confirm if you would like to delete your application.

Continuous-Deployment: Your First Pipeline in Spinnaker

Mon, 01 Jan 0001 00:00:00 +0000

What is a pipeline in Spinnaker?

The pipeline is the key deployment management construct in Spinnaker™. It consists of a sequence of actions, known as stages. You can pass parameters from stage to stage along the pipeline.

You can start a pipeline manually, or you can configure it to be automatically triggered by an event, such as a Jenkins job completing, a new Docker image appearing in your registry, a CRON schedule, or a stage in another pipeline.

Before you begin

This page assumes your application stack includes:

A Jenkins Master configured by your administrator
A Jenkins job that archives a Debian package
A security group within AWS with appropriate permissions
A Load Balancer

How to create a pipeline

This example creates a pipeline that takes the Debian package produced by a Jenkins job and uses it to create an Amazon Machine Image (AMI) before deploying that image to a server group.

After selecting your Application, click the Pipelines category.
On this page, click Configure a new pipeline.
Provide a name for your new pipeline and click Create.
On the Pipeline page you should see:
- A visual representation of your pipeline and its stages (you should only have configurations at the beginning)
- Execution Options
- Automated Triggers
- Parameters
- Notifications
- Description

Add a trigger

Define how your pipeline is triggered. Scroll down to the Automated Triggers section and click Add Trigger. This section enables you to select a Type:
For this example, select Jenkins. By adding a trigger, you are defining how your pipeline is initialized.

Note: Property File is an important topic that will be covered in a separate guide.
Before you test your pipeline, you may want to consider enabling or disabling the trigger via the checkbox at the bottom.

Add a Bake stage

Now add your first stage: Baking an AMI. Click the Add stage button in the visual representations section:
Select Bake from the Types drop down list.
If you have multiple providers configured, select Amazon from the Provider drop down list. Next select the region or regions you want to bake in. In the Package field, enter the name of the package that your Jenkins job archived.
- The package name should not include any version numbers. For example, if your build produces a deb file named “myapp_1.27-h343”, you would enter “myapp” here.
- If you configure your own Base AMI under the Advanced Options, the Base OS configuration is ignored.

Add a Deploy stage

Now add a Deploy stage by clicking Add stage again. Select Deploy In the Type drop down list. Deploy’s configuration settings should pop up on the screen.

Note: If you want to reorganize the order that the stages execute in the pipeline, you can add or remove precursor stages in the Depends On field.
In the Deploy Configuration section, click on the “Add server group” button. Pick your provider, if more than one is configured. This example uses AWS.
Because this is a new application, do not choose to copy a configuration from a template. Press the Continue without a template button.
It’s important to set up the correct Deploy Strategy for your use case. Use the Highlander strategy for this example, which will ensure that only one server group for your application exists at a time.
In the Load Balancers section, select the load balancer you created before you began this tutorial.
Select a security group that you are comfortable with, which will define the access rights to your resource.
Select Instance Type as Micro Utility, then set the size as “small”.
For Capacity, select how many instances you want in your server group. For our example, we will set it at 1.
Click “add”. You will be brought back to your Application and see a new Deploy Configuration. Press “Save Changes” at the bottom right of your window.

Execute the Pipeline

Click on the Pipelines option. You should see your new pipeline. Click on Start Manual Execution.
You will be able to select a Build for your Jenkins job from a drop down menu. By default, Spinnaker will not recreate an AMI unless the underlying package has changed. If you would like to force it, you may use the checkbox for “Rebake”.
Press “Run”, and you should see a progress bar where blue represents running and green represents complete. Gray represents not ran or canceled, which is not in our example picture.

If your pipeline does not succeed, refer to one of the troubleshooting sections in the pipelines, baking, or deploying guides.

Note: Always remember to save your changes by clicking the button in the bottom right of the window.

Continuous-Deployment: Manage Operator

Mon, 01 Jan 0001 00:00:00 +0000

This guide is for both the Armory Operator and the Spinnaker Operator. Armory Continuous Deployment and Spinnaker configuration is the same except for features only in Armory Continuous Deployment. Those features are marked .

Upgrade the Operator

Do not manually change Docker image tags in your existing manifest files. Operator computes the compatible Halyard version, so manually updating image tags is an unsupported upgrade method and may cause issues.

Use the kubectl replace command to replace your Operator deployment. See the kubectl replace docs for an explanation of this command.

Download the Operator version you want to upgrade to:

Armory Operator

In the following command, replace <version> with the specific version or “latest” for the most recent version.
```
bash -c 'curl -L https://github.com/armory-io/spinnaker-operator/releases/download/<version>/manifests.tgz | tar -xz'
```
Spinnaker Operator

In the following command, replace <version> with the specific version or “latest” for the most recent version.
```
bash -c 'curl -L https://github.com/armory/spinnaker-operator/releases/download/<version>/manifests.tgz | tar -xz'
```
Update CRDs across the cluster:
```
kubectl replace -f deploy/crds/
```

Update the Operator:

kubectl -n spinnaker-operator replace -f deploy/operator/cluster

Uninstall the Operator

Uninstalling the Operator involves deleting its deployment and SpinnakerService CRD. When you delete the Operator CRD, Kubernetes deletes any installation created by Operator. This occurs because the CRD is set as the owner of the resources, so they get garbage collected.

You can remove this ownership relationship so that Armory Continuous Deployment is not deleted when deleting the Operator by removing Operator ownership of resources.

Remove Operator ownership of Armory Continuous Deployment resources

Run the following script to remove ownership of Armory resources, where NAMESPACE is the namespace where Armory Continuous Deployment is installed:

#! /usr/bin/env bash
NAMESPACE=
for rtype in deployment service
do
 for r in $(kubectl -n $NAMESPACE get $rtype --selector=app=spin -o jsonpath='{.items[*].metadata.name}')
 do
 kubectl -n $NAMESPACE patch $rtype $r --type json -p='[{"op": "remove", "path": "/metadata/ownerReferences"}]'
 done
done

After the script completes, delete the Operator and its CRDs from the Kubernetes cluster:

kubectl delete -n <namespace> -f deploy/operator/<installation type>
kubectl delete -f deploy/crds/

Help resources

Armory Operator and Armory Continuous Deployment: contact Armory Support or use the Spinnaker Slack #armory channel.
Spinnaker Operator and Spinnaker: Spinnaker Slack #kubernetes-operator channel.

Continuous-Deployment: Secrets in Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Note: Storing Spinnaker secrets in a Kubernetes secret is only supported if you’re using the Operator to deploy and manage Spinnaker. Additionally, you cannot encrypt configuration secrets for the UI (Deck) using the Kubernetes secret engine.

Creating a Kubernetes secret for Spinnaker to use

This example uses a Kubernetes secret to store GitHub credentials and a kubeconfig file.

Spinnaker^TM can read secrets only within its own namespace. It cannot access Kubernetes secrets stored in a different namespace. In this document, assume that Spinnaker lives in the namespace spinnaker.

You can store files as well as individual text values in Kubernetes secrets to be referenced by Spinnaker. To create the secret you can use this command, assuming you have a file named kubeconfig-prod where you are running the command:

kubectl -n spinnaker create secret generic spin-secrets \
 --from-file=kubeconfig-prod \
 --from-literal=github-token=aaaaaabbbbbbbbccccccccc

The command will create a secret named spin-secrets in the spinnaker namespace, having two keys: one is a kubeconfig file with key kubeconfig-prod , and the other is a text value for a GitHub token with key github-token.

Kustomize also has a secret generator, so you can automatically deploy secrets using Kustomize along with the SpinnakerService manifest. This is a kustomization.yml file that creates the same secret as above:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

secretGenerator:
 - name: spin-secrets
 files:
 - kubeconfig-prod
 literals:
 - github-token=aaaaaabbbbbbbbccccccccc

For more information on how to create secrets in Kubernetes refer to the official Kubernetes docs or the Kustomize docs.

Referencing secrets

You reference secret values in your config with the following format:

encrypted:k8s!n:<secret name>!k:<secret key>

Similarly you can reference secret files:

encryptedFile:k8s!n:<secret name>!k:<secret key>

For example, to reference the GitHub token:

encrypted:k8s!n:spin-secrets!k:github-token

And to reference the content of our kubeconfig file:

encryptedFile:k8s!n:spin-secrets!k:kubeconfig-prod

Continuous-Deployment: Secrets with Google Cloud Storage

Mon, 01 Jan 0001 00:00:00 +0000

This example uses a bucket (mybucket) to store GitHub credentials and a kubeconfig file.

Authorize Spinnaker to access the GCS bucket

Since you’re storing sensitive information, make sure to protect the bucket by restricting access and enabling encryption.

Remember to run the Operator deployment and Spinnaker services with permissions to read that content.

Storing secrets

Store your GitHub credentials in mybucket/spinnaker-secrets.yml:

github:
 password: <PASSWORD>
 token: <TOKEN>

Note: You can store the password under different keys than github.password and github.token. To do so, change how you reference the secret.

Referencing secrets

Now that secrets are securely stored in the bucket, you reference them in your config files with the following format:

encrypted:gcs!b:<bucket>!f:<path to file>!k:<optional yaml key>

For example, to reference github.password from the file above, use:

encrypted:gcs!b:mybucket!f:spinnaker-secrets.yml!k:github.password

To reference the content of our kubeconfig file:

encrypted:gcs!f:mykubeconfig!b:mybucket

Continuous-Deployment: Secrets with S3

Mon, 01 Jan 0001 00:00:00 +0000

See the S3 Getting Started Guide for more information on encryption in S3. This example uses a bucket (mybucket) in the us-west-2 region to store GitHub credentials and a kubeconfig file. You reference the bucket by its URL mybucket.us-west-2.amazonaws.com.

Authorize Spinnaker to access the S3 bucket

Since you’re storing sensitive information, make sure to protect the bucket by restricting access and enabling encryption.

Remember to run the Operator and Spinnaker^TM services with IAM roles that allow them to read the keys stored in the AWS S3 Bucket.

Storing secrets

Storing credentials

Store your GitHub credentials in mybucket/spinnaker-secrets.yml:

github:
 password: <PASSWORD>
 token: <TOKEN>

Note: You could choose to store the password under different keys than github.password and github.token. You’d just need to change how to reference the secret further down.

Storing sensitive files

Some Spinnaker configuration uses information stored as files. For example, upload the kubeconfig file of your Kubernetes account directly to mybucket/mykubeconfig:

aws s3 cp /path/to/mykubeconfig s3://mybucket/mykubeconfig

Referencing secrets

Now that secrets are safely stored in the bucket, you reference them from your config files with the following format. The S3 specific parameters (r:<region>, b:<bucket>, etc) can be in any order:

encrypted:s3!r:<region>!b:<bucket>!f:<path to file>!k:<optional yaml key>

For example, to reference github.password from the file above, we’ll use:

encrypted:s3!r:us-west-2!b:mybucket!f:spinnaker-secrets.yml!k:github.password

And to reference the content of our kubeconfig file:

encryptedFile:s3!r:us-west-2!b:mybucket!f:mykubeconfig

Continuous-Deployment: Spinnaker Accounts CRD

Mon, 01 Jan 0001 00:00:00 +0000

Experimental

The information below is written for an experimental feature. Reach out to Armory if you are interested in using this! Your feedback will help shape the development of this feature.

Do not use this experimental feature in a production instance of Armory Continuous Deployment.

`SpinnakerAcount` Custom Resource Definition overview

The Operator comes with a SpinnakerAccount Custom Resource for managing Kubernetes accounts that you want to use with Spinnaker. This SpinnakerAccount resource enables defining and managing Kubernetes accounts outside of Spinnaker’s manifest file. You create a separate manifest for each Kubernetes account and kubectl apply each manifest. kubectl delegates to the Operator, which then processes the manifest into the requisite configuration and adds the account to Armory Continuous Deployment or Spinnaker.

For example, you have a pipeline that provisions a Kubernetes cluster with Terraform. If you want that new cluster to be available, you can create a SpinnakerAccount of type Kubernetes in Spinnaker’s namespace.

Format

apiVersion: spinnaker.io/v1alpha2
kind: SpinnakerAccount
metadata:
 name: account-inline
spec:
 type: <Account type>
 enabled: true
 permissions: {} # List of permissions - see below
 settings: {} # Settings see below

`metadata.name`

This is the name of the SpinnakerAccount. It needs to be unique across all accounts - not just type of account as in Spinnaker.

`spec.type`

Account type. See below for current support:

Account type	Status	Notes
`Kubernetes`	alpha	Only the Spinnaker Kubernetes V2 provider is supported

`spec.enabled`

Determines if the account is enabled. If not enabled, SpinnakerService doesn’t use it.

`spec.permissions`

Map of authorizations similar to most accounts in Spinnaker.

spec:
 permissions:
 READ: ['role1', 'role2']
 WRITE: ['role1', 'role3']

`spec.settings`

Map of settings that are supported by Halyard. For instance:

spec:
 type: Kubernetes
 settings:
 cacheThreads: 2
 omitKinds:
 - podPreset

`spec.kubernetes`

Auth options for Kubernetes account type. Pick only one of the options below:

`spec.kubernetes.kubeconfigFile`

References a file loaded either out of band to Clouddriver or (more likely) stored in a secret.

`spec.kubernetes.kubeconfigSecret`

Reference to a Kubernetes secret in the same namespace that contains the kubeconfig file:

spec:
 type: Kubernetes
 kubernetes:
 kubeconfigSecret:
 name: my-secret
 key: account1-kubeconfig

`spec.kubernetes.kubeconfig`

You can also inline the kubeconfig file if it does not contain secrets:

spec:
 type: Kubernetes
 kubernetes:
 kubeconfig:
 apiVersion: v1
 kind: Config
 clusters:
 - cluster:
 certificate-authority-data: LS0t...
 server: https://mycluster.url
 name: my-cluster
 contexts:
 - context:
 cluster: my-cluster
 user: my-user
 name: my-context
 current-context: my-context
 preferences: {}
 users:
 - name: my-user
 user:
 exec:
 apiVersion: client.authentication.k8s.io/v1alpha1
 args:
 - token
 - -i
 - my-eks-cluster
 command: aws-iam-authenticator

Help resources

Armory Operator and Armory Continuous Deployment: contact Armory Support or use the Spinnaker Slack #armory channel.
Spinnaker Operator and Spinnaker: Spinnaker Slack #kubernetes-operator channel.

Continuous-Deployment: Advanced Operator Configuration

Mon, 01 Jan 0001 00:00:00 +0000

This guide is for both the Armory Operator and the Spinnaker Operator. Armory Continuous Deployment and Spinnaker configuration is the same except for features only in Armory Continuous Deployment. Those features are marked .

Custom Halyard configuration

To override Halyard’s configuration, create a Kubernetes ConfigMap with the configuration changes you need. For example, if you’re using secrets management with Vault(), Halyard and Operator containers need your Vault configuration:

apiVersion: v1
kind: ConfigMap
metadata:
 name: halyard-custom-config
data:
 halyard-local.yml: |
 secrets:
 vault:
 enabled: true
 url: <URL of vault server>
 path: <cluster path>
 role: <k8s role>
 authMethod: KUBERNETES

Then, you can mount it in the Operator deployment and make it available to the Halyard and Operator containers:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
 name: spinnaker-operator
 ...
spec:
 template:
 spec:
 containers:
 - name: spinnaker-operator
 ...
 volumeMounts:
 - mountPath: /opt/spinnaker/config/halyard.yml
 name: halconfig-volume
 subPath: halyard-local.yml
 - name: halyard
 ...
 volumeMounts:
 - mountPath: /opt/spinnaker/config/halyard-local.yml
 name: halconfig-volume
 subPath: halyard-local.yml
 volumes:
 - configMap:
 defaultMode: 420
 name: halyard-custom-config
 name: halconfig-volume

Patching Runtime Resources with Kustomize

Your Kubernetes cluster may require additional sidecars or configuration present when managing Spinnaker resources. In these situations, the Armory Operator provides the ability to patch resources during reconciliation. These patches are executed via an embedded Kustomize instance in the Operator, and requires no additional installation on the user’s part. You can apply Kustomize patches at two levels of specificity:

Spinnaker as a whole
Individual services within Spinnaker

Additionally, you may make changes to the following resources generated by the Operator:

Deployment manifests
Service manifests

For example, to ensure that a ConfigMap is present on all Spinnaker services, you would add the following configuration block to your SpinnakerService config:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 kustomize:
 spinnaker:
 deployment:
 patchesJson6902: |
 - op: add
 path: /spec/template/spec/volumes/-
 value:
 name: custom-volume
 configMap:
 name: custom-volume
 - op: add
 path: /spec/template/spec/containers/0/volumeMounts/-
 value:
 mountPath: /opt/spinnaker/config/foo
 type: configMap
 name: custom-volume 

The previous configuration sample indicates how to specify patches in the patchesJson6902 format, that mounts a ConfigMap called custom-volume into the /opt/spinnaker/config/foo namespace.

When you no longer need the patches, you can remove them from the Operator config and they will be removed on next reconciliation for your cluster.

Help resources

Armory Operator and Armory Continuous Deployment: contact Armory Support or use the Spinnaker Slack #armory channel.
Spinnaker Operator and Spinnaker: Spinnaker Slack #kubernetes-operator channel.

Continuous-Deployment: Errors and Troubleshooting

Mon, 01 Jan 0001 00:00:00 +0000

Reconciler error

You may see this error even though Operator successfully applies your manifest. This error may be normal depending on the frequency of the error. Controllers work with a local cache that can be out of sync. The issue should resolve itself via repeated synchronization. One error may be fine since it’s in the design of the reconciler. Too many means something is wrong.

{
 "level": "error",
 "ts": 1592879777.6785922,
 "logger": "controller-runtime.controller",
 "msg": "Reconciler error",
 "controller": "spinnakerservice-controller",
 "request": "spinnaker-migration/spinnaker",
 "error": "Operation cannot be fulfilled on spinnakerservices.spinnaker.armory.io
 \"spinnaker\": the object has been modified; please apply your changes to the latest version and try again",
 "stacktrace": "github.com/go-logr/zapr.(*zapLogger).Error
 /opt/spinnaker-operator/build/vendor/github.com/go-logr/zapr/zapr.go:128
 sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler
 /opt/spinnaker-operator/build/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:218
 sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
 /opt/spinnaker-operator/build/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:192
 sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).worker
 /opt/spinnaker-operator/build/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:171
 k8s.io/apimachinery/pkg/util/wait.JitterUntil.func1
 /opt/spinnaker-operator/build/vendor/k8s.io/apimachinery/pkg/util/wait/wait.go:152
 k8s.io/apimachinery/pkg/util/wait.JitterUntil
 /opt/spinnaker-operator/build/vendor/k8s.io/apimachinery/pkg/util/wait/wait.go:153
 k8s.io/apimachinery/pkg/util/wait.Until
 /opt/spinnaker-operator/build/vendor/k8s.io/apimachinery/pkg/util/wait/wait.go:88"
}

Kustomize `panic` error

If you installed Kustomize standalone, Kustomize v4.0+ kustomize build throws a panic error when it tries to parse and build using the patch files in the spinnaker-kustomize-patches repo. For example:

panic: runtime error: index out of range [145] with length 145 [recovered]
 panic: runtime error: index out of range [145] with length 145

Starting with kubectl v1.21 , the bundled Kustomize version is v4.0.5, so if you execute kubectl kustomize ., you also see this error.

Solution:

Downgrade standalone Kustomize to v3.8.10.
Downgrade to kubectl v1.19.

Help resources

Armory Operator: contact Armory Support or use the Spinnaker Slack #armory channel.
Spinnaker Operator: Spinnaker Slack #kubernetes-operator channel.

Continuous-Deployment: Spinnaker Glossary

Mon, 01 Jan 0001 00:00:00 +0000

Amazon Web Services

Amazon Web Services (AWS) is a cloud services provider from Amazon that offers computing power, database storage, content delivery and additional functionalities to businesses that operate in the cloud. For Spinnaker purposes, think of AWS as a data center but instead of being physical servers it is in the cloud.

Amazon Machine Images

Amazon Machine Images (AMIs) are predetermined ’templates’ for instances that can be used to launch an instance of a virtual server. They generally include the configurations for the instance (Operating System, application server, applications), the permissions and Secrets that control which AWS accounts can access the instances, and a block device mapping that specifies the volumes to attach to the instance when it is launched.

Application

An application inside Spinnaker™ represents what you would typically find in a single code repository - and in many cases, an application maps directly to a microservice.

Auto-Scaling Group

An auto-scaling group (ASG) contains a collection of EC2 instances that share similar characteristics and are treated as a logical grouping for the purposes of instance scaling and management.

Authorization

Authorization (Auth) is the level of access to APIs that a user, application or role has within your AWS account. This is usually configured by your administrator.

Baking

The term ‘Baking’ is used within Spinnaker to refer to the process of creating machine images, usually with AMIs.

Cloud

Short for cloud computing, the cloud as we refer to it is internet-based computing that provides processing resources (e.g.; database storage, networks, servers, applications) on demand to devices connected to the internet.

Clouddriver

A sub-service within Spinnaker. See the Spinnaker Architecture for more information.

Cluster

A server group is a regional view of servers, whereas a cluster is a world-wide view of server groups.

Code repository

A source code repository is a private or public storage location for file archive and web hosting, used for source codes of software or web pages.

Continuous Delivery

Continuous Delivery (CD) is an engineering approach for DevOps teams to produce software in short cycles: building, testing, and releasing software at a fast and frequent pace in order to iterate as quickly as possible.

Continuous Integration

Continuous Integration (CI) is a development practice where software developers merge their separate changes and updates to a main source code repository - usually multiple times a day.

Deck

A sub-service within Spinnaker. See the Spinnaker Architecture for more information.

Debian package

Debian packages (deb) are two tar archives contained in standard Unix ar archives - one holds the control information and the other contains the data used for installation.

Detail

For cluster and server group configurations, ‘Detail’ is usually any additional piece of user-defined information you want to label your cluster and server group(s) with.

Echo

A sub-service within Spinnaker. See the Spinnaker Architecture for more information.

Elastic Compute Cloud

Elastic Compute Cloud (EC2) is part of the AWS cloud platform, a “pay as you go” virtual computer renting system that contains preconfigured software and applications requested by the user.

Execution

When a pipeline runs, the end result is called an execution.

Gate

A sub-service within Spinnaker. See the Spinnaker Architecture for more information.

Igor

A sub-service within Spinnaker. See the Spinnaker Architecture for more information.

Infrastructure version

The infrastructure’s version number; such as v011, v012, etc. This is automatically appended and is not user defined.

In AWS, Spinnaker will name your ASGs and Launch Configurations according to the naming convention mentioned above (ie. “armoryspinnaker-prod-polling-v015”).

Please note that if your user definition includes a hyphen, it will disrupt the naming convention.

Jenkins

Jenkins is an open source automation server that can package applications for distribution. Spinnaker pipelines can be [triggered]trigger) from a build on Jenkins.

Load balancer

For Spinnaker’s purposes, a load balancer is a service that automatically distributes incoming traffic across all instances. The one most commonly used within AWS is the Elastic Load Balancer (ELB).

Orca

A sub-service within Spinnaker. See the Spinnaker Architecture for more information.

Pipeline

Learn to create your first pipeline here.

Project

A project inside Spinnaker is a logical grouping of applications. For example, we might create a project called “Spinnaker” and its applications would be “Deck”, “Orca”, “Clouddriver”, etc. Spinnaker provides a helpful dashboard view using Deck for each project to visualize its applications and status of each application contained within it.

Rosco

A sub-service within Spinnaker. See the Spinnaker Architecture for more information.

Scale server group

Reduce the total number of server groups remaining in the cluster.

Server group

From an Amazon Web Service (AWS) point of view, a server group is represented by an auto-scaling group (ASGs). All applications that are deployed by Spinnaker are deployed to server groups.

Shrink server group

Reduce the number of instances in a particular server group.

Stack

Note that Stack names are defined by the user in the Spinnaker configuration User Interface (UI).

Stage

Within a pipeline, the tasks that pipeline performs are called stages.

Trigger

A trigger is the entry point to a pipeline - when a pipeline is triggered, it attempts to execute.

Continuous-Deployment: v2.36.9 Armory Continuous Deployment Release (Spinnaker™ v1.36.1)

Wed, 01 Apr 2026 00:00:00 +0000

2026-04-01 release notes

Note: If you experience production issues after upgrading Armory Continuous Deployment, roll back to a previous working version and report issues to http://go.armory.io/support.

Required Armory Operator version

Important

Armory Operator has been deprecated and is considered EOL. Please migrate to the Kustomize method of deployment.

To install, upgrade, or configure Armory CD 2.36.9, use Armory Operator 1.8.6 or later.

Security

Armory scans the codebase as we develop and release software. Contact your Armory account representative for information about this release.

Breaking changes

The following configuration properties have been restructured:

Previous Configuration:

tasks:
 days-of-execution-history:
 number-of-old-pipeline-executions-to-include:

New configuration format

tasks:
 controller:
 days-of-execution-history:
 number-of-old-pipeline-executions-to-include:
 optimize-execution-retrieval: <boolean>
 max-execution-retrieval-threads:
 max-number-of-pipeline-executions-to-process:
 execution-retrieval-timeout-seconds:

These changes improve query performance and execution retrieval efficiency, particularly for large-scale pipeline applications.

Performance Improvements for SQL Backend

Known issues

Echo Filter enabled pipelines feature

Spinnaker OSS Version 1.31.0 introduced a feature to filter pipelines from front50, that was disabled by default. Version 1.35.0 enabled it by default, which is not recommended and can cause issues with automated triggers. In Armory CD 2.36.2 we recommend to explicitly disable this feature by setting the following configuration:

apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 spinnakerConfig:
 profiles:
 echo:
 pipelineCache:
 filterFront50Pipelines: false

Highlighted updates

Clouddriver: Redis scheduler configuration validation

Clouddriver now validates Redis scheduler configuration keys more strictly at startup:

Legacy scalar redis.scheduler is rejected.
Legacy redis.parallelism is rejected.
Use nested keys under redis.scheduler.*.

Before:

redis:
 scheduler: default
 parallelism: -1

After:

redis:
 scheduler:
 enabled: true
 type: default
 parallelism: -1

If redis.scheduler.type is missing or blank, Clouddriver defaults to default for compatibility.

Security hardening: URL restriction validation for artifacts and webhooks

This release includes fixes that improve validation around user-supplied Git repository inputs used by GitRepo artifacts.

This release tightens URL host validation for artifact accounts and Orca webhook URL restrictions:

Validation now uses parsed host handling (HttpUrl.host()) instead of authority fallback parsing.
This prevents authority/userinfo patterns from bypassing hostname checks.
URL handling for underscore hostnames and IPv6 input is stricter and more predictable.

If you use uncommon URL formats (for example userinfo segments, unbracketed IPv6 literals, or underscore-based hosts), test those paths after upgrade.

Clouddriver SQL cache: sharding-aware unknown-agent cleanup

SqlUnknownAgentCleanupAgent now respects shard ownership and includes additional safety controls to avoid cross-pod or startup-race cleanup behavior in SQL cache environments.

Key updates:

The cleanup agent remains opt-in and disabled by default.
The cleanup agent is only created when sql.read-only=false.
Cleanup skips when sharding state is uninitialized or misconfigured.
New controls include minRecordAgeSeconds, dryRun, and excludedDataTypes.

Configuration:

sql:
 unknown-agent-cleanup-agent:
 enabled: false
 pollIntervalSeconds: 120
 timeoutSeconds: 60
 minRecordAgeSeconds: 300
 deleteBatchSize: 100
 dryRun: false
 excludedDataTypes: []

HA deployment guidance

In HA mode, enable sql.unknown-agent-cleanup-agent.enabled: true only on Clouddriver caching pods.

For caching pods:

sql:
 unknown-agent-cleanup-agent:
 enabled: true

For all non-caching Clouddriver pods:

sql:
 unknown-agent-cleanup-agent:
 enabled: false

Clouddriver cache sharding: pluggable strategy and key extraction

Cache sharding now supports pluggable strategies and key extractors for Redis and SQL sharding observers:

strategy: modulo (default, preserves legacy ownership mapping)
strategy: canonical-modulo (canonical positive modulo)
strategy: jump (jump consistent hash, less key movement during scale events)
sharding-key: account | region | agent

Defaults remain strategy: modulo and sharding-key: account, so existing behavior is preserved unless you opt in to a different strategy/key.

Configuration:

cache-sharding:
 strategy: modulo
 sharding-key: account
 replica-ttl-seconds: 60
 heartbeat-interval-seconds: 30

SqlCachingPodsObserver also resets to a fail-open state on heartbeat/topology refresh failure to avoid stale routing decisions.

Clouddriver: Redis Priority Scheduler (opt-in)

A new Redis-based priority scheduler is available for Clouddriver caching agents.

Key points:

Uses Redis sorted sets and Lua scripts for atomic scheduling transitions.
Adds cleanup services (zombie/orphan), circuit breakers, and richer scheduler observability.
Requires Redis 6.2+ (ZMSCORE).

Enablement:

redis:
 scheduler:
 enabled: true
 type: priority
 agent:
 max-concurrent-agents: 100

Migration notes:

Legacy scalar redis.scheduler and legacy redis.parallelism are rejected.
redis.scheduler.parallelism is ignored in priority mode.
Use redis.agent.max-concurrent-agents to control concurrency for priority mode.
redis.agent.disabledAgents is ignored in priority mode; use redis.agent.disabled-pattern.

AWS JDBC Driver Update

The AWS JDBC driver has been updated from the deprecated aws-mysql-jdbc driver (version 1.0.0) to the AWS Advanced JDBC Wrapper.

This update adds support for IAM authentication with AWS Aurora Global Database endpoints. The previous driver did not support global database endpoint format (*.global.rds.amazonaws.com) when using IAM authentication, resulting in the error:

java.sql.SQLException: Unsupported AWS hostname '<hostname>.global.rds.amazonaws.com'.
Amazon domain name in format *.AWS-Region.rds.amazonaws.com is expected

Note: Standard database connections (without IAM authentication) continue to work as before and do not require any configuration changes.

Affected services: Front50, Orca, Clouddriver, Fiat

Configuration for IAM Authentication with Aurora Global Database

If you are using IAM authentication and want to connect to Aurora Global Database endpoints, update your JDBC connection string:

New JDBC URL format:

jdbc:aws-wrapper:mysql://<GLOBAL_ENDPOINT>:<PORT>/<DATABASE>?wrapperPlugins=iam&globalClusterInstanceHostPatterns=?.<CLUSTER_IDENTIFIER>.<REGION1>.rds.amazonaws.com,?.<CLUSTER_IDENTIFIER>.<REGION2>.rds.amazonaws.com&iamRegion=<CURRENT_REGION>

Example: If your Aurora Global Database has:

Global endpoint: mydb-global.global-xxxxx.global.rds.amazonaws.com
Primary (us-west-2): mydb.cluster-abc123.us-west-2.rds.amazonaws.com
Secondary (us-east-1): mydb.cluster-abc123.us-east-1.rds.amazonaws.com

Configure the JDBC URL as:

jdbc:aws-wrapper:mysql://mydb-global.global-xxxxx.global.rds.amazonaws.com:3306/front50?wrapperPlugins=iam&globalClusterInstanceHostPatterns=?.cluster-abc123.us-west-2.rds.amazonaws.com,?.cluster-abc123.us-east-1.rds.amazonaws.com&iamRegion=us-west-2

Observability Plugin Update

The Armory Observability plugin has been updated to version 1.6.1 to resolve compatibility issues with the new AWS JDBC wrapper.

Security enhancement: Url Filtering/Restriction capabilities on Artifact accounts

Starting in Armory Continuous Deployment 2.36.6, we have enabled to capability to filter/restrict urls that can be accessed per artifact accounts. This feature provides a safeguard around user input of remote urls when artifact accounts are in used in the context of a pipeline execution.

An example configuration can be found below which can be added per artifact account (http, github, helm):

artifacts:
 http:
 enabled: true
 accounts:
 - name: http_account
 urlRestrictions:
 allowedDomains:
 - mydomain.com
 - raw.github.com
 - api.github.com
 rejectLocalhost: true #default value
 rejectLinkLocal: true #default value
 rejectVerbatimIps: true #default value
 rejectedIps: [] #default value

By default the configuration blocks any local CIDR ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), localhost, link local and raw IPs. For full configuration details please refer to this configuration class

Armory Continuous Deployment 2.36.2 onwards Docker images now based on Ubuntu

The Armory Continuous Deployment 2.36.2 Docker images have been updated to use Ubuntu as the base image, replacing the previous Alpine base. This change enhances compatibility with various libraries and tools, improving overall stability and performance. Additionally, the new images now include all the necessary dependencies for authentication on a Kebreros server.

Pipeline Reference feature is now able to Lazy load the pipeline reference pipelines

In Spinnaker OSS release 1.35.0 Orca introduced a feature flag to reduce the execution size in nested pipelines by converting PipelineTrigger to PipelineRefTrigger:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 spinnakerConfig:
 profiles:
 orca:
 executionRepository:
 sql:
 enabled: true
 pipelineRef:
 enabled: true

When enabled, child pipeline execution ids are stored in sql instead of the entire child pipeline execution context.

In Armory CD 2.36.2 this functionality is now extended to make the in-memory representation of the pipelines aware of the pipeline reference and to not load in-memory a full representation of the pipeline context. To enable this feature in Deck add the following in settings-local.js:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 spinnakerConfig:
 profiles:
 deck:
 settings-local.js: |
 ...
 window.spinnakerSettings.feature.pipelineRefEnabled = true;
 ... 

Orca PR 4842 Deck PR 10164

New pipeline stage configuration `backOffPeriodMs`

A new configuration option backOffPeriodMs has been added to the pipeline stage configuration. This option allows users to specify a back-off period in milliseconds for stages that may need to retry operations after a failure. Before this, pipeline authors had no control over the backoff period. It came from either spinnaker configuration properties or implementations of RetryableTask.getDynamicBackoffPeriod.

Additionally, the following configuration options have been added that allow admins to specify globablly the backoff period:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 spinnakerConfig:
 profiles:
 orca:
 tasks.global.backOffPeriod:
 tasks.<cloud provider>.backOffPeriod:
 tasks.<cloud provider>.<account name>.backOffPeriod:

Orca PR 4841

Java upgrades

Java 17 is now the default source and target. Java 11 support has been removed entirely. Please note you may need to add the following JAVA_OPTS options: --add-exports=java.base/sun.security.x509=ALL-UNNAMED --add-exports=java.base/sun.security.pkcs=ALL-UNNAMED --add-exports=java.base/sun.security.rsa=ALL-UNNAMED to clouddriver if using GCP accounts due to credentials parsing of certificates. These can set in the service-settings config . These configs are likely to be added to the defaults in all future releases

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 spinnakerConfig:
 service-settings:
 clouddriver:
 env:
 JAVA_OPTS: "--add-exports=java.base/sun.security.x509=ALL-UNNAMED --add-exports=java.base/sun.security.pkcs=ALL-UNNAMED --add-exports=java.base/sun.security.rsa=ALL-UNNAMED"

Performance Improvements for Pipeline Executions

This release includes several optimizations to improve pipeline execution times, particularly for complex pipeline structures.

Key Improvements

Memorize the anyUpstreamStagesFailed extension function to improve time complexity from exponential to linear
Optimize getAncestorsImpl to reduce time complexity by a factor of N, where N is the number of stages in a pipeline
Optimize StartStageHandler to only call withAuth (which calls getAncestorsImpl) when

These enhancements significantly reduce pipeline execution time, with the most notable gains observed in dense pipeline graphs. For example, in the ComplexPipeline.kt test scenario, execution time improved from not completing at all to approximately 160ms.

PR 4824

Performance Improvements for SQL Backend

This release enhances the performance of SQL-backed pipeline queries by optimizing database operations, particularly for the API call:

/applications/{application}/pipelines?expand=false&limit=2

which is frequently initiated by Deck and forwarded through Gate to Orca.

Key Improvements

Improved Query Efficiency: Optimized the retrieval of pipeline execution data, significantly reducing database query times.
Refactored TaskController: Externalized configuration properties to allow better flexibility and tuning.
Enhanced getPipelinesForApplication()
- Limits the number of pipeline config IDs queried.
- Processes multiple pipeline config IDs simultaneously.
- Introduces multi-threading to handle batches efficiently.

PR 4804

Feature: Read Connection Pool for SQL Execution Repository

This release introduces support for a dedicated read connection pool for specific read-only database queries in SqlExecutionRepository

Key Improvements

New “read” Connection Pool: Allows read operations to be routed to a separate connection pool.
Configurable Read Pool: Users can define an additional read connection pool in the SQL configuration.
Ensures Data Consistency: Some read queries still rely on recently written data and are not yet converted to use a read replica due to potential replication lag.

Configuration Example

To enable the read connection pool, add the following configuration:

sql:
 connectionPools:
 default:
 <...>
 read:
 jdbcUrl: jdbc:...
 user: orca_service
 password:
 connectionTimeoutMs:
 validationTimeoutMs:
 maxPoolSize:
 minIdle:
 maxLifetimeMs:
 idleTimeoutMs:

PR 4803

Enhanced pipeline batch update feature

Gate

Adds a new enpdoint, POST /pipelines/bulksave, which can take a list of pipeline configurations to save. The endpoint will return a response that indicates how many of the saves were successful, how many failed, and what the failures are. The structure is

[
 "successful_pipelines_count" : <int>,
 "successful_pipelines" : <List<String>>,
 "failed_pipelines_count" : <int>,
 "failed_pipelines" : <List<Map<String, Object>>>
]

There are a few config knobs which control some bulk save functionality. The gate endpoint invokes an orca asynchronous process to manage saving the pipelines and polls until the orca operations are complete.

controller:
 pipeline:
 bulksave:
 # the max number of times gate will poll orca to check for task status
 max-polls-for-task-completion: <int>
 # the interval at which gate will poll orca.
 taskCompletionCheckIntervalMs: <int>

Orca

Updates Orca’s SavePipelineTask to support bulk saves using the updated functionality in the front50 bulk save endpoint.

With Orca PR 4781, keys from the stage context’s outputs section can now be removed (there by reducing the context size significantly). At present the following tasks support this feature:

PromoteManifestKatoOutputsTask
WaitOnJobCompletionTask
ResolveDeploySourceManifestTask
BindProducedArtifactsTask

The Orca PR 4788 introduced a new CheckIfApplicationExists task that is added to various pipeline stages to check if the application defined in the pipeline stage context is known to front50 and/or clouddriver. The following config knobs are provided so that all of these stages can be individually configured to not perform this check if needed. Default value is set to false for all of them.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 spinnakerConfig:
 profiles:
 orca:
 tasks:
 clouddriver:
 promoteManifestKatoOutputsTask:
 excludeKeysFromOutputs:
 - outputs.createdArtifacts
 - outputs.manifests
 - outputs.boundArtifacts
 waitOnJobCompletionTask:
 excludeKeysFromOutputs:
 - jobStatus
 - completionDetails
 resolveDeploySourceManifestTask:
 excludeKeysFromOutputs:
 - manifests
 - requiredArtifacts
 - optionalArtifacts
 core:
 bindProducedArtifactsTask:
 excludeKeysFromOutputs:
 - artifacts

Separate config knobs are also provided at the AbstractCheckIfApplicationExistsTask level to determine if clouddriver needs to be queried for the application or not. It is by default set to true, so it is an opt-out capability. the config property is:

tasks:
 clouddriver:
 checkIfApplicationExistsTask:
 checkClouddriver: false # default is true

This feature runs in audit mode by default which means if checkIfApplicationExistsTask finds no application, a warning message is logged. But when audit mode is disabled through the following property, pipelines fail if application is not found:

tasks:
 clouddriver:
 checkIfApplicationExistsTask:
 auditModeEnabled: false # default is true

Front50

Batch update operation in front50 is now atomic. Deserialization issues are addressed. Configurable controls are added to decide whether cache should be refreshed while checking for duplicate pipelines:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 spinnakerConfig:
 profiles:
 front50:
 controller:
 pipeline:
 save:
 refreshCacheOnDuplicatesCheck: false // default is true

Batch update call now responds with a status of succeeded and failed pipelines info. The response will be a map containing information in the following format:

[
 "successful_pipelines_count" : <int>,
 "successful_pipelines" : <List<String>>,
 "failed_pipelines_count" : <int>,
 "failed_pipelines" : <List<Map<String, Object>>>
]

Here the value for successful_pipelines is the list of successful pipeline names whereas the value for failed_pipelines is the list of failed pipelines expressed as maps.

Spinnaker community contributions

Armory CD 2.36.9 tracks the latest published upstream 1.36.x patch line.

Upstream references:

Notable upstream changes:

Clouddriver: improved ECS target-group health evaluation and several AWS/GCP reliability fixes.
Gate/Echo: SAML signing behavior fix and duplicate manual-judgment notification fix.
Clouddriver (Google): async operation retry/status polling to prevent progressing pipeline tasks before cloud operations settle.
Clouddriver (GitRepo artifacts): validation fixes around user input and repository URL handling (backports #7542, #7564).

Detailed updates

Bill Of Materials (BOM)

Expand to see the BOM


version: 2.36.9
timestamp: 2026-04-01
services:
clouddriver:
version: 2.36.9
commit: 6deeb3c2a0f57149a595698ba3f2b83a2be8e36f
deck:
version: 2.36.9
commit: 54a2aada8cb187554536daeb8b8b2858714d1afe
dinghy:
version: 2.36.9
commit: d36fdf5b496b18212275686d4c9069d72c9dbeb1
echo:
version: 2.36.9
commit: 9ff1559a08ed6851c036ff1f51bde20e1eb36248
fiat:
version: 2.36.9
commit: e77853e0322014f3b3f8911d9d6f2431830c192c
front50:
version: 2.36.9
commit: 5f8f39172e88b3abe49bab28e2fcb786b8653bf0
gate:
version: 2.36.9
commit: f99a459232f70e19a719a1962f7c6fcee9218750
igor:
version: 2.36.9
commit: 30cab7aaabdfe08c05c37146ab644555cf413513
kayenta:
version: 2.36.9
commit: 2ce818eed3873004412758a0f731cf8420df8594
orca:
version: 2.36.9
commit: 178d4b576e7b8136c42e0baa108cbf2730f6cec8
rosco:
version: 2.36.9
commit: 8e35f1c3560b3b8f7de6fc4a35718b4aee98a47c
terraformer:
version: 2.36.9
commit: 8453d42107fda5f0c315c8459f523e9182805832
monitoring-daemon:
version: 2.26.0
monitoring-third-party:
version: 2.26.0
dependencies:
redis:
version: 2:2.8.4-2
artifactSources:
dockerRegistry: docker.io/armory

Armory

Armory Clouddriver - 2.36.8…2.36.9

fix(validation): Fixes some validation around user inputs (upstream #7542)
fix(gitrepo): Fix git repo with some odd character combinations (upstream #7564)

Armory Fiat - 2.36.8…2.36.9

Armory Front50 - 2.36.8…2.36.9

Armory Orca - 2.36.8…2.36.9

Armory Igor - 2.36.8…2.36.9

Terraformer™ - 2.36.8…2.36.9

Armory Rosco - 2.36.8…2.36.9

Armory Gate - 2.36.8…2.36.9

Armory Echo - 2.36.8…2.36.9

Armory Deck - 2.36.8…2.36.9

Armory Kayenta - 2.36.8…2.36.9

Dinghy™ - 2.36.8…2.36.9

Spinnaker

Spinnaker Igor - 1.36.1

Spinnaker Rosco - 1.36.1

Spinnaker Gate - 1.36.1

Spinnaker Echo - 1.36.1

Spinnaker Deck - 1.36.1

Spinnaker Orca - 1.36.1

Spinnaker Kayenta - 1.36.1

Spinnaker Front50 - 1.36.1

Spinnaker Clouddriver - 1.36.1

Spinnaker Fiat - 1.36.1

Continuous-Deployment: v2.36.8 Armory Continuous Deployment Release (Spinnaker™ v1.36.1)

Thu, 05 Mar 2026 00:00:00 +0000

2026-03-05 release notes

Note: If you experience production issues after upgrading Armory Continuous Deployment, roll back to a previous working version and report issues to http://go.armory.io/support.

Required Armory Operator version

Important

Armory Operator has been deprecated and is considered EOL. Please migrate to the Kustomize method of deployment.

To install, upgrade, or configure Armory CD 2.36.8, use Armory Operator 1.8.6 or later.

Security

Armory scans the codebase as we develop and release software. Contact your Armory account representative for information about CVE scans for this release.

Breaking changes

The following configuration properties have been restructured:

Previous Configuration:

tasks:
 days-of-execution-history:
 number-of-old-pipeline-executions-to-include:

New configuration format

tasks:
 controller:
 days-of-execution-history:
 number-of-old-pipeline-executions-to-include:
 optimize-execution-retrieval: <boolean>
 max-execution-retrieval-threads:
 max-number-of-pipeline-executions-to-process:
 execution-retrieval-timeout-seconds:

These changes improve query performance and execution retrieval efficiency, particularly for large-scale pipeline applications.

Performance Improvements for SQL Backend

Known issues

Echo Filter enabled pipelines feature

apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 spinnakerConfig:
 profiles:
 echo:
 pipelineCache:
 filterFront50Pipelines: false

Highlighted updates

Clouddriver: Redis scheduler configuration validation

Clouddriver now validates Redis scheduler configuration keys more strictly at startup:

Legacy scalar redis.scheduler is rejected.
Legacy redis.parallelism is rejected.
Use nested keys under redis.scheduler.*.

Before:

redis:
 scheduler: default
 parallelism: -1

After:

redis:
 scheduler:
 enabled: true
 type: default
 parallelism: -1

If redis.scheduler.type is missing or blank, Clouddriver defaults to default for compatibility.

Security hardening: URL restriction validation for artifacts and webhooks

This release tightens URL host validation for artifact accounts and Orca webhook URL restrictions:

Validation now uses parsed host handling (HttpUrl.host()) instead of authority fallback parsing.
This prevents authority/userinfo patterns from bypassing hostname checks.
URL handling for underscore hostnames and IPv6 input is stricter and more predictable.

If you use uncommon URL formats (for example userinfo segments, unbracketed IPv6 literals, or underscore-based hosts), test those paths after upgrade.

Clouddriver SQL cache: sharding-aware unknown-agent cleanup

SqlUnknownAgentCleanupAgent now respects shard ownership and includes additional safety controls to avoid cross-pod or startup-race cleanup behavior in SQL cache environments.

Key updates:

The cleanup agent remains opt-in and disabled by default.
The cleanup agent is only created when sql.read-only=false.
Cleanup skips when sharding state is uninitialized or misconfigured.
New controls include minRecordAgeSeconds, dryRun, and excludedDataTypes.

Configuration:

sql:
 unknown-agent-cleanup-agent:
 enabled: false
 pollIntervalSeconds: 120
 timeoutSeconds: 60
 minRecordAgeSeconds: 300
 deleteBatchSize: 100
 dryRun: false
 excludedDataTypes: []

HA deployment guidance

In HA mode, enable sql.unknown-agent-cleanup-agent.enabled: true only on Clouddriver caching pods.

For caching pods:

sql:
 unknown-agent-cleanup-agent:
 enabled: true

For all non-caching Clouddriver pods:

sql:
 unknown-agent-cleanup-agent:
 enabled: false

Clouddriver cache sharding: pluggable strategy and key extraction

Cache sharding now supports pluggable strategies and key extractors for Redis and SQL sharding observers:

strategy: modulo (default, preserves legacy ownership mapping)
strategy: canonical-modulo (canonical positive modulo)
strategy: jump (jump consistent hash, less key movement during scale events)
sharding-key: account | region | agent

Defaults remain strategy: modulo and sharding-key: account, so existing behavior is preserved unless you opt in to a different strategy/key.

Configuration:

cache-sharding:
 strategy: modulo
 sharding-key: account
 replica-ttl-seconds: 60
 heartbeat-interval-seconds: 30

SqlCachingPodsObserver also resets to a fail-open state on heartbeat/topology refresh failure to avoid stale routing decisions.

Clouddriver: Redis Priority Scheduler (opt-in)

A new Redis-based priority scheduler is available for Clouddriver caching agents.

Key points:

Uses Redis sorted sets and Lua scripts for atomic scheduling transitions.
Adds cleanup services (zombie/orphan), circuit breakers, and richer scheduler observability.
Requires Redis 6.2+ (ZMSCORE).

Enablement:

redis:
 scheduler:
 enabled: true
 type: priority
 agent:
 max-concurrent-agents: 100

Migration notes:

Legacy scalar redis.scheduler and legacy redis.parallelism are rejected.
redis.scheduler.parallelism is ignored in priority mode.
Use redis.agent.max-concurrent-agents to control concurrency for priority mode.
redis.agent.disabledAgents is ignored in priority mode; use redis.agent.disabled-pattern.

AWS JDBC Driver Update

The AWS JDBC driver has been updated from the deprecated aws-mysql-jdbc driver (version 1.0.0) to the AWS Advanced JDBC Wrapper.

java.sql.SQLException: Unsupported AWS hostname '<hostname>.global.rds.amazonaws.com'.
Amazon domain name in format *.AWS-Region.rds.amazonaws.com is expected

Note: Standard database connections (without IAM authentication) continue to work as before and do not require any configuration changes.

Affected services: Front50, Orca, Clouddriver, Fiat

Configuration for IAM Authentication with Aurora Global Database

If you are using IAM authentication and want to connect to Aurora Global Database endpoints, update your JDBC connection string:

New JDBC URL format:

jdbc:aws-wrapper:mysql://<GLOBAL_ENDPOINT>:<PORT>/<DATABASE>?wrapperPlugins=iam&globalClusterInstanceHostPatterns=?.<CLUSTER_IDENTIFIER>.<REGION1>.rds.amazonaws.com,?.<CLUSTER_IDENTIFIER>.<REGION2>.rds.amazonaws.com&iamRegion=<CURRENT_REGION>

Example: If your Aurora Global Database has:

Global endpoint: mydb-global.global-xxxxx.global.rds.amazonaws.com
Primary (us-west-2): mydb.cluster-abc123.us-west-2.rds.amazonaws.com
Secondary (us-east-1): mydb.cluster-abc123.us-east-1.rds.amazonaws.com

Configure the JDBC URL as:

jdbc:aws-wrapper:mysql://mydb-global.global-xxxxx.global.rds.amazonaws.com:3306/front50?wrapperPlugins=iam&globalClusterInstanceHostPatterns=?.cluster-abc123.us-west-2.rds.amazonaws.com,?.cluster-abc123.us-east-1.rds.amazonaws.com&iamRegion=us-west-2

Observability Plugin Update

The Armory Observability plugin has been updated to version 1.6.1 to resolve compatibility issues with the new AWS JDBC wrapper.

Security enhancement: Url Filtering/Restriction capabilities on Artifact accounts

An example configuration can be found below which can be added per artifact account (http, github, helm):

artifacts:
 http:
 enabled: true
 accounts:
 - name: http_account
 urlRestrictions:
 allowedDomains:
 - mydomain.com
 - raw.github.com
 - api.github.com
 rejectLocalhost: true #default value
 rejectLinkLocal: true #default value
 rejectVerbatimIps: true #default value
 rejectedIps: [] #default value

Armory Continuous Deployment 2.36.2 onwards Docker images now based on Ubuntu

Pipeline Reference feature is now able to Lazy load the pipeline reference pipelines

In Spinnaker OSS release 1.35.0 Orca introduced a feature flag to reduce the execution size in nested pipelines by converting PipelineTrigger to PipelineRefTrigger:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 spinnakerConfig:
 profiles:
 orca:
 executionRepository:
 sql:
 enabled: true
 pipelineRef:
 enabled: true

When enabled, child pipeline execution ids are stored in sql instead of the entire child pipeline execution context.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 spinnakerConfig:
 profiles:
 deck:
 settings-local.js: |
 ...
 window.spinnakerSettings.feature.pipelineRefEnabled = true;
 ... 

Orca PR 4842 Deck PR 10164

New pipeline stage configuration `backOffPeriodMs`

Additionally, the following configuration options have been added that allow admins to specify globablly the backoff period:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 spinnakerConfig:
 profiles:
 orca:
 tasks.global.backOffPeriod:
 tasks.<cloud provider>.backOffPeriod:
 tasks.<cloud provider>.<account name>.backOffPeriod:

Orca PR 4841

Java upgrades

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 spinnakerConfig:
 service-settings:
 clouddriver:
 env:
 JAVA_OPTS: "--add-exports=java.base/sun.security.x509=ALL-UNNAMED --add-exports=java.base/sun.security.pkcs=ALL-UNNAMED --add-exports=java.base/sun.security.rsa=ALL-UNNAMED"

Performance Improvements for Pipeline Executions

This release includes several optimizations to improve pipeline execution times, particularly for complex pipeline structures.

Key Improvements

Memorize the anyUpstreamStagesFailed extension function to improve time complexity from exponential to linear
Optimize getAncestorsImpl to reduce time complexity by a factor of N, where N is the number of stages in a pipeline
Optimize StartStageHandler to only call withAuth (which calls getAncestorsImpl) when

PR 4824

Performance Improvements for SQL Backend

This release enhances the performance of SQL-backed pipeline queries by optimizing database operations, particularly for the API call:

/applications/{application}/pipelines?expand=false&limit=2

which is frequently initiated by Deck and forwarded through Gate to Orca.

Key Improvements

Improved Query Efficiency: Optimized the retrieval of pipeline execution data, significantly reducing database query times.
Refactored TaskController: Externalized configuration properties to allow better flexibility and tuning.
Enhanced getPipelinesForApplication()
- Limits the number of pipeline config IDs queried.
- Processes multiple pipeline config IDs simultaneously.
- Introduces multi-threading to handle batches efficiently.

PR 4804

Feature: Read Connection Pool for SQL Execution Repository

This release introduces support for a dedicated read connection pool for specific read-only database queries in SqlExecutionRepository

Key Improvements

New “read” Connection Pool: Allows read operations to be routed to a separate connection pool.
Configurable Read Pool: Users can define an additional read connection pool in the SQL configuration.
Ensures Data Consistency: Some read queries still rely on recently written data and are not yet converted to use a read replica due to potential replication lag.

Configuration Example

To enable the read connection pool, add the following configuration:

sql:
 connectionPools:
 default:
 <...>
 read:
 jdbcUrl: jdbc:...
 user: orca_service
 password:
 connectionTimeoutMs:
 validationTimeoutMs:
 maxPoolSize:
 minIdle:
 maxLifetimeMs:
 idleTimeoutMs:

PR 4803

Enhanced pipeline batch update feature

Gate

[
 "successful_pipelines_count" : <int>,
 "successful_pipelines" : <List<String>>,
 "failed_pipelines_count" : <int>,
 "failed_pipelines" : <List<Map<String, Object>>>
]

controller:
 pipeline:
 bulksave:
 # the max number of times gate will poll orca to check for task status
 max-polls-for-task-completion: <int>
 # the interval at which gate will poll orca.
 taskCompletionCheckIntervalMs: <int>

Orca

Updates Orca’s SavePipelineTask to support bulk saves using the updated functionality in the front50 bulk save endpoint.

With Orca PR 4781, keys from the stage context’s outputs section can now be removed (there by reducing the context size significantly). At present the following tasks support this feature:

PromoteManifestKatoOutputsTask
WaitOnJobCompletionTask
ResolveDeploySourceManifestTask
BindProducedArtifactsTask

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 spinnakerConfig:
 profiles:
 orca:
 tasks:
 clouddriver:
 promoteManifestKatoOutputsTask:
 excludeKeysFromOutputs:
 - outputs.createdArtifacts
 - outputs.manifests
 - outputs.boundArtifacts
 waitOnJobCompletionTask:
 excludeKeysFromOutputs:
 - jobStatus
 - completionDetails
 resolveDeploySourceManifestTask:
 excludeKeysFromOutputs:
 - manifests
 - requiredArtifacts
 - optionalArtifacts
 core:
 bindProducedArtifactsTask:
 excludeKeysFromOutputs:
 - artifacts

tasks:
 clouddriver:
 checkIfApplicationExistsTask:
 checkClouddriver: false # default is true

tasks:
 clouddriver:
 checkIfApplicationExistsTask:
 auditModeEnabled: false # default is true

Front50

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
 name: spinnaker
spec:
 spinnakerConfig:
 profiles:
 front50:
 controller:
 pipeline:
 save:
 refreshCacheOnDuplicatesCheck: false // default is true

Batch update call now responds with a status of succeeded and failed pipelines info. The response will be a map containing information in the following format:

[
 "successful_pipelines_count" : <int>,
 "successful_pipelines" : <List<String>>,
 "failed_pipelines_count" : <int>,
 "failed_pipelines" : <List<Map<String, Object>>>
]

Here the value for successful_pipelines is the list of successful pipeline names whereas the value for failed_pipelines is the list of failed pipelines expressed as maps.

Spinnaker community contributions

Armory CD 2.36.8 tracks the latest published upstream 1.36.x patch line.

Upstream references:

Notable upstream changes:

Clouddriver: improved ECS target-group health evaluation and several AWS/GCP reliability fixes.
Gate/Echo: SAML signing behavior fix and duplicate manual-judgment notification fix.
Clouddriver (Google): async operation retry/status polling to prevent progressing pipeline tasks before cloud operations settle.

Detailed updates

Bill Of Materials (BOM)

Expand to see the BOM


version: 2.36.8
timestamp: 2026-03-05
services:
clouddriver:
version: 2.36.8
commit: 9238966167d0036449c1cf1610d4e40d30a59a95
deck:
version: 2.36.8
commit: 54a2aada8cb187554536daeb8b8b2858714d1afe
dinghy:
version: 2.36.8
commit: d36fdf5b496b18212275686d4c9069d72c9dbeb1
echo:
version: 2.36.8
commit: c7a79f742083c508cd28330814925e8f3906d067
fiat:
version: 2.36.8
commit: e77853e0322014f3b3f8911d9d6f2431830c192c
front50:
version: 2.36.8
commit: 5f8f39172e88b3abe49bab28e2fcb786b8653bf0
gate:
version: 2.36.8
commit: f99a459232f70e19a719a1962f7c6fcee9218750
igor:
version: 2.36.8
commit: 30cab7aaabdfe08c05c37146ab644555cf413513
kayenta:
version: 2.36.8
commit: 2ce818eed3873004412758a0f731cf8420df8594
orca:
version: 2.36.8
commit: 178d4b576e7b8136c42e0baa108cbf2730f6cec8
rosco:
version: 2.36.8
commit: 8e35f1c3560b3b8f7de6fc4a35718b4aee98a47c
terraformer:
version: 2.36.8
commit: 8453d42107fda5f0c315c8459f523e9182805832
monitoring-daemon:
version: 2.26.0
monitoring-third-party:
version: 2.26.0
dependencies:
redis:
version: 2:2.8.4-2
artifactSources:
dockerRegistry: docker.io/armory

Armory

Armory Clouddriver - 2.36.7…2.36.8

fix(validation): URL validation hardening on underscore/authority handling (upstream #7428)
fix(cats-sql): make SqlUnknownAgentCleanupAgent sharding-aware (upstream #7431)
refactor(sharding): pluggable sharding strategy for caching pods (upstream #7432)
feat(scheduler): add Redis priority scheduler (upstream #7433)

Armory Fiat - 2.36.7…2.36.8

Armory Front50 - 2.36.7…2.36.8

Armory Orca - 2.36.7…2.36.8

fix(validation): URL restriction parsing/validation alignment for webhook restrictions (upstream #7428)

Armory Docs – Armory Continuous Deployment

Continuous-Deployment: Cloud Foundry as a Deployment Target in Spinnaker

How Spinnaker interacts with Cloud Foundry

Cloud Foundry as a deployment target

What’s next

Continuous-Deployment: Install Operator and Deploy Armory Continuous Deployment Quickstart

Before you begin

Operator installation options

Install the Operator

Deploy an Armory Continuous Deployment instance

Single manifest file option

Kustomize patches option

Help resources

What’s next

Continuous-Deployment: System Requirements for Armory Continuous Deployment

Installation targets

Browsers

External storage

Bucket storage

RDBMS (SQL)

Hardware requirements

kubectl

Networking

Security

Continuous-Deployment: Air-Gapped with the Armory Operator

Overview

Before you begin

Clone the spinnaker-kustomize-patches repo

Deploy MinIO for storage

Download the BOM

Copy the BOM

Host the Armory Continuous Deployment Docker images

Proxy to docker.io/armory

Download images

Download the Armory Operator

Host the Armory Operator Docker images

Update Armory Operator configuration

Update MinIO secret access key

Update Halyard configuration

Deploy the Armory Operator

Help resources

What’s next

Continuous-Deployment: Armory Config

spec.spinnakerConfig.config.armory

Dinghy parameters

Diagnostics parameters

Armory Terraform parameters

Secrets parameters

Kustomize patch examples

Continuous-Deployment: Artifact Config

spec.spinnakerConfig.config.artifacts

Bitbucket

Account parameters

GCS

Account parameters

GitHub

Account parameters

GitLab

Account parameters

GitRepo

Account parameters

Helm

Account parameters

HTTPS

Account parameters

Maven

Account parameters

Oracle

Account parameters

S3

Account parameters

Templates

Continuous-Deployment: AWS QuickStart Step 1

Note

Prerequisites

Prepare AWS by creating Roles, Permissions, and Trust

In this step, we configure 2 AWS Roles to enable Spinnaker to deploy to your AWS environment

Bind “Spinnaker-Managing-Role” to Minnaker Instance in AWS Console

Login to your Minnaker EC2 Instance with SSH (Outside of Halyard Container)

Verify Roles are configured correctly

Clone the `spinnaker-kustomize-patches` repo

Proxy to `docker.io/armory`

Set up an Ingress for `spin-deck` and `spin-gate`