Flux – Flux bootstrap

Flux: Flux bootstrap for Git servers

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

The flux bootstrap git command deploys the Flux controllers on a Kubernetes cluster and configures the controllers to sync the cluster state from a Git repository. Besides installing the controllers, the bootstrap command pushes the Flux manifests to the Git repository and configures Flux to update itself from Git.

After running the bootstrap command, any operation on the cluster (including Flux upgrades) can be done via Git push, without the need to connect to the Kubernetes cluster.

Required permissions

To bootstrap Flux, the person running the command must have cluster admin rights for the target Kubernetes cluster. It is also required that the person running the command has push rights to the Git repository.

SSH Private Key

Run bootstrap for an existing Git repository and authenticate with a SSH key which has pull and push access:

flux bootstrap git \
 --url=ssh://git@<host>/<org>/<repository> \
 --branch=main \
 --private-key-file=<path/to/private.key> \
 --password=<key-passphrase> \
 --path=clusters/my-cluster

The private key is stored in the cluster as a Kubernetes secret named flux-system inside the flux-system namespace.

SSH Key rotation

To regenerate the SSH private key and known hosts keys, delete the flux-system secret from the cluster and run:

flux create secret git flux-system \
 --url=ssh://git@<host>/<org>/<repository> \
 --private-key-file=<path/to/private.key> \
 --password=<key-passphrase>

SSH Agent

Run bootstrap for an existing Git repository and authenticate with your SSH agent:

flux bootstrap git \
 --url=ssh://git@<host>/<org>/<repository> \
 --branch=main \
 --path=clusters/my-cluster

SSH hostname

If the Flux controllers must connect to a different SSH endpoint than the CLI, you can set the SSH hostname and port for the cluster with --ssh-hostname=<host:port>. Note that if set, your SSH hostname and port could be overwritten by your ssh_config.

When using the SSH Agent, the bootstrap command will generate a new SSH private key for the cluster, and it will prompt you to add the SSH public key as a deploy key to your repository.

The generated SSH key defaults to ECDSA P-384, to change the format use --ssh-key-algorithm and --ssh-ecdsa-curve.

SSH Key rotation

To regenerate the SSH private key and known hosts keys, delete the flux-system secret from the cluster and run:

flux create secret git flux-system \
 --url=ssh://git@<host>/<org>/<repository> \
 --ssh-key-algorithm=ecdsa \
 --ssh-ecdsa-curve=p384

The CLI will prompt you to add the SSH public key as a deploy key to your repository.

HTTPS basic auth

If your Git server has basic auth enabled, you can bootstrap Flux over HTTPS with:

flux bootstrap git \
 --url=https://<host>/<org>/<repository> \
 --username=<my-username> \
 --password=<my-password> \
 --token-auth=true \
 --path=clusters/my-cluster

You can also supply the password or Git token using a pipe e.g. echo "<my-pass>" | flux bootstrap git.

If your Git server uses a self-signed TLS certificate, you can specify the CA file with --ca-file=<path/to/ca.crt>.

HTTPS authorization header

To access Git repositories that require a bearer token in the HTTP headers as an Authorization header such as Oracle VBS Git Repositories:

flux bootstrap git \
 --url=https://<host>/<org>/<repository> \
 --password=<Access Token> \
 --with-bearer-token \
 --path=clusters/my-cluster

If your Git server uses a self-signed TLS certificate, you can specify the CA file with --ca-file=<path/to/ca.crt>.

Bootstrap multiple clusters

With --path you can configure the directory which will be used to reconcile the target cluster. To control multiple clusters from the same Git repository, you have to set a unique path per cluster e.g. clusters/staging and clusters/production:

./clusters/
├── staging # <- path=clusters/staging
│   └── flux-system # <- namespace dir generated by bootstrap
│   ├── gotk-components.yaml
│   ├── gotk-sync.yaml
│   └── kustomization.yaml
└── production # <- path=clusters/production
 └── flux-system

Bootstrap options

There are many options available when bootstrapping Flux, such as installing a subset of Flux components, setting the Kubernetes context, changing the Git author name and email, enabling Git submodules, and more. To list all the available options run flux bootstrap git --help.

