Spinnaker – Cloud Providers Overview

Docs: Amazon Web Services

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

AWS Compute with the Spinnaker AWS Cloud Provider

The AWS Cloud Provider allows Spinnaker to release artifacts in some of the AWS compute services

There are several ways to configure the Amazon Web Services (AWS) Cloud Provider. Choose one or more based on your requirements:

Amazon Elastic Compute Cloud (EC2) - - Use this option, if you want to manage AWS EC2 via Spinnaker
Amazon Elastic Container Service (ECS) - - Use this option, if you want to manage containers in AWS ECS
Amazon Elastic Kubernetes Service (EKS) - Use this option, if you want to manage containers in AWS EKS . This option uses Kubernetes V2 (manifest based) Clouddriver
Amazon Lambda (Lambda) - Use this option, if you want to enable AWS Lambda support

AWS IAM Permissions with the AWS Cloud Provider

AWS controls the permissions with AWS IAM Identity Access Management. Spinnaker functionality with AWS requires an AWS IAM structure to be ready in the AWS target accounts.

There are two types of Accounts in the Spinnaker AWS provider: AWS Managing account and AWS Managed account(s).

Spinnaker is considered to be the AWS Managing account which then deploys into the AWS Managed account(s).

Note The AWS IAM structure must be set up prior to adding AWS accounts.

From the AWS perspective, AWS Managing account deploys into the AWS Managed account(s) through the use of AWS IAM Roles. By assuming a role across AWS Accounts, Spinnaker can control AWS resources from multiple AWS Managed accounts. Spinnaker when an account is added will start querying information in those accounts to show information on the UI as well as cache information to reduce API calls.

Refer to AWS IAM Providing Access to multiple AWS Accounts for AWS technical details.

AWS Managing account. There is always exactly one managing account. This account is what Spinnaker authenticates as and, if necessary, uses to assumes roles in the managed account(s).
AWS Managed. Every AWS account that you want to modify resources in is a managed account. Managed accounts require AWS IAM policies and a trust relationship to grant AssumeRole access to the managed account(s).

The AWS Managing account assumes the roles of the AWS Managed account(s).

Example: AWS Managing account spinnakermanaging can assume the Managed role in the accounts accountdev, accountstaging, accountprod and deploy a baked AMI in the pipeline.

Additional documentation

Armory (now harness) has docs available here: https://docs.armory.io/continuous-deployment/spinnaker-user-guides/aws-guides/

Docs: Kubernetes V2 Provider

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

Spinnaker’s Kubernetes provider fully supports Kubernetes-native, manifest-based deployments and is the recommended provider for deploying to Kubernetes with Spinnaker.

Accounts

A Spinnaker Account maps to a credential that can authenticate against your Kubernetes Cluster.

Prerequisites

The Kubernetes provider has two requirements:

A kubeconfig file

The kubeconfig file allows Spinnaker to authenticate against your cluster and to have read/write access to any resources you expect it to manage. You can think of it as private key file to let Spinnaker connect to your cluster. You can request this from your Kubernetes cluster administrator.
kubectl CLI tool

Spinnaker relies on kubectl to manage all API access. It’s installed along with Spinnaker.

Spinnaker also relies on kubectl to access your Kubernetes cluster; only kubectl fully supports many aspects of the Kubernetes API, such as 3-way merges on kubectl apply, and API discovery. Though this creates a dependency on a binary, the good news is that any authentication method or API resource that kubectl supports is also supported by Spinnaker. This is an improvement over the original Kubernetes provider in Spinnaker.

Optional: Create a Kubernetes Service Account

If you want, you can associate Spinnaker with a Kubernetes Service Account , even when managing multiple Kubernetes clusters. This can be useful if you need to grant Spinnaker certain roles in the cluster later on, or you typically depend on an authentication mechanism that doesn’t work in all environments.

