summaryrefslogtreecommitdiff
path: root/doc/user/clusters/agent/index.md
diff options
context:
space:
mode:
authorGitLab Bot <gitlab-bot@gitlab.com>2021-09-20 13:18:24 +0000
committerGitLab Bot <gitlab-bot@gitlab.com>2021-09-20 13:18:24 +0000
commit0653e08efd039a5905f3fa4f6e9cef9f5d2f799c (patch)
tree4dcc884cf6d81db44adae4aa99f8ec1233a41f55 /doc/user/clusters/agent/index.md
parent744144d28e3e7fddc117924fef88de5d9674fe4c (diff)
downloadgitlab-ce-0653e08efd039a5905f3fa4f6e9cef9f5d2f799c.tar.gz
Add latest changes from gitlab-org/gitlab@14-3-stable-eev14.3.0-rc42
Diffstat (limited to 'doc/user/clusters/agent/index.md')
-rw-r--r--doc/user/clusters/agent/index.md48
1 files changed, 18 insertions, 30 deletions
diff --git a/doc/user/clusters/agent/index.md b/doc/user/clusters/agent/index.md
index c59d2a1f61c..d2dc57c0849 100644
--- a/doc/user/clusters/agent/index.md
+++ b/doc/user/clusters/agent/index.md
@@ -20,7 +20,7 @@ tasks in a secure and cloud-native way. It enables:
- Pull-based GitOps deployments.
- [Inventory object](../../infrastructure/clusters/deploy/inventory_object.md) to keep track of objects applied to your cluster.
- Real-time access to API endpoints in a cluster.
-- Alert generation based on [Container network policy](../../application_security/threat_monitoring/index.md#container-network-policy).
+- Alert generation based on [Container network policy](../../application_security/policies/index.md#container-network-policy).
- [CI/CD Tunnel](ci_cd_tunnel.md) that enables users to access Kubernetes clusters from GitLab CI/CD jobs even if there is no network connectivity between GitLab Runner and a cluster.
Many more features are planned. Please review [our roadmap](https://gitlab.com/groups/gitlab-org/-/epics/3329)
@@ -77,6 +77,8 @@ The setup process involves a few steps to enable GitOps deployments:
1. [Install the Agent into the cluster](#install-the-agent-into-the-cluster).
1. [Create manifest files](#create-manifest-files).
+<i class="fa fa-youtube-play youtube" aria-hidden="true"></i> Watch a GitLab 14.2 [walking-through video](https://www.youtube.com/watch?v=XuBpKtsgGkE) with this process.
+
### Upgrades and version compatibility
As the GitLab Kubernetes Agent is a new product, we are constantly adding new features
@@ -104,7 +106,8 @@ To use the KAS:
### Define a configuration repository
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/259669) in GitLab 13.7, the Agent manifest configuration can be added to multiple directories (or subdirectories) of its repository.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/259669) in GitLab 13.7, the Agent manifest configuration can be added to multiple directories (or subdirectories) of its repository.
+> - Group authorization was [introduced](https://gitlab.com/groups/gitlab-org/-/epics/5784) in GitLab 14.3.
To configure an Agent, you need:
@@ -123,6 +126,7 @@ In your repository, add the Agent configuration file under:
Your `config.yaml` file specifies all configurations of the Agent, such as:
- The manifest projects to synchronize.
+- The groups that can access this Agent via the [CI/CD Tunnel](ci_cd_tunnel.md).
- The address of the `hubble-relay` for the Network Security policy integrations.
As an example, a minimal Agent configuration that sets up only the manifest
@@ -174,17 +178,14 @@ To perform a one-liner installation, run the command below. Make sure to replace
- `your-agent-token` with the token received from the previous step (identified as `secret` in the JSON output).
- `gitlab-kubernetes-agent` with the namespace you defined in the previous step.
- `wss://kas.gitlab.example.com` with the configured access of the Kubernetes Agent Server (KAS). For GitLab.com users, the KAS is available under `wss://kas.gitlab.com`.
+- `--agent-version=vX.Y.Z` with the latest released patch version matching your GitLab installation's major and minor versions. For example, for GitLab v13.9.0, use `--agent-version=v13.9.1`. You can find your GitLab version under the "Help/Help" menu.
```shell
-docker run --pull=always --rm registry.gitlab.com/gitlab-org/cluster-integration/gitlab-agent/cli:stable generate --agent-token=your-agent-token --kas-address=wss://kas.gitlab.example.com --agent-version stable --namespace gitlab-kubernetes-agent | kubectl apply -f -
+docker run --pull=always --rm registry.gitlab.com/gitlab-org/cluster-integration/gitlab-agent/cli:stable generate --agent-token=your-agent-token --kas-address=wss://kas.gitlab.example.com --agent-version=vX.Y.Z --namespace gitlab-kubernetes-agent | kubectl apply -f -
```
-Set `--agent-version` to the latest released patch version matching your
-GitLab installation's major and minor versions. For example, if you have
-GitLab v13.9.0, set `--agent-version=v13.9.1`.
-
WARNING:
-Version `stable` can be used to refer to the latest stable release at the time when the command runs. It's fine for
+`--agent-version stable` can be used to refer to the latest stable release at the time when the command runs. It's fine for
testing purposes but for production please make sure to specify a matching version explicitly.
To find out the various options the above Docker container supports, run:
@@ -287,7 +288,7 @@ spec:
containers:
- name: agent
# Make sure to specify a matching version for production
- image: "registry.gitlab.com/gitlab-org/cluster-integration/gitlab-agent/agentk:stable"
+ image: "registry.gitlab.com/gitlab-org/cluster-integration/gitlab-agent/agentk:vX.Y.Z
args:
- --token-file=/config/token
- --kas-address
@@ -383,29 +384,16 @@ Each time you push a change to a monitored manifest repository, the Agent logs t
#### Example manifest file
-This file creates an NGINX deployment.
+This file creates a minimal `ConfigMap`:
```yaml
-apiVersion: apps/v1
-kind: Deployment
+apiVersion: v1
+kind: ConfigMap
metadata:
- name: nginx-deployment
+ name: demo-map
namespace: gitlab-kubernetes-agent # Can be any namespace managed by you that the agent has access to.
-spec:
- selector:
- matchLabels:
- app: nginx
- replicas: 2
- template:
- metadata:
- labels:
- app: nginx
- spec:
- containers:
- - name: nginx
- image: nginx:1.14.2
- ports:
- - containerPort: 80
+data:
+ key: value
```
## Example projects
@@ -433,8 +421,8 @@ There are several components that work in concert for the Agent to generate the
- Enablement of [hubble-relay](https://docs.cilium.io/en/v1.8/concepts/overview/#hubble) on an
existing installation.
- One or more network policies through any of these options:
- - Use the [Container Network Policy editor](../../application_security/threat_monitoring/index.md#container-network-policy-editor) to create and manage policies.
- - Use an [AutoDevOps](../../application_security/threat_monitoring/index.md#container-network-policy-management) configuration.
+ - Use the [Container Network Policy editor](../../application_security/policies/index.md#container-network-policy-editor) to create and manage policies.
+ - Use an [AutoDevOps](../../application_security/policies/index.md#container-network-policy) configuration.
- Add the required labels and annotations to existing network policies.
- A configuration repository with [Cilium configured in `config.yaml`](repository.md#surface-network-security-alerts-from-cluster-to-gitlab)