Flux: Flux bootstrap for Gitea

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

The flux bootstrap gitea command deploys the Flux controllers on a Kubernetes cluster and configures the controllers to sync the cluster state from a Gitea repository. Besides installing the controllers, the bootstrap command pushes the Flux manifests to the Gitea repository and configures Flux to update itself from Gitea.

After running the bootstrap command, any operation on the cluster (including Flux upgrades) can be done via Git push, without the need to connect to the Kubernetes cluster.

Required permissions

To bootstrap Flux, the person running the command must have cluster admin rights for the target Kubernetes cluster. It is also required that the person running the command to be the owner of the Gitea repository, or to have admin rights of a Gitea organization.

Forgejo support

Forgejo is a fork of Gitea (see their Comparison with Gitea). Given that Forgejo is mainly backward compatible with Gitea, you can use the same commands that you use for Gitea and it will work.

Gitea PAT

For accessing the Gitea API, the bootstrap command requires a Gitea personal access token (PAT) with the following permissions:

read:misc
write:repository

If you want Flux to to create a new personal repository with Flux the following permissions are necessary:

read:misc
write:repository
write:user

If you want Flux to to create a new organization repository with Flux the following permissions are necessary:

read:misc
write:organization
write:repository

The Gitea PAT can be exported as an environment variable:

export GITEA_TOKEN=<gt-token>

If the GITEA_TOKEN env var is not set, the bootstrap command will prompt you to type it the token.

You can also supply the token using a pipe e.g. echo "<gt-token>" | flux bootstrap gitea.

Gitea Personal Account

Run the bootstrap for a repository on your personal Gitea account:

flux bootstrap gitea \
 --token-auth \
 --owner=my-gitea-username \
 --repository=my-repository-name \
 --branch=main \
 --path=clusters/my-cluster \
 --personal

If the specified repository does not exist, Flux will create it for you as private. If you wish to create a public repository, set --private=false.

When using --token-auth, the CLI and the Flux controllers running on the cluster will use the Gitea PAT to access the Git repository over HTTPS.

PAT secret

Note that the Gitea PAT is stored in the cluster as a Kubernetes Secret named flux-system inside the flux-system namespace. If you want to avoid storing your PAT in the cluster, please see how to configure Gitea Deploy Keys.

Gitea Organization

If you want to bootstrap Flux for a repository owned by a Gitea organization, it is recommended to create a dedicated user for Flux under your organization.

Run the bootstrap for a repository owned by a Gitea organization:

flux bootstrap gitea \
 `--token-auth` \
 --owner=my-gitea-organization \
 --repository=my-repository \
 --branch=main \
 --path=clusters/my-cluster

Gitea Deploy Keys

If you want to bootstrap Flux using SSH instead of HTTP/S, you can set --token-auth=false and the Flux CLI will use the Gitea PAT to set a deploy key for your repository.

When using SSH, the bootstrap command will generate a SSH private key. The private key is stored in the cluster as a Kubernetes secret named flux-system inside the flux-system namespace.

The generated SSH key defaults to ECDSA P-384, to change the format use --ssh-key-algorithm and --ssh-ecdsa-curve.

The SSH public key, is used to create a Gitea deploy key. The deploy key is linked to the personal access token used to authenticate.

By default, the Gitea deploy key is set to read-only access. If you’re using Flux image automation, you must give it write access with --read-write-key=true.

Deploy Key rotation

Note that when the PAT is removed or when it expires, the Gitea deploy key will stop working. To regenerate the deploy key, delete the flux-system secret from the cluster and re-run the bootstrap command using a valid Gitea PAT.

Bootstrap without a Gitea PAT

For existing Gitea repositories, you can bootstrap Flux over SSH without using a Gitea PAT.

To use a SSH key instead of a Gitea PAT, the command changes to flux bootstrap git:

flux bootstrap git \
 --url=ssh://git@gitea.com/<org>/<repository> \
 --branch=<my-branch> \
 --private-key-file=<path/to/ssh/private.key> \
 --password=<key-passphrase> \
 --path=clusters/my-cluster