Given that you want to create a Service Account in existing context $CONTEXT, the following commands will create spinnaker-service-account, and add its token under a new user called ${CONTEXT}-token-user in context $CONTEXT.

CONTEXT=$(kubectl config current-context)

# This service account uses the ClusterAdmin role -- this is not necessary,
# more restrictive roles can by applied.
kubectl apply --context $CONTEXT \
    -f https://deploy-preview-629--spinnaker-io.netlify.appdownloads/kubernetes/service-account.yml


TOKEN=$(kubectl get secret --context $CONTEXT \
   $(kubectl get serviceaccount spinnaker-service-account \
       --context $CONTEXT \
       -n spinnaker \
       -o jsonpath='{.secrets[0].name}') \
   -n spinnaker \
   -o jsonpath='{.data.token}' | base64 --decode)

kubectl config set-credentials ${CONTEXT}-token-user --token $TOKEN

kubectl config set-context $CONTEXT --user ${CONTEXT}-token-user

Optional: Configure Kubernetes roles (RBAC)

If your Kubernetes cluster supports RBAC and you want to restrict permissions granted to your Spinnaker account, you will need to follow the below instructions.

The following YAML creates the correct ClusterRole, ClusterRoleBinding, and ServiceAccount. If you limit Spinnaker to operating on an explicit list of namespaces (using the namespaces option), you need to use Role and RoleBinding instead of ClusterRole and ClusterRoleBinding, and apply the Role and RoleBinding to each namespace Spinnaker manages. You can read about the difference between ClusterRole and Role in the Kubernetes docs . If you’re using RBAC to restrict the Spinnaker service account to a particular namespace, you must specify that namespace when you add the account to Spinnaker. If you don’t specify any namespaces, then Spinnaker will attempt to list all namespaces, which requires a cluster-wide role.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: spinnaker-role
rules:
  - apiGroups: [ '' ]
    resources:
      [
        'namespaces',
        'configmaps',
        'events',
        'replicationcontrollers',
        'serviceaccounts',
        'pods/log',
      ]
    verbs: [ 'get', 'list' ]
  - apiGroups: [ '' ]
    resources: [ 'pods', 'services', 'secrets' ]
    verbs:
      [
        'create',
        'delete',
        'deletecollection',
        'get',
        'list',
        'patch',
        'update',
        'watch',
      ]
  - apiGroups: [ 'autoscaling' ]
    resources: [ 'horizontalpodautoscalers' ]
    verbs: [ 'list', 'get' ]
  - apiGroups: [ 'apps' ]
    resources: [ 'controllerrevisions' ]
    verbs: [ 'list' ]
  - apiGroups: [ 'extensions', 'apps' ]
    resources: [ 'daemonsets', 'deployments', 'deployments/scale', 'ingresses', 'replicasets', 'statefulsets' ]
    verbs:
      [
        'create',
        'delete',
        'deletecollection',
        'get',
        'list',
        'patch',
        'update',
        'watch',
      ]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: spinnaker-role-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: spinnaker-role
subjects:
  - namespace: spinnaker
    kind: ServiceAccount
    name: spinnaker-service-account
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: spinnaker-service-account
  namespace: spinnaker

Adding an account

Add the following config to clouddriver-local.yml

kubernetes:
  enabled: true
  loadNamespacesInAccount: false
  verifyAccountHealth: false
  accounts:
    - name: k8s-example
      kubeconfigFile: /mnt/configs/k8s-example-kubeconfig
      kubectlExecutable: kubectl-1.29
      cacheIntervalSeconds: 60
      namespaces:
        - spinnaker
      permissions:
        READ:
          - everyone
          - engineering-managed
        WRITE:
          - everyone
          - engineering-managed

Finally, enable artifact support .

Advanced account settings

If you’re looking for more configurability, please see the code for a kubernetes account definition

Docs: Azure

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

In Azure , an Account maps to a credential able to authenticate against a given Azure subscription .

