Welcome to mirror list, hosted at ThFree Co, Russian Federation.

gitlab.com/gitlab-org/gitlab-foss.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat (limited to 'doc/security/token_overview.md')
-rw-r--r--doc/security/token_overview.md30
1 files changed, 27 insertions, 3 deletions
diff --git a/doc/security/token_overview.md b/doc/security/token_overview.md
index 64336f96274..a36d72f128d 100644
--- a/doc/security/token_overview.md
+++ b/doc/security/token_overview.md
@@ -28,7 +28,7 @@ You can limit the scope and lifetime of your OAuth2 tokens.
## Impersonation tokens
-An [Impersonation token](../api/index.md#impersonation-tokens) is a special type of personal access
+An [Impersonation token](../api/rest/index.md#impersonation-tokens) is a special type of personal access
token. It can be created only by an administrator for a specific user. Impersonation tokens can
help you build applications or scripts that authenticate with the GitLab API, repositories, and the GitLab registry as a specific user.
@@ -74,7 +74,14 @@ This is useful, for example, for cloning repositories to your Continuous Integra
Project maintainers and owners can add or enable a deploy key for a project repository
-## Runner registration tokens
+## Runner registration tokens (deprecated)
+
+WARNING:
+The ability to pass a runner registration token was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/380872) in GitLab 15.6 and is
+planned for removal in 17.0, along with support for certain configuration arguments. This change is a breaking change. GitLab plans to introduce a new
+[GitLab Runner token architecture](../architecture/blueprints/runner_tokens/index.md), which introduces
+a new method for registering runners and eliminates the
+runner registration token.
Runner registration tokens are used to [register](https://docs.gitlab.com/runner/register/) a [runner](https://docs.gitlab.com/runner/) with GitLab. Group or project owners or instance administrators can obtain them through the GitLab user interface. The registration token is limited to runner registration and has no further scope.
@@ -100,6 +107,23 @@ triggering the job.
The job token is secured by its short life-time and limited scope. It could possibly be leaked if multiple jobs run on the same machine ([like with the shell runner](https://docs.gitlab.com/runner/security/#usage-of-shell-executor)). On Docker Machine runners, configuring [`MaxBuilds=1`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runnersmachine-section) is recommended to make sure runner machines only ever run one build and are destroyed afterwards. This may impact performance, as provisioning machines takes some time.
+## Other tokens
+
+### Feed token
+
+Each user has a long-lived feed token that does not expire. This token allows authentication for:
+
+- RSS readers to load a personalized RSS feed.
+- Calendar applications to load a personalized calendar.
+
+This token is visible in those feed URLs. You cannot use this token to access any other data.
+
+Anyone who has your token can read activity and issue RSS feeds or your calendar feed as if they were you, including confidential issues. If that happens, [reset the token](../user/profile/contributions_calendar.md#reset-the-user-activity-feed-token).
+
+### Incoming email token
+
+Each user has a long-lived incoming email token that does not expire. This token allows a user to [create a new issue by email](../user/project/issues/create_issues.md#by-sending-an-email), and is included in that user's personal project-specific email addresses. You cannot use this token to access any other data. Anyone who has your token can create issues and merge requests as if they were you. If that happens, reset the token.
+
## Available scopes
This table shows available scopes per token. Scopes can be limited further on token creation.
@@ -127,7 +151,7 @@ This table shows available scopes per token. Scopes can be limited further on to
- Access tokens should be treated like passwords and kept secure.
- Adding access tokens to URLs is a security risk, especially when cloning or adding a remote because Git then writes the URL to its `.git/config` file in plain text. URLs are
also generally logged by proxies and application servers, which makes those credentials visible to system administrators. Instead, pass API calls an access token using
- headers like [the `Private-Token` header](../api/index.md#personalprojectgroup-access-tokens).
+ headers like [the `Private-Token` header](../api/rest/index.md#personalprojectgroup-access-tokens).
- Tokens can also be stored using a [Git credential storage](https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage).
- Tokens must not be committed to your source code. Instead, consider an approach such as [using external secrets in CI](../ci/secrets/index.md).
- When creating a scoped token, consider using the most limited scope possible to reduce the impact of accidentally leaking the token.