Note that you must generate a SSH private key and set the public key as a deploy key on Gitea in advance.

For more information on how to use the flux bootstrap git command, please see the generic Git server documentation.

Flux: Flux bootstrap for GitHub

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

The flux bootstrap github command deploys the Flux controllers on a Kubernetes cluster and configures the controllers to sync the cluster state from a GitHub repository. Besides installing the controllers, the bootstrap command pushes the Flux manifests to the GitHub repository and configures Flux to update itself from Git.

After running the bootstrap command, any operation on the cluster (including Flux upgrades) can be done via Git push, without the need to connect to the Kubernetes cluster.

Required permissions

To bootstrap Flux, the person running the command must have cluster admin rights for the target Kubernetes cluster. It is also required that the person running the command to be the owner of the GitHub repository, or to have admin rights of a GitHub organization.

GitHub PAT

For accessing the GitHub API, the bootstrap command requires a GitHub personal access token (PAT) with administration permissions.

The GitHub PAT can be exported as an environment variable:

export GITHUB_TOKEN=<gh-token>

If the GITHUB_TOKEN env var is not set, the bootstrap command will prompt you to type it the token.

You can also supply the token using a pipe e.g. echo "<gh-token>" | flux bootstrap github.

GitHub Personal Account

If you want to bootstrap Flux for a repository owned by a personal account, you can generate a GitHub PAT that can create repositories by checking all permissions under repo.

If you want to use an existing repository, the PAT’s user must have admin permissions.

Run the bootstrap for a repository on your personal GitHub account:

flux bootstrap github \
 --token-auth \
 --owner=my-github-username \
 --repository=my-repository-name \
 --branch=main \
 --path=clusters/my-cluster \
 --personal

If the specified repository does not exist, Flux will create it for you as private. If you wish to create a public repository, set --private=false.

When using --token-auth, the CLI and the Flux controllers running on the cluster will use the GitHub PAT to access the Git repository over HTTPS.

PAT secret

Note that the GitHub PAT is stored in the cluster as a Kubernetes Secret named flux-system inside the flux-system namespace. If you want to avoid storing your PAT in the cluster, please see how to configure GitHub Deploy Keys.

GitHub Organization

If you want to bootstrap Flux for a repository owned by an GitHub organization, it is recommended to create a dedicated user for Flux under your organization.

Generate a GitHub PAT for the Flux user that can create repositories by checking all permissions under repo.

If you want to use an existing repository, the Flux user must have admin permissions for that repository.

GitHub fine-grained PAT

Bootstrap can be run with a GitHub fine-grained personal access token, for repositories that are created ahead of time by an organization admin.

The fine-grained PAT must be generated with the following permissions:

Administration -> Access: Read-only
Contents -> Access: Read and write
Metadata -> Access: Read-only

Note that Administration should be set to Access: Read and write when using bootstrap github --token-auth=false.

Run the bootstrap for a repository owned by a GitHub organization:

flux bootstrap github \
 --token-auth \
 --owner=my-github-organization \
 --repository=my-repository \
 --branch=main \
 --path=clusters/my-cluster

When creating a new repository, you can specify a list of GitHub teams with --team=team1-slug,team2-slug, those teams will be granted maintainer access to the repository.

GitHub Enterprise

To run the bootstrap for a repository hosted on GitHub Enterprise, you have to specify your GitHub hostname:

flux bootstrap github \
 --token-auth \
 --hostname=my-github-enterprise.com \
 --owner=my-github-organization \
 --repository=my-repository \
 --branch=main \
 --path=clusters/my-cluster

If you want use SSH and GitHub deploy keys, set --token-auth=false and provide the SSH hostname with --ssh-hostname=my-github-enterprise.com.

GitHub Deploy Keys

If you want to bootstrap Flux using SSH instead of HTTP/S, you can set --token-auth=false and the Flux CLI will use the GitHub PAT to set a deploy key for your repository.

When using SSH, the bootstrap command will generate a SSH private key. The private key is stored in the cluster as a Kubernetes secret named flux-system inside the flux-system namespace.