Prerequisites

You need a Service Principal to authenticate with Azure and a Key Vault to store a default username/ssh public key for deployed VM Scale Sets . The next steps assume the use of the Azure CLI 2.0 . The example commands will set environment variables along the way for use when creating an account in the final stage. You can check that you have az installed by running:

az --version

First, log in and set your subscription:

az login
az account list
SUBSCRIPTION_ID=<Insert Subscription ID>
az account set --subscription $SUBSCRIPTION_ID

Next, create a Service Principal (where the name is unique in your subscription) and set environment variables based on the output:

az ad sp create-for-rbac --name "Spinnaker" --role contributor --scopes /subscriptions/${SUBSCRIPTION_ID}
APP_ID=<Insert App Id>
TENANT_ID=<Insert Tenant Id>

NOTE: You will need the App Key (also called password) when creating an account, but you will be prompted on standard input for that since it is sensitive data.

Next, create a resource group for your Key Vault. Make sure to specify a location (e.g. westus) available in your account:

az account list-locations --query [].name
RESOURCE_GROUP="Spinnaker"
az group create --name $RESOURCE_GROUP --location <Insert Location>

Finally, create a Key Vault (where the vault name is globally unique) and add a default username/ssh public key. This credential is used to provision all Azure VM scale sets by default. You can log on to VM instances in VM scale sets with this credential.

VAULT_NAME=<Insert Vault Name>
az keyvault create --enabled-for-template-deployment true --resource-group $RESOURCE_GROUP --name $VAULT_NAME
az keyvault set-policy --secret-permissions get --name $VAULT_NAME --spn $APP_ID
az keyvault secret set --name VMUsername --vault-name $VAULT_NAME --value <Insert default username>
az keyvault secret set --name VMSshPublicKey --vault-name $VAULT_NAME --value <Insert default SSH public key>

If you prefer to use password instead of SSH public key, then replace

az keyvault secret set --name VMSshPublicKey --vault-name $VAULT_NAME --value <Insert default SSH public key>

with

az keyvault secret set --name VMPassword --vault-name $VAULT_NAME --value <Insert default password>

Follow the Azure VM username and password rules documented here .

Adding an account

Enable azure and add the azure account to clouddriver-local.yml

azure:
  enabled: true
  accounts:
    - name: my-azure-account
      clientId: replaceMeWithAppId
      tenant-id: replaceMeWithTenantId
      subscriptionId: replaceMeWithSubscriptId
      defaultKeyValue: replaceMeWithVaultName
      defaultResourceGroup: replaceMeWithResourceGroup
      packerResourceGroup: replaceMeWithResourceGroup
      useSshPublicKey: true
      appKey: 
      regions:
      - regionname

NOTE:

You will be prompted for the App Key on standard input. If necessary, you can generate a new key: az ad sp credential reset --name $APP_ID

SSH public key will be used to provision VM scale set by default. If you prefer to use password, change the flag for this as so: useSshPublicKey: false. Secret values of either the SSH public key or password are stored in the Azure key vault specified by the property defaultKeyVault, in which the stored secret names are called “VMPassword” and “VMSshPublicKey”, separately.

The Azure regions used by default are “eastus” and “westus”. If you would like to add custom regions, adjust the property
regions per the above

Advanced account settings

For a full list of account properties, see the AzureConfigurationProperties class.

Next steps

Optionally, you can set up another cloud provider or continue the installation instructions

Docs: Cloud Foundry

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

In Cloud Foundry (CF), an Account maps to a user account on a CF foundation (a BOSH Director and all the VMs it deploys). You can add multiple accounts for one or more CF foundations.

Prerequisites

Your CF foundations’ API endpoints must be reachable from your installation of Spinnaker.

Add an account

First, make sure that the provider is enabled and add an account named my-cf-account to the clouddriver list of Cloud Foundry accounts: in ~/spinnaker-kustomize/overlays/config/files/clouddriver-local.yml

