diff options
Diffstat (limited to 'doc/user/clusters/agent')
| -rw-r--r-- | doc/user/clusters/agent/ci_cd_workflow.md | 2 | ||||
| -rw-r--r-- | doc/user/clusters/agent/gitops.md | 7 | ||||
| -rw-r--r-- | doc/user/clusters/agent/install/index.md | 6 | ||||
| -rw-r--r-- | doc/user/clusters/agent/troubleshooting.md | 4 | ||||
| -rw-r--r-- | doc/user/clusters/agent/vulnerabilities.md | 18 | ||||
| -rw-r--r-- | doc/user/clusters/agent/work_with_agent.md | 3 |
6 files changed, 21 insertions, 19 deletions
diff --git a/doc/user/clusters/agent/ci_cd_workflow.md b/doc/user/clusters/agent/ci_cd_workflow.md index 304bbaee256..982411d35f9 100644 --- a/doc/user/clusters/agent/ci_cd_workflow.md +++ b/doc/user/clusters/agent/ci_cd_workflow.md @@ -66,7 +66,7 @@ To authorize the agent to access the GitLab project where you keep Kubernetes ma 1. On the top bar, select **Main menu > Projects** and find the project that contains the [agent configuration file](install/index.md#create-an-agent-configuration-file) (`config.yaml`). 1. Edit the `config.yaml` file. Under the `ci_access` keyword, add the `projects` attribute. -1. For the `id`, add the path: +1. For the `id`, add the path to the project. Do not wrap the path in quotation marks. ```yaml ci_access: diff --git a/doc/user/clusters/agent/gitops.md b/doc/user/clusters/agent/gitops.md index bd7dfb3abee..787b0062017 100644 --- a/doc/user/clusters/agent/gitops.md +++ b/doc/user/clusters/agent/gitops.md @@ -115,10 +115,7 @@ The agent has [default sorting](https://github.com/kubernetes-sigs/cli-utils/blo but with annotations, you can fine-tune the order and apply time-value injection. To provide the GitOps functionality, the GitLab agent for Kubernetes uses the [`cli-utils` library](https://github.com/kubernetes-sigs/cli-utils/), -a Kubernetes SIG project. You can read more about the available annotations in the [`cli-utils` documentation](https://github.com/kubernetes-sigs/cli-utils/blob/master/README.md#apply-sort-ordering). - -- [Learn more about apply sort ordering](https://github.com/kubernetes-sigs/cli-utils#apply-sort-ordering). -- [Learn more about apply-time mutation](https://github.com/kubernetes-sigs/cli-utils#apply-time-mutation). +a Kubernetes SIG project. For more information, see the available annotations in the [`cli-utils` documentation](https://github.com/kubernetes-sigs/cli-utils/blob/master/README.md). ## Automatic drift remediation @@ -183,4 +180,4 @@ update your agent configuration file with the location of these projects. WARNING: The project with the agent's configuration file can be private or public. Other projects with Kubernetes manifests must be public. Support for private manifest projects is tracked -in [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/283885). +in [this epic](https://gitlab.com/groups/gitlab-org/-/epics/7704). diff --git a/doc/user/clusters/agent/install/index.md b/doc/user/clusters/agent/install/index.md index 62767f1dfd9..bb9a9c371a2 100644 --- a/doc/user/clusters/agent/install/index.md +++ b/doc/user/clusters/agent/install/index.md @@ -22,7 +22,7 @@ Before you can install the agent in your cluster, you need: - [Digital Ocean](https://docs.digitalocean.com/products/kubernetes/quickstart/) - On self-managed GitLab instances, a GitLab administrator must set up the [agent server](../../../../administration/clusters/kas.md). - Then it will be available by default at `wss://gitlab.example.com/-/kubernetes-agent/`. + Then it is available by default at `wss://gitlab.example.com/-/kubernetes-agent/`. On GitLab.com, the agent server is available at `wss://kas.gitlab.com`. ## Installation steps @@ -155,6 +155,10 @@ helm upgrade --install gitlab-agent gitlab/gitlab-agent \ ... ``` +NOTE: +DNS rebind protection is disabled when either the HTTP_PROXY or the HTTPS_PROXY environment variable is set, +and the domain DNS can't be resolved. + #### Advanced installation method GitLab also provides a [KPT package for the agent](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/tree/master/build/deployment/gitlab-agent). This method provides greater flexibility, but is only recommended for advanced users. diff --git a/doc/user/clusters/agent/troubleshooting.md b/doc/user/clusters/agent/troubleshooting.md index a44d1e9685b..f5f235d2758 100644 --- a/doc/user/clusters/agent/troubleshooting.md +++ b/doc/user/clusters/agent/troubleshooting.md @@ -108,7 +108,7 @@ certificate authority that is unknown to the agent. To fix this issue, you can present the CA certificate file to the agent by using a Kubernetes `configmap` and mount the file in the agent `/etc/ssl/certs` directory from where it -will be picked up automatically. +is picked up automatically. For example, if your internal CA certificate is `myCA.pem`: @@ -200,7 +200,7 @@ are stored in the repository where the agent is configured. ``` The GitLab agent performs vulnerability scans by creating a job to scan each workload. If a scan -is interrupted, these jobs may be left behind and will need to be cleaned up before more jobs can +is interrupted, these jobs may be left behind and need to be cleaned up before more jobs can be run. You can clean up these jobs by running: ```shell diff --git a/doc/user/clusters/agent/vulnerabilities.md b/doc/user/clusters/agent/vulnerabilities.md index 37d742e2b08..a71eea82df5 100644 --- a/doc/user/clusters/agent/vulnerabilities.md +++ b/doc/user/clusters/agent/vulnerabilities.md @@ -1,13 +1,13 @@ --- -stage: Configure -group: Configure +stage: Secure +group: Composition analysis info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments --- # Operational Container Scanning **(ULTIMATE)** > - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/6346) in GitLab 14.8. -> - [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/368828) the starboard directive in GitLab 15.4. The starboard directive will be removed in GitLab 16.0. +> - [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/368828) the starboard directive in GitLab 15.4. The starboard directive is scheduled for removal in GitLab 16.0. To view cluster vulnerabilities, you can view the [vulnerability report](../../application_security/vulnerabilities/index.md). You can also configure your agent so the vulnerabilities are displayed with other agent information in GitLab. @@ -24,7 +24,7 @@ In GitLab 15.0 and later, you do not need to install Starboard operator in the K ### Enable via agent configuration To enable scanning of all images within your Kubernetes cluster via the agent configuration, add a `container_scanning` configuration block to your agent -configuration with a `cadence` field containing a [CRON expression](https://docs.oracle.com/cd/E12058_01/doc/doc.1014/e12030/cron_expressions.htm) for when the scans will be run. +configuration with a `cadence` field containing a [CRON expression](https://docs.oracle.com/cd/E12058_01/doc/doc.1014/e12030/cron_expressions.htm) for when the scans are run. ```yaml container_scanning: @@ -42,7 +42,7 @@ Other elements of the [CRON syntax](https://docs.oracle.com/cd/E12058_01/doc/doc NOTE: The CRON expression is evaluated in [UTC](https://www.timeanddate.com/worldclock/timezone/utc) using the system-time of the Kubernetes-agent pod. -By default, operational container scanning will attempt to scan the workloads in all +By default, operational container scanning attempts to scan the workloads in all namespaces for vulnerabilities. You can set the `vulnerability_report` block with the `namespaces` field which can be used to restrict which namespaces are scanned. For example, if you would like to scan only the `default`, `kube-system` namespaces, you can use this configuration: @@ -60,10 +60,10 @@ container_scanning: To enable scanning of all images within your Kubernetes cluster via scan execution policies, we can use the [scan execution policy editor](../../application_security/policies/scan-execution-policies.md#scan-execution-policy-editor) -in order to create a new schedule rule. +To create a new schedule rule. NOTE: -The Kubernetes agent must be running in your cluster in order to scan running container images +The Kubernetes agent must be running in your cluster to scan running container images Here is an example of a policy which enables operational container scanning within the cluster the Kubernetes agent is attached to: @@ -84,9 +84,9 @@ Here is an example of a policy which enables operational container scanning with The keys for a schedule rule are: -- `cadence` (required): a [CRON expression](https://docs.oracle.com/cd/E12058_01/doc/doc.1014/e12030/cron_expressions.htm) for when the scans will be run +- `cadence` (required): a [CRON expression](https://docs.oracle.com/cd/E12058_01/doc/doc.1014/e12030/cron_expressions.htm) for when the scans are run - `agents:<agent-name>` (required): The name of the agent to use for scanning -- `agents:<agent-name>:namespaces` (optional): The Kubernetes namespaces to scan. If omitted, all namespaces will be scanned +- `agents:<agent-name>:namespaces` (optional): The Kubernetes namespaces to scan. If omitted, all namespaces are scanned NOTE: Other elements of the [CRON syntax](https://docs.oracle.com/cd/E12058_01/doc/doc.1014/e12030/cron_expressions.htm) may work in the cadence field if supported by the [cron](https://github.com/robfig/cron) we are using in our implementation, however, GitLab does not officially test or support them. diff --git a/doc/user/clusters/agent/work_with_agent.md b/doc/user/clusters/agent/work_with_agent.md index 566eae8e24e..0b0e1365604 100644 --- a/doc/user/clusters/agent/work_with_agent.md +++ b/doc/user/clusters/agent/work_with_agent.md @@ -19,6 +19,7 @@ Prerequisite: To view the list of agents: 1. On the top bar, select **Main menu > Projects** and find the project that contains your agent configuration file. + You cannot view registered agents from a project that does not contain the agent configuration file. 1. On the left sidebar, select **Infrastructure > Kubernetes clusters**. 1. Select **Agent** tab to view clusters connected to GitLab through the agent. @@ -76,7 +77,7 @@ observability: grpc_level: warn ``` -When `grpc_level` is set to `info` or below, there will be a lot of gRPC logs. +When `grpc_level` is set to `info` or below, there are a lot of gRPC logs. Commit the configuration changes and inspect the agent service logs: |