The generated SSH key defaults to ECDSA P-384, to change the format use --ssh-key-algorithm and --ssh-ecdsa-curve.

The SSH public key, is used to create a GitHub deploy key. The deploy key is linked to the personal access token used to authenticate.

By default, the GitHub deploy key is set to read-only access. If you’re using Flux image automation, you must give it write access with --read-write-key=true.

Deploy Key rotation

Note that when the PAT is removed or when it expires, the GitHub deploy key will stop working. To regenerate the deploy key, delete the flux-system secret from the cluster and re-run the bootstrap command using a valid GitHub PAT.

Bootstrap without a GitHub PAT

For existing GitHub repositories, you can bootstrap Flux over SSH without using a GitHub PAT.

To use a SSH key instead of a GitHub PAT, the command changes to flux bootstrap git:

flux bootstrap git \
 --url=ssh://git@github.com/<org>/<repository> \
 --branch=<my-branch> \
 --private-key-file=<path/to/ssh/private.key> \
 --password=<key-passphrase> \
 --path=clusters/my-cluster

Note that you must generate a SSH private key and set the public key as a deploy key on GitHub in advance.

For more information on how to use the flux bootstrap git command, please see the generic Git server documentation.

Flux: Flux bootstrap for GitLab

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

The flux bootstrap gitlab command deploys the Flux controllers on a Kubernetes cluster and configures the controllers to sync the cluster state from a GitLab project. Besides installing the controllers, the bootstrap command pushes the Flux manifests to the GitLab project and configures Flux to update itself from Git.

After running the bootstrap command, any operation on the cluster (including Flux upgrades) can be done via Git push, without the need to connect to the Kubernetes cluster.

Required permissions

To bootstrap Flux, the person running the command must have cluster admin rights for the target Kubernetes cluster. It is also required that the person running the command to be the owner of the GitLab project, or to have admin rights of a GitLab group.

GitLab PAT

For accessing the GitLab API, the bootstrap command requires a GitLab personal access token (PAT) with complete read/write access to the GitLab API.

The GitLab PAT can be exported as an environment variable:

export GITLAB_TOKEN=<gl-token>

If the GITLAB_TOKEN env var is not set, the bootstrap command will prompt you to type it the token.

You can also supply the token using a pipe e.g. echo "<gl-token>" | flux bootstrap gitlab.

GitLab Personal Account

Run the bootstrap for a project on your personal GitLab account:

flux bootstrap gitlab \
 --deploy-token-auth \
 --owner=my-gitlab-username \
 --repository=my-project \
 --branch=master \
 --path=clusters/my-cluster \
 --personal

If the specified project does not exist, Flux will create it for you as private. If you wish to create a public project, set --private=false.

When using --deploy-token-auth, the CLI generates a GitLab project deploy token and stores it in the cluster as a Kubernetes Secret named flux-system inside the flux-system namespace.

Deploy token read-only

Note that project deploy tokens grant read-only access to Git. If you want to use Flux image automation, please see how to configure GitLab Deploy Keys with read-write Git accesses.

GitLab Groups

Run the bootstrap for a project owned by a GitLab (sub)group:

flux bootstrap gitlab \
 --deploy-token-auth \
 --owner=my-gitlab-group/my-gitlab-subgroup \
 --repository=my-project \
 --branch=master \
 --path=clusters/my-cluster

GitLab Enterprise

To run the bootstrap for a project hosted on GitLab on-prem or enterprise, you have to specify your GitLab hostname:

flux bootstrap gitlab \
 --token-auth \
 --hostname=my-gitlab-enterprise.com \
 --owner=my-gitlab-group \
 --repository=my-project \
 --branch=master \
 --path=clusters/my-cluster

If you want to use SSH and GitLab deploy keys, set --token-auth=false and provide the SSH hostname with --ssh-hostname=my-gitlab-enterprise.com.

GitLab Deploy Keys

If you want to bootstrap Flux using SSH instead of HTTP/S, you can set --token-auth=false and the Flux CLI will use the GitLab PAT to set a deploy key for your project.