cloudfoundry:
  enabled: true
  accounts:
    - name: my-cf-account
      api: api.sys.endpoint.for.foundation
      user: username
      password: password
      environment: whatever
      appsManagerUrl: http://apps.sys.endpoint.for.foundation
      metricsUrl: http://metrics.sys.endpoint.for.foundation
      skipSslValidation: true|false
      ## ONLY caches things spinnaker has deployed when true
      onlySpinnakerManaged: true

NOTE: skipSslValidation: true may be necessary when adding an account with a CF API endpoint using a self-signed SSL certificate or a certificate issued by an internal certificate authority. Turning this on will generate a warning.

Next steps

Optionally, you can set up another cloud provider or continue the installation instructions

Docs: Docker Registry

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

:warning: This only acts as a source of images, and does not include support for deploying Docker images.

When configuring Docker Registries, an Account maps to a credential able to authenticate against a certain set of Docker repositories .

Prerequisites

The Docker Registry you are configuring must already exist.
That Registry must support the v2 registry API . OCI registries are ALSO supported at this time.

Registry providers

You can set up a Docker Registry provider for Spinnaker using any of the repositories listed here. Each one supports the same API, but there are subtle differences in how to get them to work with Spinnaker.

DockerHub

The DockerHub registry address is index.docker.io, keep track of this for later:

ADDRESS=index.docker.io

Dockerhub hosts a mix of public and private repositories, but does not expose a catalog endpoint to programmatically list them. Therefore you need to explicitly list which Docker repositories you want to index and deploy. For example, if you wanted to deploy the public NGINX image, alongside your private app image, your list of repositories would look like:

REPOSITORIES=library/nginx yourusername/app

NOTE: Keep in mind that the repository name is typically either prefixed with library/ for most public images, or <username>/ for images belonging to user <username>/.

If any of your images aren’t publicly available, make sure you know your DockerHub username & password to supply to hal later:

USERNAME=yourusername
PASSWORD=hunter2

GitHub Container Registry

To note since GitHub does NOT expose a catalog endpoint you MUST explicitly define which repositories you want to be cached here. You can deploy other images, just be aware that spinnaker won’t cache, trigger or show those in the dropdowns UNLESS you’ve added them below.

docker-registry:
  enabled: true
  accounts:
  - name: docker-ghcr-jasonmcintosh
    address: https://ghcr.io/
    username: jasonmcintosh
    password: encrypted:s3!n:artifact-creds!k:githubPatToken
    repositories:
    - jasonmcintosh/spinnaker-work/demo-web-app

Google Artifact Registry

Set the registry address.

The GAR typical address for an image is [LOCATION]-docker.pkg.dev/[PROJECT-ID]/[REPOSITORY], but see google docs for more information on the appropriate URLs. You’ll typically use the location-docker.pkg.dev for API calls due to how the docker APIs are setup.
Enable access to the catalog endpoint

Make sure you have setup auth with these permissions if you want to use the catalog endpoint to programmatically list all images available to your credentials, so you don’t have supply repositories manually for cache purposes.

Setting up a service account is the preferred way to authenticate to GAR. Please read the google docs for the appropriate commands

NOTE That GAR uses OCI compliant APIs and as such, operates a bit differently than standard docker registries.
Enable the provider and add the account by adding to clouddriver-local.yml the following

artifacts:
  helm-oci:
    clone-retention-minutes: 60
dockerRegistry:
  enabled: true
  primaryAccount: gar-registry   # Must be one of the configured docker accounts
  accounts:
    - name: gar-registry
      requiredGroupMembership: [ ]
      providerVersion: V1
      permissions: { }
      address: https://us-docker.pkg.dev
      username: example
      passwordFile: /mnt/secrets/secret-entry.json
      #passwordCommand: 
      cacheIntervalSeconds: 30
      clientTimeoutMillis: 60000
      cacheThreads: 1
      paginateSize: 100
      sortTagsByDate: false
      trackDigests: false
      insecureRegistry: false
      helmOciRepositories:
        - "spinnaker-community/docker/clouddriver"

