diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/api/settings.md | 1 | ||||
| -rw-r--r-- | doc/ci/environments.md | 35 | ||||
| -rw-r--r-- | doc/ci/yaml/README.md | 32 | ||||
| -rw-r--r-- | doc/user/admin_area/settings/account_and_limit_settings.md | 32 |
4 files changed, 100 insertions, 0 deletions
diff --git a/doc/api/settings.md b/doc/api/settings.md index ad9ffcbf872..185cce6353e 100644 --- a/doc/api/settings.md +++ b/doc/api/settings.md @@ -269,6 +269,7 @@ are listed in the descriptions of the relevant settings. | `max_artifacts_size` | integer | no | Maximum artifacts size in MB | | `max_attachment_size` | integer | no | Limit attachment size in MB | | `max_pages_size` | integer | no | Maximum size of pages repositories in MB | +| `max_personal_access_token_lifetime` | integer | no | **(ULTIMATE ONLY)** Maximum allowable lifetime for personal access tokens in days | | `metrics_enabled` | boolean | no | (**If enabled, requires:** `metrics_host`, `metrics_method_call_threshold`, `metrics_packet_size`, `metrics_pool_size`, `metrics_port`, `metrics_sample_interval` and `metrics_timeout`) Enable influxDB metrics. | | `metrics_host` | string | required by: `metrics_enabled` | InfluxDB host. | | `metrics_method_call_threshold` | integer | required by: `metrics_enabled` | A method call is only tracked when it takes longer than the given amount of milliseconds. | diff --git a/doc/ci/environments.md b/doc/ci/environments.md index bd989157486..6666b8d6145 100644 --- a/doc/ci/environments.md +++ b/doc/ci/environments.md @@ -303,6 +303,41 @@ You are not required to use the same prefix or only slashes (`/`) in the dynamic names. However, using this format will enable the [grouping similar environments](#grouping-similar-environments) feature. +### Configuring Kubernetes deployments + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/27630) in GitLab 12.6. + +If you are deploying to a [Kubernetes cluster](../user/project/clusters/index.md) +associated with your project, you can configure these deployments from your +`gitlab-ci.yml` file. + +The following configuration options are supported: + +- [`namespace`](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) + +In the following example, the job will deploy your application to the +`production` Kubernetes namespace. + +```yaml +deploy: + stage: deploy + script: + - echo "Deploy to production server" + environment: + name: production + url: https://example.com + kubernetes: + namespace: production + only: + - master +``` + +NOTE: **Note:** +Kubernetes configuration is not supported for Kubernetes clusters +that are [managed by GitLab](../user/project/clusters/index.md#gitlab-managed-clusters). +To follow progress on support for Gitlab-managed clusters, see the +[relevant issue](https://gitlab.com/gitlab-org/gitlab/issues/38054). + ### Complete example The configuration in this section provides a full development workflow where your app is: diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index 714de3bac36..8562dc646f1 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -1421,6 +1421,38 @@ The `stop_review_app` job is **required** to have the following keywords defined - `stage` should be the same as the `review_app` in order for the environment to stop automatically when the branch is deleted +#### `environment:kubernetes` + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/27630) in GitLab 12.6. + +The `kubernetes` block is used to configure deployments to a +[Kubernetes cluster](../../user/project/clusters/index.md) that is associated with your project. + +For example: + +```yaml +deploy: + stage: deploy + script: make deploy-app + environment: + name: production + kubernetes: + namespace: production +``` + +This will set up the `deploy` job to deploy to the `production` +environment, using the `production` +[Kubernetes namespace](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/). + +For more information, see +[Available settings for `kubernetes`](../environments.md#configuring-kubernetes-deployments). + +NOTE: **Note:** +Kubernetes configuration is not supported for Kubernetes clusters +that are [managed by GitLab](../../user/project/clusters/index.md#gitlab-managed-clusters). +To follow progress on support for Gitlab-managed clusters, see the +[relevant issue](https://gitlab.com/gitlab-org/gitlab/issues/38054). + #### Dynamic environments > - [Introduced][ce-6323] in GitLab 8.12 and GitLab Runner 1.6. diff --git a/doc/user/admin_area/settings/account_and_limit_settings.md b/doc/user/admin_area/settings/account_and_limit_settings.md index e443127a8a0..9d82b3b4292 100644 --- a/doc/user/admin_area/settings/account_and_limit_settings.md +++ b/doc/user/admin_area/settings/account_and_limit_settings.md @@ -84,3 +84,35 @@ add the line below to `/etc/gitlab/gitlab.rb` before increasing the max attachme ``` nginx['client_max_body_size'] = "200m" ``` + +## Limiting lifetime of personal access tokens **(ULTIMATE ONLY)** + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/3649) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.6. + +Users can optionally specify an expiration date for +[personal access tokens](../../profile/personal_access_tokens.md). +This expiration date is not a requirement, and can be set to any arbitrary date. + +Since personal access tokens are the only token needed for programmatic access to GitLab, +organizations with security requirements may want to enforce more protection to require +regular rotation of these tokens. + +### Setting a limit + +Only a GitLab administrator can set a limit. Leaving it empty means +there are no restrictions. + +To set a limit on how long personal access tokens are valid: + +1. Navigate to **Admin Area > Settings > General**. +1. Expand the **Account and limit** section. +1. Fill in the **Maximun allowable lifetime for personal access tokens (days)** field. +1. Click **Save changes**. + +Once a lifetime for personal access tokens is set, GitLab will: + +- Apply the lifetime for new personal access tokens, and require users to set an expiration date + and a date no later than the allowed lifetime. +- After three hours, revoke old tokens with no expiration date or with a lifetime longer than the + allowed lifetime. Three hours is given to allow administrators to change the allowed lifetime, + or remove it, before revocation takes place. |