diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2022-09-20 02:18:09 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2022-09-20 02:18:09 +0300 |
commit | 6ed4ec3e0b1340f96b7c043ef51d1b33bbe85fde (patch) | |
tree | dc4d20fe6064752c0bd323187252c77e0a89144b /doc/security/token_overview.md | |
parent | 9868dae7fc0655bd7ce4a6887d4e6d487690eeed (diff) |
Add latest changes from gitlab-org/gitlab@15-4-stable-eev15.4.0-rc42
Diffstat (limited to 'doc/security/token_overview.md')
-rw-r--r-- | doc/security/token_overview.md | 27 |
1 files changed, 13 insertions, 14 deletions
diff --git a/doc/security/token_overview.md b/doc/security/token_overview.md index a2119c86268..e585f2caeca 100644 --- a/doc/security/token_overview.md +++ b/doc/security/token_overview.md @@ -124,17 +124,16 @@ This table shows available scopes per token. Scopes can be limited further on to ## Security considerations -Access tokens should be treated like passwords and kept secure. - -Adding them to URLs is a security risk. This is especially true when cloning or adding a remote, as 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, API calls can be passed an access token using headers, like [the `Private-Token` header](../api/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 should 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. - -When creating a token, consider setting a token that expires when your task is complete. For example, if performing a one-off import, set the -token to expire after a few hours or a day. This reduces the impact of a token that is accidentally leaked because it is useless when it expires. +- 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). +- Tokens can also be stored using a [Git credential storage](https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage). +- Tokens should 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. +- When creating a token, consider setting a token that expires when your task is complete. For example, if performing a one-off import, set the + token to expire after a few hours or a day. This reduces the impact of a token that is accidentally leaked because it is useless when it expires. +- Be careful not to include tokens when pasting code, console commands, or log outputs into an issue or MR description or comment. +- Don’t log credentials in the console logs. Consider [protecting](../ci/variables/index.md#protected-cicd-variables) and + [masking](../ci/variables/index.md#mask-a-cicd-variable) your credentials. +- Review all currently active access tokens of all types on a regular basis and revoke any that are no longer needed. |