Amazon Elastic Container Registry (ECR)

Get the registry address.

ECR registry addresses are specific to an AWS account and region. You can retrieve the address from the ECR console, or with aws ecr describe-repositories. An example:
```
ADDRESS=012345678910.dkr.ecr.us-east-1.amazonaws.com
REGION=us-east-1
```
Set up authentication.

The Spinnaker instance running the Clouddriver service will be doing the queries to these accounts. As such you’ll need to grant the role that spinnaker runs as permissions to interact with the ECR repository. Attach the AmazonEC2ContainerRegistryReadOnly managed policy to the IAM role/user for your Spinnaker installation. For example,
```
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly --role-name SpinnakerRole
```
or:
```
aws iam attach-user-policy --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly --user-name spinnaker
```
Enable the provider and add the account

dockerRegistry:
  enabled: true
  primaryAccount: ecr-registry   # Must be one of the configured docker accounts
  accounts:
    - name: ecr-registry
      requiredGroupMembership:
      providerVersion: V1
      address: 012345678910.dkr.ecr.us-east-1.amazonaws.com
      username: AWS
      passwordCommand: "aws --region us-east-2 ecr get-authorization-token --output text --query 'authorizationData[].authorizationToken' | base64 -d | sed 's/^AWS://'"

Other registries

Most registries fit either the Dockerhub or GCR pattern described above, or some mix of the two. In all cases you need to know the FQDN of the registry, and your username/password pair if you are accessing private images. If your registry supports the <code>/_catalog</code> endpoint you do not have to list your repositories. If it does not, keep in mind that the repository names are generally of the form <username>/<image name>.

Registry	FQDN	Catalog
GAR	`location`-docker.pkg.dev	Yes
DockerHub	index.docker.io	No
Quay	quay.io	Yes
ECR	`account-id`.dkr.ecr.`region`.amazon.aws.com	Yes
JFrog Artifactory	`server`-`repo`.jfrog.io	?
ghcr	ghcr.io	no

Add the account

You can add any other compliant OCI or Docker registry by adding entries similar to the above examples by changing the username, password/passwordCommand, URLs and repositories as needed.

Advanced Account Settings

If you are looking for more configurability, please see the other options listed in the Docker account properties .

Next Steps

Optionally, you can set up another cloud provider or continue the installation instructions

Docs: Google App Engine

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

In Google App Engine , an Account maps to a credential able to authenticate against a given Google Cloud Platform project.

Prerequisites

You need a Google Cloud Platform project to run Spinnaker against. The next steps assume you’ve already created a project , and installed gcloud . You can check that gcloud is installed and authenticated by running:

gcloud info

If this is your first time deploying to App Engine in your project, create an App Engine application. You cannot change your application’s region, so pick wisely:

gcloud app create --region <e.g., us-central>

You will also need to enable the App Engine Admin API for your project:

gcloud services enable appengine.googleapis.com

Downloading credentials

Spinnaker does not need to be given service account credentials if it is running on a Google Compute Engine VM whose application default credentials have sufficient scopes to deploy to App Engine and Spinnaker is deploying to an App Engine application inside the same Google Cloud Platform project in which it is running. If Spinnaker will not need to be given service account credentials, or if you already have such a service account with the corresponding JSON key downloaded, skip ahead to Adding an Account .

Run the following commands to create a service account with the roles/appengine.appAdmin and roles/storage.admin roles enabled:

SERVICE_ACCOUNT_NAME=spinnaker-appengine-account
SERVICE_ACCOUNT_DEST=~/.gcp/appengine-account.json

gcloud iam service-accounts create \
    $SERVICE_ACCOUNT_NAME \
    --display-name $SERVICE_ACCOUNT_NAME