When using SSH, the bootstrap command will generate a SSH private key. The private key is stored in the cluster as a Kubernetes secret named flux-system inside the flux-system namespace.

The generated SSH key defaults to ECDSA P-384, to change the format use --ssh-key-algorithm and --ssh-ecdsa-curve.

The SSH public key, is used to create a GitLab deploy key. By default, the GitLab deploy key is set to read-only access. If you’re using Flux image automation, you must give it write access with --read-write-key=true.

Deploy Key rotation

To regenerate the deploy key, delete the flux-system secret from the cluster and re-run the bootstrap command using a valid GitLab PAT.

Bootstrap without a GitLab PAT

For existing GitLab repositories, you can bootstrap Flux over SSH without using a GitLab PAT.

To use an SSH key instead of a GitLab PAT, the command changes to flux bootstrap git:

flux bootstrap git \
 --url=ssh://git@gitlab.com/<group>/<project> \
 --branch=<my-branch> \
 --private-key-file=<path/to/ssh/private.key> \
 --password=<key-passphrase> \
 --path=clusters/my-cluster

Note that you must generate an SSH private key and set the public key as a deploy key on GitLab in advance.

For more information on how to use the flux bootstrap git command, please see the generic Git server documentation.

Flux: Flux bootstrap for Bitbucket

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

The flux bootstrap bitbucket-server command deploys the Flux controllers on a Kubernetes cluster and configures the controllers to sync the cluster state from a Bitbucket project. Besides installing the controllers, the bootstrap command pushes the Flux manifests to the Bitbucket project and configures Flux to update itself from Git.

After running the bootstrap command, any operation on the cluster (including Flux upgrades) can be done via Git push, without the need to connect to the Kubernetes cluster.

Required permissions

To bootstrap Flux, the person running the command must have cluster admin rights for the target Kubernetes cluster. It is also required that the person running the command to be the owner of the Bitbucket project, or to have admin rights of a Bitbucket group.

Bitbucket versions

This bootstrap command works only with Bitbucket Server and Data Center. For Bitbucket Cloud, please use the generic bootstrap procedure.

Bitbucket HTTP Access Token

For accessing the Bitbucket API, the bootstrap command requires a Bitbucket HTTP Access Token with administration permissions.

The Bitbucket HTTP access token can be exported as an environment variable:

export BITBUCKET_TOKEN=<bb-token>

If the BITBUCKET_TOKEN env var is not set, the bootstrap command will prompt you to type it the token. You can also supply the token using a pipe e.g. echo "<bb-token>" | flux bootstrap bitbucket-server.

Bitbucket Personal Account

Run the bootstrap for a repository on your personal Bitbucket Server account:

flux bootstrap bitbucket-server \
 --token-auth \
 --hostname=my-bitbucket-server.com \
 --owner=my-bitbucket-username \
 --repository=my-repository \
 --branch=main \
 --path=clusters/my-cluster \
 --personal

If the specified repository does not exist, Flux will create it for you as private. If you wish to create a public repository, set --private=false.

When using --token-auth, the CLI and the Flux controllers running on the cluster will use the Bitbucket token to access the Git repository over HTTPS.

PAT secret

Note that the Bitbucket token is stored in the cluster as a Kubernetes Secret named flux-system inside the flux-system namespace. If you want to avoid storing your token in the cluster, please see how to configure Bitbucket SSH access keys.

Bitbucket Personal Project

Run the bootstrap for a repository owned by a Bitbucket Server project:

flux bootstrap bitbucket-server \
 --token-auth \
 --hostname=my-bitbucket-server.com \
 --owner=my-bitbucket-project \
 --username=my-bitbucket-username \
 --repository=my-repository \
 --branch=main \
 --path=clusters/my-cluster \
 --group=group-name

When you specify a list of groups, those teams will be granted write access to the repository.

Note: The username is mandatory for project owned repositories. The specified user must own the BITBUCKET_TOKEN and have sufficient rights on the target project to create repositories.

Bitbucket SSH Access Keys

