Merge branch 'main' into fharper/k3s-ssh

.github/workflows/check-syntax.yml

@@ -1,20 +1,28 @@
 ---
-name: Syntax Validation
+name: Check spelling & grammar
 on: [push, workflow_dispatch]
 
 jobs:
-  syntax-check:
+  check-syntax:
     name: vale
     runs-on: ubuntu-latest
     steps:
+
       - name: Checkout this repository
-        uses: actions/[email protected]
+        uses: actions/[email protected]
+
+      - name: Setup Python
+        uses: actions/[email protected]
+        with:
+          python-version: '3.12.4'
 
-      - name: Install Vale
-        run: |
-          wget https://github.com/errata-ai/vale/releases/download/v2.30.0/vale_2.30.0_Linux_64-bit.tar.gz -O vale.tar.gz
-          tar -xvzf vale.tar.gz vale
-          rm vale.tar.gz
+      - name: Setup Python
+        uses: ruby/[email protected]
+        with:
+          ruby-version: '3.3.4'
 
       - name: Validate the syntax
-        run: ./vale --config=.vale.ini *.md
+        uses: errata-ai/[email protected]
+        with:
+          fail_on_error: true
+          version: 3.6.1

.github/workflows/update-license.yml

@@ -18,7 +18,7 @@ jobs:
           token: ${{ secrets.GITHUB_TOKEN }}
           commitAuthorName: 'kube1st'
           commitAuthorEmail: ${{ secrets.GPG_EMAIL }}
-          gpgPrivateKey: ${{ secrets.GPG_KEY }}
+          gpgPrivateKey: ${{ secrets.GPG_PRIVATE_KEY }}
           gpgPassphrase: ${{ secrets.GPG_PASSPHRASE }}
           commitTitle: "chore: update license years with {{currentYear}}"
           prTitle: "chore: update license years with {{currentYear}}"

.vale.ini

@@ -1,4 +1,4 @@
-StylesPath = styles
+StylesPath = .vale
 Vocab = base
 
 [formats]
@@ -7,7 +7,7 @@ mdx = md
 [*.md]
 BasedOnStyles = Custom
 Packages = alex
-IgnoredScopes = code
 BlockIgnores = (?s) *(import.*?\n), \