SA_EMAIL=$(gcloud iam service-accounts list \
    --filter="displayName:$SERVICE_ACCOUNT_NAME" \
    --format='value(email)')

PROJECT=$(gcloud config get-value project)

gcloud projects add-iam-policy-binding $PROJECT \
    --role roles/storage.admin \
    --member serviceAccount:$SA_EMAIL

gcloud projects add-iam-policy-binding $PROJECT \
    --role roles/appengine.appAdmin \
    --member serviceAccount:$SA_EMAIL

mkdir -p $(dirname $SERVICE_ACCOUNT_DEST)

gcloud iam service-accounts keys create $SERVICE_ACCOUNT_DEST \
    --iam-account $SA_EMAIL

Your service account JSON key now sits inside $SERVICE_ACCOUNT_DEST.

Adding an account

First, make sure that the provider is enabled:

hal config provider appengine enable

Next, run the following hal command to add an account named my-appengine-account to your list of App Engine accounts:

hal config provider appengine account add my-appengine-account \
  --project $PROJECT \
  --json-path $SERVICE_ACCOUNT_DEST

You can omit the --json-path flag if Spinnaker does not need service account credentials.

Deploying to App Engine

Deploying from Git

Spinnaker supports deploying your source code to App Engine by cloning your application’s git repository and submitting it to App Engine. Unless your code is public, Spinnaker needs a mechanism to authenticate with your repositories - many of the configuration flags for App Engine manage this authentication.

You can view the available configuration properties for App Engine within the codebase.

Deploying from storage

Much like deploying from Git, Spinnaker also supports deploying your source code to App Engine from a Google Cloud Storage bucket. This method of deploying requires you to bundle your code into a .tar archive and then store that on GCS. When the deploy stage executes, Spinnaker will fetch your tar archive, untar it, and then deploy the code to App Engine.

Deploying from Google Container Registry URL

Spinnaker supports deploying Docker containers on the App Engine Flex runtime from images built and stored in Google Container Registry from just a gcr.io URL.

You’ll find an option in the Create Server Group dialog in Deck to use a Container Image as a deployment’s Source Type. Selecting the Container Image option reveals a textbox that can then be used to specify the gcr.io URL. Alternatively you can use an Artifact as the source of the container image URL.

Next steps

Optionally, you can set up another cloud provider , or continue the installation instructions

Docs: Google Cloud Run

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

In Google Cloud Run , an Account maps to a credential able to authenticate against a given Google Cloud Platform project.

Prerequisites

gcloud info

To initialize the gcloud CLI, run the following command:

gcloud init

If this is your first time deploying to Cloud Run in your project, create a Cloud Run application.

To set the default project for your Cloud Run service:

gcloud config set project <PROJECT_ID>

NOTE: Replace PROJECT_ID with the name of the project you created.

Enable the Cloud Run Admin API:

gcloud services enable run.googleapis.com

For Cloud Build to be able to build your sources, grant the Cloud Build Service Account role to the Compute Engine default service account by running the following:

gcloud projects add-iam-policy-binding <PROJECT_ID> \
    --member=serviceAccount:<PROJECT_NUMBER>-compute@developer.gserviceaccount.com \
    --role=roles/cloudbuild.builds.builder

NOTE: Replace PROJECT_NUMBER with your Google Cloud project number, and PROJECT_ID with your Google Cloud project ID.

Downloading credentials

Spinnaker does not need to be given service account credentials if it is running on a Google Compute Engine VM whose application default credentials have sufficient scopes to deploy to Cloud Run and Spinnaker is deploying to an Cloud Run application inside the same Google Cloud Platform project in which it is running. If Spinnaker does not need to be given service account credentials, or if you already have such a service account with the corresponding JSON key downloaded, skip ahead to Adding an Account .

Run the following commands to create a service account with the roles/run.admin and roles/storage.admin roles enabled:

SERVICE_ACCOUNT_NAME=spinnaker-cloudrun-account
SERVICE_ACCOUNT_DEST=~/.gcp/cloudrun-account.json

gcloud iam service-accounts create \
    $SERVICE_ACCOUNT_NAME \
    --display-name $SERVICE_ACCOUNT_NAME

SA_EMAIL=$(gcloud iam service-accounts list \
    --filter="displayName:$SERVICE_ACCOUNT_NAME" \
    --format='value(email)')

PROJECT=$(gcloud config get-value project)

gcloud projects add-iam-policy-binding $PROJECT \
    --role roles/storage.admin \
    --member serviceAccount:$SA_EMAIL

gcloud projects add-iam-policy-binding $PROJECT \
    --role roles/run.admin \
    --member serviceAccount:$SA_EMAIL

mkdir -p $(dirname $SERVICE_ACCOUNT_DEST)

gcloud iam service-accounts keys create $SERVICE_ACCOUNT_DEST \
    --iam-account $SA_EMAIL

Your service account JSON key now sits inside $SERVICE_ACCOUNT_DEST.

Adding an account

First, make sure that the provider is enabled and add an account to clouddriver:

cloudrun:
  enabled: true
  accounts:
  - name: my-cloudrun-account
    project: replaceMe
    json-path: serviceAccountDestFileFromConfigMap

You can omit the --json-path flag if Spinnaker does not need service account credentials.

Deploying to Cloud Run

Deploying from Git

Spinnaker supports deploying your source code to Cloud Run by cloning your application’s git repository and submitting it to Cloud Run. Unless your code is public, Spinnaker needs a mechanism to authenticate with your repositories - many of the configuration flags for Cloud Run manage this authentication.

You can view the available configuration flags for Cloud Run within the cloudrun account credentials properties code

Deploying from storage

Much like deploying from Git, Spinnaker also supports deploying your source code to Cloud Run from a Google Cloud Storage bucket. This method of deploying requires you to bundle your code into a .tar archive and then store that on GCS. When the deploy stage executes, Spinnaker will fetch your tar archive, untar it, and then deploy the code to Cloud Run.

Deploying from Google Container Registry URL

Spinnaker supports deploying Docker containers on the Cloud Run runtime from images built and stored in Google Container Registry from just a gcr.io URL.

Next steps

Optionally, you can set up another cloud provider or continue the installation instructions

Docs: Google Compute Engine

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

In Google Compute Engine (GCE), an Account maps to a credential able to authenticate against a given Google Cloud Platform (GCP) project.

Prerequisites

You need a Google Cloud Platform (GCP) project to run Spinnaker against. The next steps assume you’ve already created a project , and installed gcloud . You can check that gcloud is installed and authenticated by running:

gcloud info

Downloading credentials

Spinnaker needs a service account to authenticate as against GCE, with the role enumerated below enabled. If you don’t already have such a service account with the corresponding JSON key downloaded, you can run the following commands to do so:

SERVICE_ACCOUNT_NAME=spinnaker-gce-account
SERVICE_ACCOUNT_DEST=~/.gcp/gce-account.json

gcloud iam service-accounts create \
    $SERVICE_ACCOUNT_NAME \
    --display-name $SERVICE_ACCOUNT_NAME

SA_EMAIL=$(gcloud iam service-accounts list \
    --filter="displayName:$SERVICE_ACCOUNT_NAME" \
    --format='value(email)')

PROJECT=$(gcloud config get-value project)

# permission to create/modify instances in your project
gcloud projects add-iam-policy-binding $PROJECT \
    --member serviceAccount:$SA_EMAIL \
    --role roles/compute.instanceAdmin

# permission to create/modify network settings in your project
gcloud projects add-iam-policy-binding $PROJECT \
    --member serviceAccount:$SA_EMAIL \
    --role roles/compute.networkAdmin