If you want to bootstrap Flux using SSH instead of HTTP/S, you can set --token-auth=false and the Flux CLI will use the Bitbucket token to set a SSH access key for your repository.

When using SSH, the bootstrap command will generate a SSH private key. The private key is stored in the cluster as a Kubernetes secret named flux-system inside the flux-system namespace.

The generated SSH key defaults to ECDSA P-384, to change the format use --ssh-key-algorithm and --ssh-ecdsa-curve.

By default, the SSH key is set to read-only access. If you’re using Flux image automation, you must give it write access with --read-write-key=true.

To run the bootstrap for Bitbucket server with a custom SSH hostname and port:

flux bootstrap bitbucket-server \
 --hostname=my-bitbucket-server.com \
 --ssh-hostname=my-bitbucket-server.com:7999 \
 --owner=my-bitbucket-project \
 --username=my-bitbucket-username \
 --repository=my-repository \
 --branch=main \
 --path=clusters/my-cluster

Bootstrap without a Bitbucket token

For existing Bitbucket repositories, you can bootstrap Flux over SSH without using a Bitbucket token.

To use a SSH key instead of a Bitbucket token, the command changes to flux bootstrap git:

flux bootstrap git \
 --url=ssh://git@<host>/<org>/<repository> \
 --branch=<my-branch> \
 --private-key-file=<path/to/ssh/private.key> \
 --password=<key-passphrase> \
 --path=clusters/my-cluster

Note that you must generate a SSH private key and set the public key as the access key on Bitbucket in advance.

For more information on how to use the flux bootstrap git command, please see the generic Git server documentation.

Flux: Flux bootstrap for Azure DevOps

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

To install Flux on an AKS cluster using an Azure DevOps Git repository as the source of truth, you can use the flux bootstrap git command.

Required permissions

To bootstrap Flux, the person running the command must have cluster admin rights for the target Kubernetes cluster. It is also required that the person running the command to have pull and push rights for the Azure DevOps Git repository.

Azure DevOps PAT

For accessing the Azure API, the bootstrap command requires an Azure DevOps personal access token (PAT) with pull and push permissions for Git repositories.

Generate an Azure DevOps PAT and create a new repository to hold your Flux install and other Kubernetes resources.

The Azure DevOps PAT can be exported as an environment variable:

export GIT_PASSWORD=<az-token>

If the GIT_PASSWORD env var is not set, the bootstrap command will prompt you to type it the token.

You can also supply the token using a pipe e.g. echo "<az-token>" | flux bootstrap git.

Bootstrap using a DevOps PAT

Run the bootstrap for a repository using token-based authentication:

flux bootstrap git \
 --token-auth=true \
 --url=https://dev.azure.com/<org>/<project>/_git/<repository> \
 --branch=main \
 --path=clusters/my-cluster

When using --token-auth, the CLI and the Flux controllers running on the cluster will use the Azure DevOps PAT to access the Git repository over HTTPS.

Note that the Azure DevOps PAT is stored in the cluster as a Kubernetes Secret named flux-system inside the flux-system namespace.

Token rotation

Note that Azure DevOps PAT have an expiry date. To rotate the token before it expires, delete the flux-system secret from the cluster and create a new one with the new PAT:

flux create secret git flux-system \
 --url=https://dev.azure.com/<org>/<project>/_git/<repository> \
 --username=git \
 --password=<az-token>

Bootstrap using SSH keys

Azure DevOps SSH works only with RSA SHA-2 keys.

To configure Flux with RSA SHA-2 keys, you need to clone the DevOps locally, then create the file structure required by bootstrap with:

mkdir -p clusters/my-cluster/flux-system
touch clusters/my-cluster/flux-system/gotk-components.yaml \
 clusters/my-cluster/flux-system/gotk-sync.yaml \
 clusters/my-cluster/flux-system/kustomization.yaml

Edit the kustomization.yaml file to include the following patches:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
 - gotk-components.yaml
 - gotk-sync.yaml
patches:
 - patch: |
 - op: add
 path: /spec/template/spec/containers/0/args/-
 value: --ssh-hostkey-algos=rsa-sha2-512,rsa-sha2-256 
 target:
 kind: Deployment
 name: (source-controller|image-automation-controller)