-               (?s) *(### gitops\n)
+               (?s) *(### gitops\n), \
+               (?s) *(### Can I give the gitops repository another name\?\n)
 TokenIgnores = (?s) *(export.*?\n)

styles/Custom/spelling.yml → .vale/Custom/spelling.yml

@@ -3,4 +3,4 @@ extends: spelling
 message: "Did you really mean '%s'?"
 level: error
 ignore:
-  - styles/Custom/ignore.txt
+  - .vale/Custom/ignore.txt

styles/Custom/substitutions.yml → .vale/Custom/substitutions.yml

@@ -29,15 +29,10 @@ swap:
   docker: Docker
   gcp: Google Cloud
   gcp cloud: Google Cloud
-  # Starting or with a space before, and ending with a dot or space (so not working used in a path, caused of MDX)
   '[G|g]ithub': GitHub
-  # Starting or with a space before, and ending with a dot or space (so not working used in a path, caused of MDX)
   'git[H|h]ub': GitHub
-  # Starting or with a space before, and ending with a dot or space (so not working used in a path, caused of MDX)
-  '(?<=^| )[G|g]itlab(?=$| |\.)': GitLab
-  # Starting or with a space before, and ending with a dot or space (so not working used in a path, caused of MDX)
-  '(?<=^| )git[L|l]ab(?=$| |\.)': GitLab
-  # Starting or with a space before, and ending with a dot or space (so not working used in a path, caused of MDX)
+  '[G|g]itlab': GitLab
+  'git[L|l]ab': GitLab
   '(?<=^| )gitops(?=$| |\.)': GitOps for the term or put gitops as inline code for the repository
   google: Google
   helm: Helm
@@ -53,5 +48,6 @@ swap:
   '(?<=^| )terraform(?=$| |\.)': Terraform
   ui: UI
   url: URL
+  vault: Vault
   vpc: VPC
   vultr: Vultr

styles/Vocab/base/accept.txt → .vale/config/vocabularies/base/accept.txt

@@ -1,16 +1,21 @@
 # A
 admunition
+Akamai
 anonymize
 auditable
+authentification
+authtoken
 automation
 
 # B
 
 # C
 CLI'
+CLIs
 ClusterIssuer
 containerd
 CPU
+Crossplane
 CWFT
 
 # D
@@ -26,6 +31,7 @@ Docusaurus
 # G
 
 # H
+hardcoded
 hotfix
 
 # I
@@ -39,6 +45,7 @@ KMS
 kubectl
 
 # L
+Linode
 
 # M
 markdownlint
@@ -57,6 +64,7 @@ onboarding
 
 # P
 preconfigure
+preloaded
 
 # Q
 
@@ -81,6 +89,7 @@ uncomment
 
 # V
 vale
+vcluster
 Vultr
 
 # W

charts/docs/Chart.yaml

@@ -1,6 +1,6 @@
 apiVersion: v2
-appVersion: 115f368
+appVersion: 9a78271
 description: Kubefirst documentation Helm chart
 name: docs
 type: application
-version: 1.130.0
+version: 1.131.0

docs/akamai/overview.mdx

@@ -29,7 +29,7 @@ Akamai is in beta. Use at your own risks.
 :::
 
 :::note
-[Linode has been acquired by Akamai in 2022](https://www.akamai.com/newsroom/press-release/akamai-completes-acquisition-of-linode), but the branding is still in some cases, like for the CLI used to connect to Kubernetes on Akamai. If you see Linode written in the documention, keep in mind that it is in reality Akamai, but that we have to use the previous brand because Akamai still do.
+[Linode has been acquired by Akamai in 2022](https://www.akamai.com/newsroom/press-release/akamai-completes-acquisition-of-linode), but the branding is still in some cases, like for the CLI used to connect to Kubernetes on Akamai. If you see Linode written in the documentation, keep in mind that it is in reality Akamai, but that we have to use the previous brand because Akamai still do.
 :::
 
 The Akamai provisioning process will:

docs/akamai/quick-start/install/cli.mdx

@@ -40,13 +40,6 @@ export const TabLabel = ({ imgSrc, label, alt }) => (
     <CommonTerminalOutput cloud="Akamai"  minutes="10" handoffScreen={GitHubHandoffScreen} />
   </TabItem>
 
-  <!-- markdownlint-disable MD049 -->
-  {/*<TabItem attributes={{ className: styles.gitlab }} value="gitlab" label={ <div className="git-tab"><img src="https://assets.kubefirst.com/console/gitlab.svg" alt="GitLab logo" /><span>GitLab</span></div> }>
-    <GitLabPrerequisites />
-    <GitLabClusterCreateCmd />
-    <CommonTerminalOutput cloud="Akamai"  minutes="10" handoffScreen={GitLabHandoffScreen} />
-  </TabItem>*/}
-
 </Tabs>
 
 <CommonRootCredentialsCmd cloud="akamai" />

docs/common/clusters.mdx

@@ -1,54 +1,51 @@
-The kubefirst 2.3 release introduces kubernetes cluster lifecycle management to the platform to provide our users with the ability
-to create their own opinionated workload clusters in a way that takes advantage of their management cluster. We're introducing both
-physical clusters, which will be created in your cloud account, as well as virtual clusters, which are also isolated kubernetes
-clusters, but which run inside your management cluster.
+The kubefirst 2.3 release introduces Kubernetes cluster lifecycle management to the platform to provide our users with the ability to create their own opinionated workload clusters in a way that takes advantage of their management cluster. We're introducing both physical clusters, which will be created in your cloud account, as well as virtual clusters, which are also isolated Kubernetes clusters, but which run inside your management cluster.
 
 ![cluster creation in kubefirst user interface](../img/kubefirst/getting-started/cluster-creation.gif)
 
 ## GitOps-Oriented Workload Clusters
 
 By default, a new kubefirst will provide you with 2 template-driven directories that will drive how your workload clusters are created.
 
-![cluster template directories in gitops repository](../img/kubefirst/getting-started/cluster-template.png)
+![cluster template directories in GitOps repository](../img/kubefirst/getting-started/cluster-template.png)
 
 Each cluster that you create from these templates through our management interface will orchestrate the following:
 
 - new Argo CD project in the management cluster's Argo CD instance to encapsulate the apps that are delivered to that new cluster
-- a new app-of-apps for your cluster will be added to your `registry/clusters` directory in your `gitops` repo and bound to your manangement cluster's orchestration in `registry/clusters/<management-cluster>/components/clusters`
-- an optional environment binding so a new cluster can establish a space for a new environment in your gitops repository
+- a new app-of-apps for your cluster will be added to your `registry/clusters` directory in your `gitops` repository and bound to your management cluster's orchestration in `registry/clusters/<management-cluster>/components/clusters`
+- an optional environment binding so a new cluster can establish a space for a new environment in your `gitops` repository
 
 ![cluster binding in management clusters directory](../img/kubefirst/getting-started/cluster-binding.png)
 
 ## Cluster Provisioning Orchestration
 
 ![production workload cluster app-of-apps in Argo CD](../img/kubefirst/getting-started/cluster-argocd.png)
 
-If you inspect your templates for cluster and vcluster, you'll find them to be very similar. They will both create new kubernetes clusters with the following components preloaded:
+If you inspect your templates for cluster and vcluster, you'll find them to be very similar. They will both create new Kubernetes clusters with the following components preloaded:
 
-- infrastructure (virtual): vcluster kubernetes cluster that will run in a namespace in your management cluster, with an additional bootstrap app to configure the cluster with crossplane-managed terraform
-- infrastructure (physical): crossplane-managed terraform that creates a kubernetes cluster tailored to your cloud and configures the cluster
+- infrastructure (virtual): vcluster Kubernetes cluster that will run in a namespace in your management cluster, with an additional bootstrap app to configure the cluster with crossplane-managed Terraform
+- infrastructure (physical): crossplane-managed Terraform that creates a Kubernetes cluster tailored to your cloud and configures the cluster
 - ingress-nginx ingress controller
 - external-dns preconfigured for your domain
-- external-secrets-operator with preconfigured secret store to access vault in the management cluster
+- external-secrets-operator with preconfigured secret store to access Vault in the management cluster
 - cert-manager with clusterissuers preconfigured
 - reloader for pod restart automation
-- optional binding to an environment directory in your gitops repo
-- you can customize this template in your gitops repository as your needs require
+- optional binding to an environment directory in your `gitops` repository
+- you can customize this template in your `gitops` repository as your needs require
 
 :::tip
-The Kubefirst Console "Physical Clusters" feature will be the first feature of our upcoming Pro tier. We'd love for you to try it out and tell us what you think during its free introductory period.
+The kubefirst Console "Physical Clusters" feature will be the first feature of our upcoming Pro tier. We'd love for you to try it out and tell us what you think during its free introductory period.
 
-We plan to keep the Kubefirst Console "Virtual Clusters" feature on the Community tier at no cost.
+We plan to keep the kubefirst Console "Virtual Clusters" feature on the Community tier at no cost.
 
-You will always be able to create anything you need on your own without our user interface, and we hope you find that starting point immensly valuable. We hope to earn your business with our management interface. Thank you sincerely to all of our customers.
+You will always be able to create anything you need on your own without our user interface, and we hope you find that starting point immensely valuable. We hope to earn your business with our management interface. Thank you sincerely to all of our customers.
 :::
 
 ## Operating your workload clusters
 
-When you create a cluster in our UI we place the gitops content for the cluster and its apps in your gitops repository. You'll be able to see it in your gitops repo commits.
+When you create a cluster in our UI we place the GitOps content for the cluster and its apps in your `gitops` repository. You'll be able to see it in your `gitops` repository commits.
 
 Cluster creation takes about 6 minutes to fully sync in Argo CD for virtual clusters. Physical clusters take anywhere from 5 to 25 minutes to fully sync, depending on the cloud, the weather, or anything in between.
 
 Your workload cluster will have a starting point app-of-apps in Argo CD in the `clusters` app and will share your cluster's name.
 
-When you delete a cluster, kubefirst will remove the binding from your management cluster so that it begins deleting in Argo CD, but we must leave the directory there so that the apps can remove gracefully. You're free to remove it once cluster deprovisioning has completed successfully. Deletion takes time to deprovision resources - can be anywhere from 5 to 15 minites depending on the cloud. Be patient and inspect the deprovision operation in argocd.
+When you delete a cluster, kubefirst will remove the binding from your management cluster so that it begins deleting in Argo CD, but we must leave the directory there so that the apps can remove gracefully. You're free to remove it once cluster deprovisioning has completed successfully. Deletion takes time to deprovision resources - can be anywhere from 5 to 15 minutes depending on the cloud. Be patient and inspect the deprovision operation in Argo CD.

docs/common/faq.mdx

@@ -18,7 +18,7 @@
 - [What is the wait.yaml file in each application components folder?](#what-is-the-waityaml-file-in-each-application-components-folder)
 - [Can I install kubefirst on an existing cluster?](#can-i-install-kubefirst-on-an-existing-cluster)
 - [Does kubefirst add any cloud resources overhead?](#does-kubefirst-add-any-cloud-resources-overhead)
-- [Can I give the gitops repository another name?](#can-i-give-the-gitops-repository-another-name)
+- [Can I give the GitOps repository another name?](#can-i-give-the-gitops-repository-another-name)
 - [How can I unseal HashiCorp Vault?](#how-can-i-unseal-hashicorp-vault)
 - [Terraform is returning a quota limit exceeded error](#terraform-is-returning-a-quota-limit-exceeded-error)
 - [Do you plan to support technology X?](#do-you-plan-to-support-technology-x)
@@ -70,7 +70,7 @@ kubefirst adds virtually no overhead when it comes to cloud resources compared t
 
 ### Can I give the gitops repository another name?
 
-It is not possible right now to have kubefirst create the GitOps repository under another name, nor to easily rename it after the creation. Unfortunately, a lot of parts of our code using the repository's name are hardcoded. We may add this option in the future.
+It is not possible right now to have kubefirst create the `gitops` repository under another name, nor to easily rename it after the creation. Unfortunately, a lot of parts of our code using the repository's name are hardcoded. We may add this option in the future.
 
 ### How can I unseal HashiCorp Vault?
 

docs/common/gitops-catalog.mdx

@@ -12,7 +12,7 @@ After your management cluster has been provisioned, you're able to click on a bu
 
 ![Cluster provision complete](../img/common/catalog/button.png)
 
-Once this button has been clicked, you'll be sent to your new Kubefirst console. In the left margin, click on Applications.
+Once this button has been clicked, you'll be sent to your new kubefirst console. In the left margin, click on Applications.
 
 ![Applications page](../img/common/catalog/page.png)
 

docs/common/known-limitations.mdx

@@ -1,3 +1,3 @@
 ### General
 
-- [Let's encrypt](https://letsencrypt.org/) is limited to 50 weekly certificates with an additional limitations of 5 per subdomains. We use Let's encrypt to automatically create certicicates for your domains. In most cases, this won't be an issue, but you may reach that limit if you create, and destroy often kubefirst clusters using the same domain during a short period. You can use the [Let's Debug Toolkit](https://tools.letsdebug.net/cert-search) to check those, but note that the result isn't always valid.
+- [Let's encrypt](https://letsencrypt.org/) is limited to 50 weekly certificates with an additional limitations of 5 per subdomains. We use Let's encrypt to automatically create certificates for your domains. In most cases, this won't be an issue, but you may reach that limit if you create, and destroy often kubefirst clusters using the same domain during a short period. You can use the [Let's Debug Toolkit](https://tools.letsdebug.net/cert-search) to check those, but note that the result isn't always valid.

docs/common/partials/common/_prerequisites-windows.mdx

@@ -1 +1 @@
-We currenctly do not support Windows directly, but you can easily use kubefirst using [WSL](https://learn.microsoft.com/en-us/windows/wsl/about) (tested with Ubuntu). To install the lastest WSL version, please follow the [Microsoft documentation on how to install Linux on Windows](https://learn.microsoft.com/en-us/windows/wsl/install).
+We currently do not support Windows directly, but you can easily use kubefirst using [WSL](https://learn.microsoft.com/en-us/windows/wsl/about) (tested with Ubuntu). To install the latest WSL version, please follow the [Microsoft documentation on how to install Linux on Windows](https://learn.microsoft.com/en-us/windows/wsl/install).

docs/common/partials/common/_prerequisites.mdx

@@ -26,7 +26,7 @@ import Windows from '../common/_prerequisites-windows.mdx';
 
 :::info
 
-If you are a Windows user, you need to be sure to enable Docker support in WSL2 distros. More information in the [Docker documentation](https://docs.docker.com/desktop/wsl/#enabling-docker-support-in-wsl-2-distros).
+If you are a Windows user, you need to be sure to enable Docker support in WSL2 distributions. More information in the [Docker documentation](https://docs.docker.com/desktop/wsl/#enabling-docker-support-in-wsl-2-distros).
 
 :::
 

docs/common/partials/github/_tokens.mdx

@@ -16,6 +16,7 @@ If you never connected to GitHub using SSH before and are creating a cluster usi
 
 kubefirst needs the following scopes or scopes groups:
 
+<!-- vale off -->
 | Scope                 | Score Permission                             | kubefirst Usage                                                                                         |
 |-----------------------|----------------------------------------------|---------------------------------------------------------------------------------------------------------|
 | repo                  | Full access to public & private repositories | Creating 2 repositories on cluster creation & manage repositories related to your cluster with Atlantis |
@@ -28,6 +29,7 @@ kubefirst needs the following scopes or scopes groups:
 | user                  | Grants read & write access to profile info   | Retrieving the user profile to display in the console UI & let the user validate the used token         |
 | delete_repo           | Delete repositories                          | Deleting repositories managed by Infrastructure as Code with Atlantis                                   |
 | admin:ssh_signing_key | Full control of public user SSH signing keys | This is will be removed soon (see [#2180](https://github.com/kubefirst/kubefirst/issues/2180))          |
+<!-- vale on -->
 
 You can read more about the [scopes in the GitHub documentation](https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/scopes-for-oauth-apps#available-scopes).
 

docs/common/partials/github/_user-creation.mdx

@@ -51,7 +51,7 @@ Atlantis will always run plans automatically for you when a pull request is open
 
 Any new users you have created through this process will have their temporary initial passwords stored in your Vault cluster. You can access Vault using the root login credentials provided to you during your kubefirst installation. Only the root Vault token can access these secrets. You will find your users' initial passwords in the Vault secret store `/secrets/users/<username>`.
 
-![vault token login](../../../img/kubefirst/local/vault-token-login.png)
+![Vault token login](../../../img/kubefirst/local/vault-token-login.png)
 
 Once you've provided them their initial password, they can update their own password throughout the platform by updating their user password entity in Vault. Anyone can change their own password, and Admins can reset anyone's password. These rules, just like everything else on kubefirst, can be configured in your new `gitops` repository.
 

docs/common/partials/gitlab/_user-creation.mdx

@@ -52,7 +52,7 @@ Atlantis will always run plans automatically for you when a merge request is ope
 
 Any new users you have created through this process will have their temporary initial passwords stored in your Vault cluster. You can access Vault using the root login credentials provided to you during your kubefirst installation. Only the root Vault token can access these secrets. You will find your users' initial passwords in the Vault secret store `/secrets/users/<username>`.
 
-![vault token login](../../../img/kubefirst/local/vault-token-login.png)
+![Vault token login](../../../img/kubefirst/local/vault-token-login.png)
 
 Once you've provided them their initial password, they can update their own password throughout the platform by updating their user password entity in Vault. Anyone can change their own password, and Admins can reset anyone's password. These rules, just like everything else on kubefirst, can be configured in your new `gitops` repository.