# permission to create/modify firewall rules in your project
gcloud projects add-iam-policy-binding $PROJECT \
    --member serviceAccount:$SA_EMAIL \
    --role roles/compute.securityAdmin

# permission to create/modify images & disks in your project
gcloud projects add-iam-policy-binding $PROJECT \
    --member serviceAccount:$SA_EMAIL \
    --role roles/compute.storageAdmin

# permission to download service account keys in your project
# this is needed by packer to bake GCE images remotely
gcloud projects add-iam-policy-binding $PROJECT \
    --member serviceAccount:$SA_EMAIL \
    --role roles/iam.serviceAccountActor

mkdir -p $(dirname $SERVICE_ACCOUNT_DEST)

gcloud iam service-accounts keys create $SERVICE_ACCOUNT_DEST \
    --iam-account $SA_EMAIL

Once you have run these commands, your GCP JSON key is sitting in a file called $SERVICE_ACCOUNT_DEST.

Adding an Account

Get the following values (we’ve provided defaults for you):

PROJECT=$(gcloud config get-value project)
SERVICE_ACCOUNT_DEST=# see Prerequisites section above

Add your new google account and enable google:

google:
  enabled: true
  accounts:
    - name: account-name
      project: replaceMe
      jsonPath: /mnt/configmap/file.json

Advanced account settings

More account configuration properties can be found in the codebase for the google account . This code is actually extended with MORE options here: https://github.com/spinnaker/spinnaker/blob/main/clouddriver/clouddriver-google/src/main/groovy/com/netflix/spinnaker/clouddriver/google/config/GoogleConfigurationProperties.groovy#L44

It’s recommended with large numbers of accounts to disable verification and check logs for account access healthy by setting:

google:
  health:
    verifyAccountHealth: false

Next steps

Optionally, you can set up another cloud provider or continue the installation instructions

Docs: Oracle

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

In Oracle Cloud , a Spinnaker Account maps to an Oracle Cloud Infrastructure user .

Prerequisites

You will need the following to enable Oracle Cloud provider in Spinnaker:

A user in IAM for the person or system who will be using Spinnaker, and put that user in at least one IAM group with any desired permissions. See Adding Users .
The user’s home region. See Managing Regions . (e.g. --region us-ashburn-1)
RSA key pair in PEM format (minimum 2048 bits). See How to Generate an API Signing Key . (e.g. --ssh-private-key-file-path /home/ubuntu/.oci/myPrivateKey.pem)
Fingerprint of the public key. See How to Get the Fingerprint of the Key . (e.g. --fingerprint 11:22:33:..:aa)
Tenancy’s OCID and user’s OCID. See Where to Get the Tenancy and User OCIDs . (e.g. --tenancyId ocid1.tenancy.oc1..aa... --user-id ocid1.user.oc1..aa...)
Compartment OCID: On Oracle Cloud Console, open the navigation menu. Under Governance and Administration, go to Identity and click Compartments. See Managing Compartments . (e.g. --compartment-id ocid1.compartment.oc1..aa...)
Upload the public key from the key pair in the Console. See How to Upload the Public Key .

Add an Oracle Cloud account

Enable the Oracle Cloud provider and add the account

oracle:
  enabled: true
  accounts:
  - name: my-oci-acct
    compartment-id: ocid1.compartment.oc1..aaaaaaaatjuwhxwkspkxhumqke4o73b2b
    fingerprint: 8f:05:f4:94:f3:5f:e3:30:ec:35 
    region: us-phoenix-1
    ssh-private-key-file-path: /mnt/secrets/oci_api_key.pem
    tenancyId: ocid1.tenancy.oc1..aaaaaaaa225wmphohi3iiyxxxjruo
    userId: ocid1.user.oc1..aaaaaaaagosdr3zsh67tvgpnmw42ywqc

Next steps

Optionally, you can set up another cloud provider or continue the installation instructions