diff options
Diffstat (limited to 'doc/user/clusters/agent')
| -rw-r--r-- | doc/user/clusters/agent/ci_cd_workflow.md | 6 | ||||
| -rw-r--r-- | doc/user/clusters/agent/gitops.md | 3 | ||||
| -rw-r--r-- | doc/user/clusters/agent/install/index.md | 2 | ||||
| -rw-r--r-- | doc/user/clusters/agent/vulnerabilities.md | 3 |
4 files changed, 9 insertions, 5 deletions
diff --git a/doc/user/clusters/agent/ci_cd_workflow.md b/doc/user/clusters/agent/ci_cd_workflow.md index dce02a72300..16b92eb92a3 100644 --- a/doc/user/clusters/agent/ci_cd_workflow.md +++ b/doc/user/clusters/agent/ci_cd_workflow.md @@ -25,7 +25,7 @@ To ensure access to your cluster is safe: - Each agent has a separate context (`kubecontext`). - Only the project where the agent is configured, and any additional projects you authorize, can access the agent in your cluster. -You do not need to have a runner in the cluster with the agent. +The CI/CD workflow requires runners to be registered with GitLab, but these runners do not have to be in the cluster where the agent is. ## GitLab CI/CD workflow steps @@ -127,8 +127,8 @@ Run `kubectl config get-contexts`. ### Environments with both certificate-based and agent-based connections -When you deploy to an environment that has both a [certificate-based -cluster](../../infrastructure/clusters/index.md) (deprecated) and an agent connection: +When you deploy to an environment that has both a +[certificate-based cluster](../../infrastructure/clusters/index.md) (deprecated) and an agent connection: - The certificate-based cluster's context is called `gitlab-deploy`. This context is always selected by default. diff --git a/doc/user/clusters/agent/gitops.md b/doc/user/clusters/agent/gitops.md index 73a35ffbc64..4978b56917b 100644 --- a/doc/user/clusters/agent/gitops.md +++ b/doc/user/clusters/agent/gitops.md @@ -4,10 +4,11 @@ group: Configure info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments --- -# Using GitOps with a Kubernetes cluster **(PREMIUM)** +# Using GitOps with a Kubernetes cluster **(FREE)** > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/259669) in GitLab 13.7. > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/332227) in GitLab 14.0, the `resource_inclusions` and `resource_exclusions` attributes were removed and `reconcile_timeout`, `dry_run_strategy`, `prune`, `prune_timeout`, `prune_propagation_policy`, and `inventory_policy` attributes were added. +> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/346567) from GitLab Premium to GitLab Free in 15.3. With GitOps, you can manage containerized clusters and applications from a Git repository that: diff --git a/doc/user/clusters/agent/install/index.md b/doc/user/clusters/agent/install/index.md index 9282ac7fb40..4b0d8b77493 100644 --- a/doc/user/clusters/agent/install/index.md +++ b/doc/user/clusters/agent/install/index.md @@ -17,7 +17,7 @@ To connect a Kubernetes cluster to GitLab, you must install an agent in your clu Before you can install the agent in your cluster, you need: - An existing Kubernetes cluster. If you don't have a cluster, you can create one on a cloud provider, like: - - [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine/docs/quickstart) + - [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine/docs/deploy-app-cluster) - [Amazon Elastic Kubernetes Service (EKS)](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html) - [Digital Ocean](https://docs.digitalocean.com/products/kubernetes/quickstart/) - On self-managed GitLab instances, a GitLab administrator must set up the diff --git a/doc/user/clusters/agent/vulnerabilities.md b/doc/user/clusters/agent/vulnerabilities.md index 3b80a7a0f81..5afe3ccec2b 100644 --- a/doc/user/clusters/agent/vulnerabilities.md +++ b/doc/user/clusters/agent/vulnerabilities.md @@ -16,6 +16,9 @@ You can also configure your agent so the vulnerabilities are displayed with othe You can use operational container scanning to scan container images in your cluster for security vulnerabilities. +NOTE: +In GitLab 15.0 and later, you do not need to install Starboard operator in the Kubernetes cluster. + To begin scanning all resources in your cluster, add a `starboard` configuration block to your agent configuration with a `cadence` field containing a CRON expression for when the scans will be run. |