Commit and push the changes to upstream with:

git add -A && git commit -m "init flux" && git push

To generate an SSH key pair compatible with Azure DevOps, you’ll need to use ssh-keygen with the rsa-sha2-512 algorithm:

ssh-keygen -t rsa-sha2-512

Upload the SSH public key to Azure DevOps. For more information, see the Azure DevOps documentation.

Run bootstrap using the SSH URL of the Azure DevOps repository and the RSA SHA-2 private key:

flux bootstrap git \
 --url=ssh://git@ssh.dev.azure.com/v3/<org>/<project>/<repository>
 --branch=<my-branch> \
 --ssh-hostkey-algos=rsa-sha2-512,rsa-sha2-256 \
 --private-key-file=<path/to/ssh/private.key> \
 --password=<key-passphrase> \
 --path=clusters/my-cluster

For more information on how to use the flux bootstrap git command, please see the generic Git server documentation.

Flux: Flux bootstrap for Google Cloud Source

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

To install Flux on a GKE cluster using a Google Cloud Source repository as the source of truth, you can use the flux bootstrap git command.

Required permissions

To bootstrap Flux, the person running the command must have cluster admin rights for the target Kubernetes cluster. It is also required that the person running the command to have pull and push rights for the Google Cloud Source repository.

Bootstrap over SSH

First create a new repository to hold your Flux install and other Kubernetes resources. Then generate a SSH key and add the SSH public key to your personal SSH keys on Google Cloud.

Run bootstrap using the SSH private key and passphrase:

flux bootstrap git \
 --url=ssh://<user>s@source.developers.google.com:2022/p/<project-name>/r/<repo-name> \
 --branch=<my-branch> \
 --private-key-file=<path/to/ssh/private.key> \
 --password=<key-passphrase> \
 --path=clusters/my-cluster

You can also pipe the passphrase e.g. echo key-passphrase | flux bootstrap git.

The SSH private key and the known hosts keys are stored in the cluster as a Kubernetes secret named flux-system inside the flux-system namespace.

SSH Key rotation

To rotate the SSH public key, delete the flux-system secret from the cluster and re-run the bootstrap command using a new SSH private key.

Flux: Flux bootstrap for Oracle VBS Git Repositories

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

To install Flux on an OKE cluster using an Oracle VBS Git repository as the source of truth, you can use the flux bootstrap git command.

Required permissions

To bootstrap Flux, the person running the command must have cluster admin rights for the target Kubernetes cluster. It is also required that the person running the command to have pull and push rights for the Oracle VBS Git repositories.

Oracle VBS PAT

For accessing the Oracle VBS, the bootstrap command requires an Oracle VBS personal access token (PAT) with pull and push permissions for Git repositories.

Generate an Oracle VBS Access Token. And create a new repository to hold your Flux install and other Kubernetes resources.

The Oracle VBS PAT can be exported as an environment variable:

export GIT_PASSWORD=<vbs-token>

If the GIT_PASSWORD env var is not set, the bootstrap command will prompt you to type it the token.

You can also supply the token using a pipe e.g. echo "<vbs-token>" | flux bootstrap git.

Bootstrap using an Oracle VBS PAT

Run the bootstrap for a repository using token-based authentication:

flux bootstrap git \
 --with-bearer-token=true \
 --url=https://<vbs-repository-url> \
 --branch=my-branch \
 --path=clusters/my-cluster

When using --with-bearer-token, the CLI and the Flux controllers running on the cluster will use the Oracle VBS PAT to access the Git repository over HTTPS.

Note that the Oracle VBS PAT is stored in the cluster as a Kubernetes Secret named flux-system inside the flux-system namespace.

Token rotation

Note that Oracle VBS PAT may have an expiry date if it was configured to have one. To rotate the token before it expires, delete the flux-system secret from the cluster and recreate it with the new PAT:

flux create secret git flux-system \
 --url=https://<vbs-repository-url> \
 --bearer-token=<vbs-token>