root
/
gitlab-ce
mirror of https://gitlab.com/free-releases/gitlab-ce.git
1
0
Fork 0
Code Issues Actions Packages Projects Releases Wiki Activity

Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2025-06-05 06:07:16 +00:00
parent ed06be76e4
commit a4308a3876
230 changed files with 12256 additions and 2022 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
app/assets/javascripts/todos/components/queries/todo.fragment.graphql
View File

@ -4,6 +4,7 @@ fragment Todo on Todo {
snoozedUntil
createdAt
action
body
targetType
targetUrl
memberAccessType

4
app/assets/javascripts/todos/components/todo_item_body.vue
View File

@ -162,9 +162,7 @@ export default {
}
if (DUO_ACCESS_GRANTED_ACTIONS.includes(this.todo.action)) {
name = s__(
'Todos|You now have access to AI-native features. Learn how to set up Code Suggestions and Chat in your IDE',
);
name = this.todo.body;
}
if (!name) {

4
app/assets/javascripts/vue_shared/components/markdown/markdown_editor.vue
View File

@ -194,7 +194,9 @@ export default {
mounted() {
this.autofocusTextarea();
this.$emit('input', this.markdown);
// Second argument (`true`) is passed to identify
// that the input event was emitted on component mount.
this.$emit('input', this.markdown, true);
this.saveDraft();
this.setFacade?.({

28
app/assets/javascripts/work_items/components/create_work_item.vue
View File

@ -273,15 +273,15 @@ export default {
?.textContent.trim();
for await (const workItemType of this.workItemTypes) {
await setNewWorkItemCache(
this.selectedProjectFullPath,
workItemType?.widgetDefinitions,
workItemType.name,
workItemType.id,
workItemType.iconName,
await setNewWorkItemCache({
fullPath: this.selectedProjectFullPath,
widgetDefinitions: workItemType?.widgetDefinitions,
workItemType: workItemType.name,
workItemTypeId: workItemType.id,
workItemTypeIconName: workItemType.iconName,
workItemTitle,
workItemDescription,
);
});
}
const selectedWorkItemType = this.workItemTypes?.find(
@ -856,13 +856,13 @@ export default {
const selectedWorkItemWidgets = this.selectedWorkItemType?.widgetDefinitions || [];
setNewWorkItemCache(
this.selectedProjectFullPath,
selectedWorkItemWidgets,
this.selectedWorkItemTypeName,
this.selectedWorkItemTypeId,
this.selectedWorkItemTypeIconName,
);
setNewWorkItemCache({
fullPath: this.selectedProjectFullPath,
workItemWidgetDefinitions: selectedWorkItemWidgets,
workItemType: this.selectedWorkItemTypeName,
workItemTypeId: this.selectedWorkItemTypeId,
workItemTypeIconName: this.selectedWorkItemTypeIconName,
});
},
onParentMilestone(parentMilestone) {
this.selectedParentMilestone = parentMilestone;

10
app/assets/javascripts/work_items/components/work_item_description.vue
View File

@ -412,9 +412,15 @@ export default {
this.conflictedDescription = '';
this.initialDescriptionText = this.descriptionText;
},
setDescriptionText(newText) {
setDescriptionText(newText, onMountInit = false) {
this.descriptionText = newText;
this.$emit('updateDraft', this.descriptionText);
// Ensure that we don't update the draft on mount during create mode as
// it will otherwise overwrite localStorage and previously saved data
// will be lost. See vue_shared/components/markdown/markdown_editor.vue
// mounted hook where onMountInit boolean is passed with $emit('input').
if (!onMountInit || !this.isCreateFlow) {
this.$emit('updateDraft', this.descriptionText);
}
updateDraft(this.autosaveKey, this.descriptionText);
},
handleDescriptionTextUpdated(newText) {

70
app/assets/javascripts/work_items/graphql/cache_utils.js
View File

@ -33,6 +33,15 @@ import {
import {
findCurrentUserTodosWidget,
findDescriptionWidget,
findAssigneesWidget,
findLabelsWidget,
findWeightWidget,
findCrmContactsWidget,
findMilestoneWidget,
findIterationWidget,
findStartAndDueDateWidget,
findHealthStatusWidget,
findCustomFieldsWidget,
findHierarchyWidget,
findHierarchyWidgetChildren,
findNotesWidget,
@ -40,6 +49,8 @@ import {
isNotesWidget,
newWorkItemFullPath,
newWorkItemId,
findColorWidget,
findStatusWidget,
} from '../utils';
import workItemByIidQuery from './work_item_by_iid.query.graphql';
import workItemByIdQuery from './work_item_by_id.query.graphql';
@ -305,7 +316,7 @@ export const updateWorkItemCurrentTodosWidget = ({ cache, fullPath, iid, todos }
cache.writeQuery({ ...query, data: newData });
};
export const setNewWorkItemCache = async (
export const setNewWorkItemCache = async ({
fullPath,
widgetDefinitions,
workItemType,
@ -313,8 +324,7 @@ export const setNewWorkItemCache = async (
workItemTypeIconName,
workItemTitle = '',
workItemDescription = '',
// eslint-disable-next-line max-params
) => {
}) => {
const workItemAttributesWrapperOrder = [
WIDGET_TYPE_STATUS,
WIDGET_TYPE_ASSIGNEES,
@ -376,7 +386,9 @@ export const setNewWorkItemCache = async (
allowsMultipleAssignees: assigneesWidgetData.allowsMultipleAssignees || false,
canInviteMembers: assigneesWidgetData.canInviteMembers || false,
assignees: {
nodes: [],
nodes: draftData
? findAssigneesWidget(draftData?.workspace?.workItem)?.assignees.nodes || []
: [],
__typename: 'UserCoreConnection',
},
__typename: 'WorkItemWidgetAssignees',
@ -400,7 +412,9 @@ export const setNewWorkItemCache = async (
type: 'CRM_CONTACTS',
contactsAvailable: false,
contacts: {
nodes: [],
nodes: draftData
? findCrmContactsWidget(draftData?.workspace?.workItem)?.contacts.nodes || []
: [],
__typename: 'CustomerRelationsContactConnection',
},
__typename: 'WorkItemWidgetCrmContacts',
@ -415,7 +429,9 @@ export const setNewWorkItemCache = async (
type: 'LABELS',
allowsScopedLabels: labelsWidgetData.allowsScopedLabels,
labels: {
nodes: [],
nodes: draftData
? findLabelsWidget(draftData?.workspace?.workItem)?.labels.nodes || []
: [],
__typename: 'LabelConnection',
},
__typename: 'WorkItemWidgetLabels',
@ -429,7 +445,9 @@ export const setNewWorkItemCache = async (
widgets.push({
type: 'WEIGHT',
weight: null,
weight: draftData
? findWeightWidget(draftData?.workspace?.workItem)?.weight || null
: null,
rolledUpWeight: 0,
rolledUpCompletedWeight: 0,
widgetDefinition: {
@ -443,7 +461,9 @@ export const setNewWorkItemCache = async (
if (widgetName === WIDGET_TYPE_MILESTONE) {
widgets.push({
type: 'MILESTONE',
milestone: null,
milestone: draftData
? findMilestoneWidget(draftData?.workspace?.workItem)?.milestone || null
: null,
projectMilestone: false,
__typename: 'WorkItemWidgetMilestone',
});
@ -451,18 +471,24 @@ export const setNewWorkItemCache = async (
if (widgetName === WIDGET_TYPE_ITERATION) {
widgets.push({
iteration: null,
iteration: draftData
? findIterationWidget(draftData?.workspace?.workItem)?.iteration || null
: null,
type: 'ITERATION',
__typename: 'WorkItemWidgetIteration',
});
}
if (widgetName === WIDGET_TYPE_START_AND_DUE_DATE) {
const startDueDateDraft = draftData
? findStartAndDueDateWidget(draftData?.workspace?.workItem)
: {};
widgets.push({
type: 'START_AND_DUE_DATE',
dueDate: null,
startDate: null,
isFixed: false,
dueDate: startDueDateDraft?.dueDate || null,
startDate: startDueDateDraft?.startDate || null,
isFixed: startDueDateDraft?.isFixed || false,
rollUp: false,
__typename: 'WorkItemWidgetStartAndDueDate',
});
@ -480,7 +506,9 @@ export const setNewWorkItemCache = async (
if (widgetName === WIDGET_TYPE_HEALTH_STATUS) {
widgets.push({
type: 'HEALTH_STATUS',
healthStatus: null,
healthStatus: draftData
? findHealthStatusWidget(draftData?.workspace?.workItem)?.healthStatus || null
: null,
rolledUpHealthStatus: [],
__typename: 'WorkItemWidgetHealthStatus',
});
@ -489,7 +517,9 @@ export const setNewWorkItemCache = async (
if (widgetName === WIDGET_TYPE_COLOR) {
widgets.push({
type: 'COLOR',
color: '#1068bf',
color: draftData
? findColorWidget(draftData?.workspace?.workItem)?.color || '#1068bf'
: '#1068bf',
textColor: '#FFFFFF',
__typename: 'WorkItemWidgetColor',
});
@ -501,7 +531,9 @@ export const setNewWorkItemCache = async (
);
widgets.push({
type: 'STATUS',
status: defaultOpenStatus,
status: draftData
? findStatusWidget(draftData?.workspace?.workItem)?.status || defaultOpenStatus
: defaultOpenStatus,
__typename: 'WorkItemWidgetStatus',
});
}
@ -511,7 +543,9 @@ export const setNewWorkItemCache = async (
type: 'HIERARCHY',
hasChildren: false,
hasParent: false,
parent: null,
parent: draftData
? findHierarchyWidget(draftData?.workspace?.workItem)?.parent || null
: null,
depthLimitReachedByType: [],
rolledUpCountsByType: [],
children: {
@ -542,7 +576,9 @@ export const setNewWorkItemCache = async (
widgets.push({
type: WIDGET_TYPE_CUSTOM_FIELDS,
customFieldValues: customFieldsWidgetData?.customFieldValues ?? [],
customFieldValues: draftData
? findCustomFieldsWidget(draftData?.workspace?.workItem)?.customFieldValues || []
: customFieldsWidgetData?.customFieldValues ?? [],
__typename: 'WorkItemWidgetCustomFields',
});
}

14
app/assets/javascripts/work_items/graphql/resolvers.js
View File

@ -4,7 +4,6 @@ import * as Sentry from '~/sentry/sentry_browser_wrapper';
import { findWidget } from '~/issues/list/utils';
import { newDate, toISODateFormat } from '~/lib/utils/datetime_utility';
import { updateDraft } from '~/lib/utils/autosave';
import { getParameterByName } from '~/lib/utils/url_utility';
import {
findCustomFieldsWidget,
findStartAndDueDateWidget,
@ -201,18 +200,7 @@ export const updateNewWorkItemCache = (input, cache) => {
const isQueryDataValid = !isEmpty(newData) && newData?.workspace?.workItem;
const isWorkItemToResolveDiscussion = getParameterByName(
'merge_request_to_resolve_discussions_of',
);
const isNewIssueForVulnerability = getParameterByName('vulnerability_id');
if (
isQueryDataValid &&
autosaveKey &&
!isWorkItemToResolveDiscussion &&
!isNewIssueForVulnerability
) {
if (isQueryDataValid && autosaveKey) {
updateDraft(autosaveKey, JSON.stringify(newData));
}
} catch (e) {

5
app/assets/javascripts/work_items/utils.js
View File

@ -401,6 +401,11 @@ export const makeDrawerUrlParam = (activeItem, fullPath, issuableType = TYPE_ISS
export const getNewWorkItemAutoSaveKey = (fullPath, workItemType) => {
if (!workItemType || !fullPath) return '';
const queryParamString = new URLSearchParams(window.location.search).toString();
if (queryParamString) {
return `new-${fullPath}-${workItemType.toLowerCase()}-${queryParamString}-draft`;
}
return `new-${fullPath}-${workItemType.toLowerCase()}-draft`;
};

283
doc-locale/ja-jp/ci/testing/code_coverage/_index.md Normal file
View File

@ -0,0 +1,283 @@
---
stage: Verify
group: Pipeline Execution
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: コードカバレッジ
---
{{< details >}}
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
{{< /details >}}
テストでカバーされているソースコードの量を追跡および可視化するようにコードカバレッジを設定します。以下を実行できます。
- `coverage`キーワードを使用して、全体的なカバレッジのメトリクスと傾向を追跡します。
- `artifacts:reports:coverage_report`キーワードを使用して、行ごとのカバレッジを可視化します。
## カバレッジレポートを設定する
[`coverage`](../../yaml/_index.md#coverage)キーワードを使用して、テストカバレッジを監視し、マージリクエストでカバレッジ要件を適用します。
カバレッジレポートでは、次のことが可能です。
- マージリクエストで全体的なカバレッジの割合を表示します。
- 複数のテストジョブからカバレッジを集約します。
- カバレッジチェックの承認ルールを追加します。
- 経時的なカバレッジの傾向を追跡します。
カバレッジレポートを設定するには:
1. `coverage`キーワードをパイプライン設定に追加します。
```yaml
test-unit:
script:
- coverage run unit/
coverage: '/TOTAL.+ ([0-9]{1,3}%)/'
test-integration:
script:
- coverage run integration/
coverage: '/TOTAL.+ ([0-9]{1,3}%)/'
```
1. テスト出力形式に一致するように正規表現（regex）を設定します。一般的なパターンについては、「[カバレッジの正規表現パターン](#coverage-regex-patterns)」を参照してください。
1. 複数のジョブからカバレッジを集約するには、含める各ジョブに`coverage`キーワードを追加します。
1. オプション: [カバレッジチェックの承認ルールを追加](#add-a-coverage-check-approval-rule)します。
### カバレッジの正規表現パターン
次のサンプル正規表現パターンは、一般的なテストカバレッジツールからのカバレッジ出力を解析するように設計されています。
正規表現パターンを注意深くテストしてください。ツールの出力形式は時間とともに変化する可能性があり、これらのパターンは期待どおりに動作しなくなる可能性があります。
<!-- vale gitlab_base.Spelling = NO -->
<!-- markdownlint-disable MD056 -->
<!-- Verify regex patterns on docs.gitlab.com as escape characters render differently than in `.md` files rendered via GitLab code browser -->
{{< tabs >}}
{{< tab title="PythonとRuby" >}}
| ツール | 言語 | コマンド | 正規表現パターン |
|------------|----------|----------------|---------------|
| pytest-cov | Python | `pytest --cov` | `/TOTAL.*? (100(?:\.0+)?\%\|[1-9]?\d(?:\.\d+)?\%)$/` |
| Simplecov | Ruby | `rspec spec` | `/\(\d+.\d+\%\) covered/` |
{{< /tab >}}
{{< tab title="C/C++とRust" >}}
| ツール | 言語 | コマンド | 正規表現パターン |
|-----------|----------|-------------------|---------------|
| gcovr | C/C++ | `gcovr` | `/^TOTAL.*\s+(\d+\%)$/` |
| tarpaulin | Rust | `cargo tarpaulin` | `/^\d+.\d+% coverage/` |
{{< /tab >}}
{{< tab title="JavaとJVM" >}}
| ツール | 言語 | コマンド | 正規表現パターン |
|-----------|-------------|------------------------------------|---------------|
| JaCoCo | Java/Kotlin | `./gradlew test jacocoTestReport` | `/Total.*?([0-9]{1,3})%/` |
| Scoverage | Scala | `sbt coverage test coverageReport` | `/(?i)total.*? (100(?:\.0+)?\%\|[1-9]?\d(?:\.\d+)?\%)$/` |
{{< /tab >}}
{{< tab title="Node.js" >}}
| ツール | コマンド | 正規表現パターン |
|------|--------------------------------------|---------------|
| tap | `tap --coverage-report=text-summary` | `/^Statements\s*:\s*([^%]+)/` |
| nyc | `nyc npm test` | `/All files[^\|]*\|[^\|]*\s+([\d\.]+)/` |
| jest | `jest --ci --coverage` | `/All files[^\|]*\|[^\|]*\s+([\d\.]+)/` |
{{< /tab >}}
{{< tab title="PHP" >}}
| ツール | コマンド | 正規表現パターン |
|---------|------------------------------------------|---------------|
| pest | `pest --coverage --colors=never` | `/Statement coverage[A-Za-z\.*]\s*:\s*([^%]+)/` |
| phpunit | `phpunit --coverage-text --colors=never` | `/^\s*Lines:\s*\d+.\d+\%/` |
{{< /tab >}}
{{< tab title="Go" >}}
| ツール | コマンド | 正規表現パターン |
|-------------------|------------------|---------------|
| go test（シングル） | `go test -cover` | `/coverage: \d+.\d+% of statements/` |
| go test（プロジェクト） | `go test -coverprofile=cover.profile && go tool cover -func cover.profile` | `/total:\s+\(statements\)\s+\d+.\d+%/` |
{{< /tab >}}
{{< tab title=".NETとPowerShell" >}}
| ツール | 言語 | コマンド | 正規表現パターン |
|-----------|------------|---------|---------------|
| OpenCover | .NET | なし | `/(Visited Points).*\((.*)\)/` |
| dotnet test（[MSBuild](https://github.com/coverlet-coverage/coverlet/blob/master/Documentation/MSBuildIntegration.md)） | .NET | `dotnet test` | `/Total\s*\\|*\s(\d+(?:\.\d+)?)/` |
| Pester | PowerShell | なし | `/Covered (\d+\.\d+%)/` |
{{< /tab >}}
{{< tab title="Elixir" >}}
| ツール | コマンド | 正規表現パターン |
|-------------|--------------------|---------------|
| excoveralls | なし | `/\[TOTAL\]\s+(\d+\.\d+)%/` |
| mix | `mix test --cover` | `/\d+.\d+\%\s+\|\s+Total/` |
{{< /tab >}}
{{< /tabs >}}
<!-- vale gitlab_base.Spelling = YES -->
<!-- markdownlint-enable MD056 -->
## カバレッジの可視化
[`artifacts:reports:coverage_report`](../../yaml/artifacts_reports.md#artifactsreportscoverage_report)キーワードを使用して、マージリクエスト内のテストでカバーされる特定のコード行を表示します。
次の形式でカバレッジレポートを生成できます。
- Cobertura: Java、JavaScript、Python、Rubyなどの複数の言語に対応
- JaCoCo: Javaプロジェクトにのみ対応
カバレッジの可視化では、[アーティファクトレポート](../../yaml/_index.md#artifactsreports)を使用して次のことを行います。
1. ワイルドカードパスなど、1つ以上のカバレッジレポートを収集します。
1. すべてのレポートからのカバレッジ情報を結合します。
1. 結合された結果をマージリクエストの差分に表示します。
カバレッジファイルはバックグラウンドジョブで解析されるため、パイプラインの完了から可視化がマージリクエストに表示されるまでに遅延が発生する可能性があります。
デフォルトでは、カバレッジの可視化データは作成から1週間で期限切れになります。
### カバレッジの可視化を設定する
カバレッジの可視化を設定するには:
1. カバレッジレポートを生成するようにテストツールを設定します。
1. `artifacts:reports:coverage_report`設定をパイプラインに追加します。
```yaml
test:
script:
- run tests with coverage
artifacts:
reports:
coverage_report:
coverage_format: cobertura # or jacoco
path: coverage/coverage.xml
```
言語固有の設定の詳細については、以下を参照してください。
- [Coberturaカバレッジレポート](cobertura.md)
- [JaCoCoカバレッジレポート](jacoco.md)
### 子パイプラインからのカバレッジレポート
{{< history >}}
- GitLab 15.1で、`ci_child_pipeline_coverage_reports`という名前の[フラグとともに](../../../administration/feature_flags.md)[導入](https://gitlab.com/gitlab-org/gitlab/-/issues/363301)されました。デフォルトでは無効になっています。
- GitLab 15.2の[GitLab.comとGitLab Self-Managedで有効](https://gitlab.com/gitlab-org/gitlab/-/issues/363557)になり、機能フラグ`ci_child_pipeline_coverage_reports`が削除されました。
{{< /history >}}
子パイプラインで生成されたカバレッジレポートは、親パイプラインのカバレッジレポートに含まれます。次に例を示します。
```yaml
child_test_pipeline:
trigger:
include:
- local: path/to/child_pipeline_with_coverage.yml
```
## カバレッジチェックの承認ルールを追加する
{{< details >}}
- プラン: Premium、Ultimate
{{< /details >}}
プロジェクトのテストカバレッジを低下させるマージリクエストを承認するように、特定のユーザーまたはグループに要求できます。
前提要件:
- [カバレッジレポートを設定](#configure-coverage-reporting)していること。
`Coverage-Check`承認ルールを追加するには:
1. プロジェクトに移動し、**設定>マージリクエスト**を選択します。
1. **マージリクエストの承認**で、次のいずれかを実行します。
- `Coverage-Check`承認ルールの横にある**有効化**を選択します。
- 手動セットアップの場合は、**承認ルールを追加**を選択し、**ルール名**を入力します。例: `Coverage Check`。
1. **ターゲットブランチ**を選択します。
1. **必要な承認数**を設定します。
1. 承認を提供する**ユーザー**または**グループ**を選択します。
1. **変更の保存**を選択します。
## カバレッジ結果を表示する
パイプラインが正常に実行された後、次の場所にコードカバレッジの結果を表示できます。
- マージリクエストウィジェット: ターゲットブランチと比較して、カバレッジの割合と変更を確認します。
![コードカバレッジの割合を示すマージリクエストウィジェット](../img/pipelines_test_coverage_mr_widget_v17_3.png)
- マージリクエストの差分: どの行がテストでカバーされているかを確認します。CoberturaレポートおよびJaCoCoレポートで使用できます。
- パイプラインジョブ: 個々のジョブのカバレッジ結果を監視します。
## カバレッジ履歴を表示する
プロジェクトまたはグループのコードカバレッジの進化を経時的に追跡できます。
### プロジェクトの場合
プロジェクトのコードカバレッジ履歴を表示するには:
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトを検索します。
1. **分析>リポジトリ分析**を選択します。
1. ドロップダウンリストから、履歴データを表示するジョブを選択します。
1. オプション: データのCSVファイルを表示するには、**元のデータをダウンロード（.csv）**を選択します。
### グループの場合
{{< details >}}
- プラン: Premium、Ultimate
{{< /details >}}
グループ内のすべてのプロジェクトのコードカバレッジ履歴を表示するには:
1. 左側のサイドバーで、**検索または移動**を選択し、グループを検索します。
1. **分析>リポジトリ分析**を選択します。
1. オプション: データのCSVファイルを表示するには、**過去のテストカバレッジデータをCSV形式でダウンロード**を選択します。
## カバレッジバッジを表示する
パイプラインバッジを使用して、プロジェクトのコードカバレッジの状態を共有します。
プロジェクトにカバレッジバッジを追加するには、「[テストカバレッジレポートバッジ](../../../user/project/badges.md#test-coverage-report-badges)」を参照してください。
## トラブルシューティング
### コードカバレッジからカラーコードを削除する
一部のテストカバレッジツールは、正規表現で正しく解析されないANSIカラーコードで出力します。これにより、カバレッジの解析が失敗します。
一部のカバレッジツールには、出力のカラーコードを無効にするオプションがありません。その場合は、カラーコードを削除する1行のスクリプトによってカバレッジツールの出力をパイプします。
次に例を示します。
```shell
lein cloverage | perl -pe 's/\e\[?.*?[\@-~]//g'
```

8
doc-locale/ja-jp/ci/testing/code_coverage/cobertura.md Normal file
View File

@ -0,0 +1,8 @@
---
stage: Verify
group: Pipeline Execution
info: Placeholder text
title: Placeholder text
---
<!-- Placeholder until translations are done -->

8
doc-locale/ja-jp/ci/testing/code_coverage/jacoco.md Normal file
View File

@ -0,0 +1,8 @@
---
stage: Verify
group: Pipeline Execution
info: Placeholder text
title: Placeholder text
---
<!-- Placeholder until translations are done -->

154
doc-locale/ja-jp/ci/testing/unit_test_reports.md Normal file
View File

@ -0,0 +1,154 @@
---
stage: Verify
group: Pipeline Execution
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: 単体テストレポート
---
{{< details >}}
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
{{< /details >}}
[CI/CD パイプライン](../pipelines/_index.md)を設定して、単体テストの結果をマージリクエストとパイプラインの詳細に直接表示できます。これにより、ジョブログを検索しなくても、テストの失敗を簡単に特定できます。
単体テストレポート:
- JUnitレポート形式が必要です。
- ジョブステータスには影響しません。単体テストが失敗した場合にジョブを失敗にするには、ジョブの[スクリプト](../yaml/_index.md#script)を0以外のステータスで終了する必要があります。
次のワークフローを検討してください。
1. デフォルトブランチは非常に安定しています。プロジェクトはGitLab CI/CDを使用しており、パイプラインに何も問題がないことが示されています。
1. チームの誰かがマージリクエストを送信すると、テストが失敗し、パイプラインにおなじみの赤いアイコンが表示されます。さらに調査するには、ジョブログを調べて失敗したテストの原因を突き止める必要があります。通常、ジョブログには何千行もの行が含まれています。
1. 単体テストレポートを設定すると、GitLabはすぐにそれらを収集してマージリクエストで公開します。ジョブログ内を検索する必要はありません。
1. 開発とデバッグのワークフローがより簡単、高速かつ効率的になります。
## 仕組み
まず、GitLab Runnerはすべての[JUnitレポート形式のXMLファイル](https://www.ibm.com/docs/en/developer-for-zos/16.0?topic=formats-junit-xml-format)を[アーティファクト](../yaml/artifacts_reports.md#artifactsreportsjunit)としてGitLabにアップロードします。次に、マージリクエストにアクセスすると、GitLabはheadブランチとbaseブランチのJUnitレポート形式のXMLファイルの比較を開始します。ここで、次のようになります。
- ベースブランチはターゲットブランチです（通常はデフォルトブランチ）。
- ヘッドブランチはソースブランチです（各マージリクエストの最新のパイプライン）。
**テストのサマリー**パネルには、失敗したテストの数、エラーが発生したテストの数、修正されたテストの数が表示されます。ベースブランチのデータが利用できないために比較を実行できない場合、パネルにはソースブランチの失敗したテストのリストのみが表示されます。
結果の種類は次のとおりです。
- **新たに失敗したテスト:** ベースブランチでは合格したが、ヘッドブランチでは失敗したテストケース
- **新しく発生したエラー:** ベースブランチでは合格したが、ヘッドブランチではテストエラーが原因で失敗したテストケース
- **既存の失敗:** ベースブランチで失敗し、ヘッドブランチでも失敗したテストケース
- **解決済みの失敗:** ベースブランチでは失敗したが、ヘッドブランチでは合格したテストケース
### 失敗したテストを表示する
**テストのサマリー**パネルの各エントリには、テスト名と結果の種類が表示されます。テスト名を選択すると、実行時間とエラー出力の詳細を示すモーダルウィンドウが開きます。
![テストレポートウィジェット](img/junit_test_report_v13_9.png)
#### 失敗したテスト名をコピーする
{{< history >}}
- GitLab 15.2で[導入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/91552)されました。
{{< /history >}}
**テストのサマリー**パネルに失敗したテストがリストされている場合は、失敗したテストの名前とパスをコピーできます。名前とパスを使用して、検証のためにローカルでテストを検索して再実行します。
すべての失敗したテストの名前をコピーするには、**テストのサマリー**パネルの上部にある**失敗したテストをコピー**を選択します。失敗したテストは、テストがスペースで区切られた文字列としてリストされます。このオプションは、JUnitレポートが失敗したテストの`<file>`属性に値を入力する場合にのみ使用できます。
単一の失敗したテストの名前をコピーするには:
1. **テストのサマリーの詳細を表示**（{{< icon name="chevron-lg-down" >}}）を選択して、**テストのサマリー**パネルを展開します。
1. レビューするテストを選択します。
1. **ローカルで再実行するためにテスト名をコピー**（{{< icon name="copy-to-clipboard" >}}）を選択します。
### 最近の失敗回数
プロジェクトのデフォルトブランチで過去14日間にテストが失敗した場合、`Failed {n} time(s) in {default_branch} in the last 14 days`のようなメッセージがそのテストに対して表示されます。
計算には、完了したパイプラインで失敗したテストが含まれますが、[ブロックされたパイプライン](../jobs/job_control.md#types-of-manual-jobs)で失敗したテストは含まれません。[イシュー431265](https://gitlab.com/gitlab-org/gitlab/-/issues/431265)では、ブロックされたパイプラインも計算に追加することが提案されています。
## 設定方法
マージリクエストで単体テストレポートを有効にするには、`.gitlab-ci.yml`に[`artifacts:reports:junit`](../yaml/artifacts_reports.md#artifactsreportsjunit)を追加し、生成されたテストレポートのパスを指定する必要があります。レポートは`.xml`ファイルである必要があります。そうでない場合、[GitLabはエラー500を返します](https://gitlab.com/gitlab-org/gitlab/-/issues/216575)。
Rubyの次の例では、`test`ステージのジョブが実行され、GitLabはジョブから単体テストレポートを収集します。ジョブが実行されると、XMLレポートはアーティファクトとしてGitLabに保存され、結果はマージリクエストウィジェットに表示されます。
```yaml
## Use https://github.com/sj26/rspec_junit_formatter to generate a JUnit report format XML file with rspec
ruby:
stage: test
script:
- bundle install
- bundle exec rspec --format progress --format RspecJunitFormatter --out rspec.xml
artifacts:
when: always
paths:
- rspec.xml
reports:
junit: rspec.xml
```
単体テストレポートの出力ファイルを参照できるようにするには、例に示すように、[`artifacts:paths`](../yaml/_index.md#artifactspaths)キーワードも使用します。ジョブが失敗した場合（テストに合格しなかった場合など）もレポートをアップロードするには、[`artifacts:when:always`](../yaml/_index.md#artifactswhen)キーワードを使用します。
JUnitレポート形式のXMLファイルに、同じ名前とクラスを持つ複数のテストを含めることはできません。
GitLab 15.0以前では、[parallel:matrix](../yaml/_index.md#parallelmatrix)ジョブのテストレポートが集約されるため、一部のレポート情報が表示されない場合があります。GitLab 15.1以降では、[このバグは修正](https://gitlab.com/gitlab-org/gitlab/-/issues/296814)され、すべてのレポート情報が表示されます。
## GitLabで単体テストレポートを表示する
JUnitレポート形式のXMLファイルがパイプラインの一部として生成およびアップロードされる場合、これらのレポートはパイプラインの詳細ページ内で確認できます。このページの**テスト**タブには、XMLファイルから報告されたテストスイートとテストケースのリストが表示されます。
![テストレポートウィジェット](img/pipelines_junit_test_report_v13_10.png)
既知のすべてのテストスイートを表示し、各スイートを選択して、スイートを構成するケースなどの詳細を確認できます。
[GitLab API](../../api/pipelines.md#get-a-pipelines-test-report)経由でレポートを取得することもできます。
### 単体テストレポートの解析エラー
JUnitレポートXMLの解析でエラーが発生した場合、ジョブ名の横にインジケーターが表示されます。アイコンにカーソルをおくと、ツールチップにパーサーエラーが表示されます。複数の解析エラーが[グループ化されたジョブ](../jobs/_index.md#group-similar-jobs-together-in-pipeline-views)から発生している場合、GitLabはグループからの最初のエラーのみを表示します。
![エラーを含むテストレポート](img/pipelines_junit_test_report_with_errors_v13_10.png)
テストケースの解析制限については、[単体テストレポートごとの最大テストケース数](../../user/gitlab_com/_index.md#cicd)を参照してください。
GitLabはJUnitレポートの非常に[大きなノード](https://nokogiri.org/tutorials/parsing_an_html_xml_document.html#parse-options)を解析しません。これをオプションにするための[イシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/268035)がオープンされています。
## GitLabでJUnitスクリーンショットを表示する
スクリーンショットを[アーティファクト](../yaml/artifacts_reports.md#artifactsreportsjunit)としてGitLabにアップロードできます。JUnitレポート形式のXMLファイルに`attachment`タグが含まれている場合、GitLabは添付ファイルを解析します。スクリーンショットアーティファクトをアップロードする場合:
- `attachment`タグには、`$CI_PROJECT_DIR`を基準にしてアップロードしたスクリーンショットのパスを含める**必要があります**。次に例を示します。
```xml
<testcase time="1.00" name="Test">
<system-out>[[ATTACHMENT|/path/to/some/file]]</system-out>
</testcase>
```
- テストが失敗した場合でもスクリーンショットがアップロードされるように、スクリーンショットをアップロードするジョブを[`artifacts:when: always`](../yaml/_index.md#artifactswhen)に設定する必要があります。
添付ファイルがアップロードされると、[パイプラインテストレポート](#view-unit-test-reports-on-gitlab)にスクリーンショットへのリンクが含まれます。次に例を示します。
![テストの詳細とスクリーンショットの添付ファイルを含む失敗した単体テストレポート](img/unit_test_report_screenshot_v13_12.png)
## トラブルシューティング
### テストレポートが空で表示される
マージリクエストで単体テストレポートを表示すると、次の理由により空で表示されることがあります。
1. レポートを含むアーティファクトの有効期限が切れている: この問題を解決するには、次のいずれかの操作を実行します。
- レポートアーティファクトに、より長い[`expire_in`](../yaml/_index.md#artifactsexpire_in)値を設定する。
- 新しいパイプラインを実行して、新しいレポートを生成する。
1. JUnitファイルがサイズ制限を超えている: この問題を解決するには、次の操作を実行します。
- 個々のJUnitファイルが30 MB未満であることを確認する。
- ジョブのJUnitサイズの合計が100 MB未満であることを確認しする。
カスタム制限のサポートは、[エピック16374](https://gitlab.com/groups/gitlab-org/-/epics/16374)で提案されています。

755
doc-locale/ja-jp/user/application_security/container_scanning/_index.md Normal file
View File

@ -0,0 +1,755 @@
---
stage: Application Security Testing
group: Composition Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: コンテナスキャン
---
{{< details >}}
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
{{< /details >}}
{{< history >}}
- GitLab15.0で、主要なアナライザーのバージョンが`4`から`5`に[変更](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/86092)されました。
- 15.0で、GitLab UltimateからGitLab Freeに[移行](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/86783)しました。
- GitLab 15.4で、Dockerを参照するコンテナスキャン変数の[名前が変更](https://gitlab.com/gitlab-org/gitlab/-/issues/357264)されました。
- GitLab15.6で、コンテナスキャンテンプレートが`Security/Container-Scanning.gitlab-ci.yml`から`Jobs/Container-Scanning.gitlab-ci.yml`に[移動](https://gitlab.com/gitlab-org/gitlab/-/issues/381665)しました。
{{< /history >}}
コンテナイメージのセキュリティの脆弱性は、アプリケーションライフサイクル全体にリスクをもたらします。コンテナスキャンは、本番環境に到達する前に、これらのリスクを早期に検出します。ベースイメージまたはオペレーティングシステムのパッケージに脆弱性がある場合、コンテナスキャンはそれらを特定し、可能な場合は修正パスを提供します。
- <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>概要については、「[Container Scanning](https://www.youtube.com/watch?v=C0jn2eN5MAs)（コンテナスキャン）」をご覧ください。
- <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>ビデオによるチュートリアルについては、「[How to set up Container Scanning using GitLab](https://youtu.be/h__mcXpil_4?si=w_BVG68qnkL9x4l1)（GitLabを使用してコンテナスキャンを設定する方法）」をご覧ください。
- 入門チュートリアルについては、「[Dockerコンテナの脆弱性スキャン](../../../tutorials/container_scanning/_index.md)」を参照してください。
コンテナスキャンは、ソフトウェアコンポジション解析（SCA）の一部と見なされることがよくあります。SCAには、コードで使用するアイテムの検査の側面が含まれる場合があります。これらのアイテムには通常、アプリケーションやシステムの依存関係が含まれており、ほとんどの場合、これらはユーザーが記述したアイテムからではなく外部ソースからインポートされます。
GitLabは、これらのすべての依存関係タイプを確実に網羅するために、コンテナスキャンと[依存関係スキャン](../dependency_scanning/_index.md)の両方を提供しています。リスク領域をできるだけ広くカバーするために、すべてのセキュリティスキャナーを使用することをおすすめします。これらの機能の比較については、「[依存関係スキャンとコンテナスキャンの比較](../comparison_dependency_and_container_scanning.md)」を参照してください。
GitLabは、[Trivy](https://github.com/aquasecurity/trivy)セキュリティスキャナーと統合して、コンテナ内の脆弱性の静的な解析を実行します。
{{< alert type="warning" >}}
Grypeアナライザーは、[サポートステートメント](https://about.gitlab.com/support/statement-of-support/#version-support)で説明されているように、限定的な修正を除き、メンテナンスされなくなりました。Grypeアナライザーイメージの現在の主要バージョンは、GitLab 19.0まで最新のアドバイザリーデータベースとオペレーティングシステムパッケージの更新が継続され、その後アナライザーは動作を停止します。
{{< /alert >}}
GitLabは、ソースブランチとターゲットブランチの間で見つかった脆弱性を比較し、次の処理を実行します。
- 結果をマージリクエストウィジェットに表示します。
- 結果を[コンテナスキャンレポートアーティファクト](../../../ci/yaml/artifacts_reports.md#artifactsreportscontainer_scanning)として保存します。これはダウンロードして後で分析できます。ダウンロードすると、常に最新のアーティファクトを受け取ります。
- 検出されたコンポーネントをリストする[CycloneDX SBOM JSONレポート](#cyclonedx-software-bill-of-materials)を保存します。
![コンテナスキャンウィジェット](img/container_scanning_v13_2.png)
## 機能
| 機能 | FreeとPremium | Ultimate |
| --- | ------ | ------ |
| 設定のカスタマイズ（[変数](#available-cicd-variables)、[オーバーライド](#overriding-the-container-scanning-template)、[オフライン環境のサポート](#running-container-scanning-in-an-offline-environment)など） | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 |
| CIジョブアーティファクトとして[JSONレポートを表示](#reports-json-format) | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 |
| CIジョブアーティファクトとして[CycloneDX SBOM JSONレポート](#cyclonedx-software-bill-of-materials)を生成 | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 |
| GitLab UIのMR 経由でコンテナスキャンを有効にする機能 | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 |
| [UBIイメージのサポート](#fips-enabled-images) | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 |
| Trivyのサポート | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 |
| GitLab Advisory Databaseの組み込み | GitLab [advisories-communities](https://gitlab.com/gitlab-org/advisories-community/)プロジェクトからの時間差コンテンツに限定 | 可 - [Gemnasium DB](https://gitlab.com/gitlab-org/security-products/gemnasium-db)からのすべての最新コンテンツ |
| CIパイプラインジョブのマージリクエストタブとセキュリティタブでのレポートデータの表示 | {{< icon name="dotted-circle" >}} 不可 | {{< icon name="check-circle" >}} 可 |
| [脆弱性のソリューション（自動修正）](#solutions-for-vulnerabilities-auto-remediation) | {{< icon name="dotted-circle" >}} 不可 | {{< icon name="check-circle" >}} 可 |
| [脆弱性許可リスト](#vulnerability-allowlisting)のサポート | {{< icon name="dotted-circle" >}} 不可 | {{< icon name="check-circle" >}} 可 |
| [依存関係リストページへのアクセス](../dependency_list/_index.md) | {{< icon name="dotted-circle" >}} 不可 | {{< icon name="check-circle" >}} 可 |
## 設定
CI/CDパイプラインでコンテナスキャンアナライザーを有効にします。パイプラインが実行されると、アプリケーションが依存するイメージの脆弱性がスキャンされます。CI/CD変数を使用してコンテナスキャンをカスタマイズできます。
### アナライザーを有効にする
前提要件:
- `.gitlab-ci.yml`ファイルにはtestステージが必要です。
- Self-Managed Runner では、Linux/amd64上で`docker`または`kubernetes` executorを備えたGitLab Runner が必要です。GitLab.comのインスタンスRunnerを使用している場合、これはデフォルトで有効になっています。
- [サポートされているディストリビューション](#supported-distributions)に一致するイメージ。
- プロジェクトのコンテナレジストリに対して、Dockerイメージを[ビルドしてプッシュ](../../packages/container_registry/build_and_push_images.md#use-gitlab-cicd)していること。
- サードパーティのコンテナレジストリを使用している場合は、`CS_REGISTRY_USER`および`CS_REGISTRY_PASSWORD`の[設定変数](#available-cicd-variables)を使用して認証情報を提供する必要がある場合があります。これらの変数の使用方法の詳細については、「[リモートレジストリに対して認証する](#authenticate-to-a-remote-registry)」を参照してください。
アナライザーを有効にするには、次のいずれかの方法を使用します。
- 依存関係スキャンを含め、Auto DevOpsを有効にします。
- 事前設定されたマージリクエストを使用します。
- コンテナスキャンを実行する[スキャン実行ポリシー](../policies/scan_execution_policies.md)を作成します。
- `.gitlab-ci.yml`ファイルを手動で編集します。
#### 事前設定されたマージリクエストを使用する
この方法は、`.gitlab-ci.yml`ファイルにコンテナスキャンテンプレートが含まれているマージリクエストを自動的に準備します。次に、マージリクエストをマージして、依存関係スキャンを有効にします。
{{< alert type="note" >}}
この方法は、既存の`.gitlab-ci.yml`ファイルがない場合、または最小限の設定ファイルがある場合に最適です。複雑なGitLab設定ファイルがある場合は、正常に解析されず、エラーが発生する可能性があります。その場合は、代わりに[手動](#edit-the-gitlab-ciyml-file-manually)の方法を使用してください。
{{< /alert >}}
コンテナスキャンを有効にするには:
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトを検索します。
1. **セキュリティ>セキュリティ設定**を選択します。
1. **コンテナスキャン**行で、**マージリクエスト経由で設定**を選択します。
1. **マージリクエストの作成**を選択します。
1. マージリクエストをレビューして、**マージ**を選択します。
これで、パイプラインにコンテナスキャンジョブが含まれるようになります。
#### `.gitlab-ci.yml`ファイルを手動で編集する
この方法では、既存の`.gitlab-ci.yml`ファイルを手動で編集する必要があります。GitLab CI/CD設定ファイルが複雑な場合や、デフォルト以外のオプションを使用する必要がある場合は、この方法を使用します。
コンテナスキャンを有効にするには:
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトを検索します。
1. **ビルド>パイプラインエディタ**を選択します。
1. `.gitlab-ci.yml`ファイルが存在しない場合は、**パイプラインの設定**を選択し、例のコンテンツを削除します。
1. 次の内容をコピーして、`.gitlab-ci.yml`ファイルの末尾に貼り付けます。`include`行がすでに存在する場合は、その下に`template`行のみを追加します。
```yaml
include:
- template: Jobs/Container-Scanning.gitlab-ci.yml
```
1. **検証**タブを選択し、**パイプラインの検証**を選択します。
**シミュレーションが正常に完了しました**というメッセージは、ファイルが有効であることを裏付けています。
1. **編集**タブを選択します。
1. フィールドに入力します。**ブランチ**フィールドにデフォルトブランチを使用しないでください。
1. **これらの変更で新しいマージリクエストを開始**チェックボックスをオンにし、**変更をコミットする**を選択します。
1. 標準のワークフローに従ってフィールドに入力し、**マージリクエストの作成**を選択します。
1. 標準のワークフローに従ってマージリクエストをレビューおよび編集し、パイプラインがパスするまで待ってから**マージ**を選択します。
これで、パイプラインにコンテナスキャンジョブが含まれるようになります。
### アナライザーの動作をカスタマイズする
コンテナスキャンをカスタマイズするには、[CI/CD変数](#available-cicd-variables)を使用します。
#### 冗長な出力を有効にする
トラブルシューティング時など、依存関係スキャン ジョブの動作を詳細に確認する必要がある場合は、冗長な出力を有効にします。
次の例では、コンテナスキャンテンプレートが含まれており、冗長な出力が有効になっています。
```yaml
include:
- template: Jobs/Container-Scanning.gitlab-ci.yml
variables:
SECURE_LOG_LEVEL: 'debug'
```
#### リモートレジストリ内のイメージをスキャンする
プロジェクト以外のレジストリにあるイメージをスキャンするには、次の`.gitlab-ci.yml`を使用します。
```yaml
include:
- template: Jobs/Container-Scanning.gitlab-ci.yml
container_scanning:
variables:
CS_IMAGE: example.com/user/image:tag
```
##### リモートレジストリに対して認証する
プライベートレジストリ内のイメージをスキャンするには、認証が必要です。`CS_REGISTRY_USER`変数にユーザー名を、`CS_REGISTRY_PASSWORD`設定変数にパスワードを指定します。
たとえば、AWS Elasticコンテナレジストリからイメージをスキャンするには、次のようにします。
```yaml
container_scanning:
before_script:
- ruby -r open-uri -e "IO.copy_stream(URI.open('https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip'), 'awscliv2.zip')"
- unzip awscliv2.zip
- sudo ./aws/install
- aws --version
- export AWS_ECR_PASSWORD=$(aws ecr get-login-password --region region)
include:
- template: Jobs/Container-Scanning.gitlab-ci.yml
variables:
CS_IMAGE: <aws_account_id>.dkr.ecr.<region>.amazonaws.com/<image>:<tag>
CS_REGISTRY_USER: AWS
CS_REGISTRY_PASSWORD: "$AWS_ECR_PASSWORD"
AWS_DEFAULT_REGION: <region>
```
[FIPSモード](../../../development/fips_gitlab.md#enable-fips-mode)が有効になっている場合、リモートレジストリに対する認証はサポートされていません。
#### 言語固有の検出結果をレポートする
`CS_DISABLE_LANGUAGE_VULNERABILITY_SCAN` CI/CD変数は、スキャンでプログラミング言語に関連する検出結果をレポートするかどうかを制御します。サポートされている言語の詳細については、Trivyドキュメントの[言語固有のパッケージ](https://aquasecurity.github.io/trivy/latest/docs/coverage/language/#supported-languages)を参照してください。
デフォルトでは、レポートにはオペレーティングシステム（OS）パッケージマネージャー（`yum`、`apt`、`apk`、`tdnf`など）によって管理されるパッケージのみが含まれます。OS以外のパッケージのセキュリティ検出結果を報告するには、`CS_DISABLE_LANGUAGE_VULNERABILITY_SCAN`を`"false"`に設定します。
```yaml
include:
- template: Jobs/Container-Scanning.gitlab-ci.yml
container_scanning:
variables:
CS_DISABLE_LANGUAGE_VULNERABILITY_SCAN: "false"
```
この機能を有効にすると、プロジェクトで[依存関係スキャン](../dependency_scanning/_index.md)が有効になっている場合、[脆弱性レポート](../vulnerability_report/_index.md)に[重複する検出結果](../terminology/_index.md#duplicate-finding)が表示されることがあります。これは、GitLabが種類の異なるスキャンツール間で検出結果を自動的に重複排除できないために発生します。重複する可能性がある依存関係の種類については、「[依存関係スキャンとコンテナスキャンの比較](../comparison_dependency_and_container_scanning.md)」を参照してください。
#### マージリクエストパイプラインでジョブを実行する
「[マージリクエストパイプラインでセキュリティスキャンツールを使用する](../detect/roll_out_security_scanning.md#use-security-scanning-tools-with-merge-request-pipelines)」を参照してください。
#### 利用可能なCI/CD変数
コンテナスキャンをカスタマイズするには、CI/CD変数を使用します。次の表に、コンテナスキャンに固有のCI/CD変数を示します。[事前定義されたCI/CD変数](../../../ci/variables/predefined_variables.md)も使用できます。
{{< alert type="warning" >}}
これらの変更をデフォルトブランチにマージする前に、マージリクエストでGitLabアナライザーのカスタマイズをテストします。そうしないと、誤検出が多数発生するなど、予期しない結果が生じる可能性があります。
{{< /alert >}}
| CI/CD変数 | デフォルト | 説明 |
| ------------------------------ | ------------- | ----------- |
| `ADDITIONAL_CA_CERT_BUNDLE` | `""` | 信頼するCA証明書のバンドル。詳細については、「[カスタムSSL CA公開認証局を使用する](#using-a-custom-ssl-ca-certificate-authority)」を参照してください。 |
| `CI_APPLICATION_REPOSITORY` | `$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG` | スキャンするイメージのDockerリポジトリURL。 |
| `CI_APPLICATION_TAG` | `$CI_COMMIT_SHA` | スキャンするイメージのDockerリポジトリタグ。 |
| `CS_ANALYZER_IMAGE` | `registry.gitlab.com/security-products/container-scanning:7` | アナライザーのDockerイメージ。GitLabが提供するアナライザーイメージで`:latest`タグを使用しないでください。 |
| `CS_DEFAULT_BRANCH_IMAGE` | `""` | デフォルトブランチの`CS_IMAGE`の名前。詳細については、「[デフォルトブランチイメージを設定する](#setting-the-default-branch-image)」を参照してください。 |
| `CS_DISABLE_DEPENDENCY_LIST` | `"false"` | {{< icon name="warning" >}}GitLab 17.0で**[削除](https://gitlab.com/gitlab-org/gitlab/-/issues/439782)**されました。 |
| `CS_DISABLE_LANGUAGE_VULNERABILITY_SCAN` | `"true"` | スキャンされたイメージにインストールされている言語固有パッケージのスキャンを無効にします。 |
| `CS_DOCKER_INSECURE` | `"false"` | 証明書を検証せずに、HTTPSを使用してセキュアなDocker レジストリへのアクセスを許可します。 |
| `CS_DOCKERFILE_PATH` | `Dockerfile` | 修正の生成に使用する`Dockerfile`へのパス。デフォルトでは、スキャナーはプロジェクトのルートディレクトリにある`Dockerfile`という名前のファイルを探します。この変数は、`Dockerfile`がサブディレクトリなどの標準以外の場所にある場合にのみ設定する必要があります。詳細については、「[脆弱性のソリューション](#solutions-for-vulnerabilities-auto-remediation)」を参照してください。 |
| `CS_IGNORE_STATUSES` | `""` | アナライザーに、コンマ区切りのリストで指定されたステータスの検出結果を無視するように強制します。次の値が許可されています: `unknown,not_affected,affected,fixed,under_investigation,will_not_fix,fix_deferred,end_of_life`。<sup>1</sup> |
| `CS_IGNORE_UNFIXED` | `"false"` | 修正されていない検出結果を無視します。無視された検出結果はレポートに含まれません。 |
| `CS_IMAGE` | `$CI_APPLICATION_REPOSITORY:$CI_APPLICATION_TAG` | スキャンするDockerイメージ。設定されている場合、この変数は`$CI_APPLICATION_REPOSITORY`変数と`$CI_APPLICATION_TAG`変数をオーバーライドします。 |
| `CS_IMAGE_SUFFIX` | `""` | `CS_ANALYZER_IMAGE`に追加されたサフィックス。`-fips`に設定すると、`FIPS-enabled`イメージがスキャンに使用されます。詳細については、「[FIPS対応イメージ](#fips-enabled-images)」を参照してください。 |
| `CS_QUIET` | `""` | 設定されている場合、この変数はジョブログの[脆弱性テーブル](#container-scanning-job-log-format)の出力を無効にします。GitLab 15.1で[導入](https://gitlab.com/gitlab-org/security-products/analyzers/container-scanning/-/merge_requests/50)されました。 |
| `CS_REGISTRY_INSECURE` | `"false"` | 脆弱なレジストリへのアクセスを許可します（HTTPのみ）。ローカルでイメージをテストする場合は、`true`にのみ設定する必要があります。すべてのスキャナーで動作しますが、Trivyを動作させるには、レジストリがポート`80/tcp`でリッスンする必要があります。 |
| `CS_REGISTRY_PASSWORD` | `$CI_REGISTRY_PASSWORD` | 認証が必要なDockerレジストリにアクセスするためのパスワード。デフォルトは、`$CS_IMAGE`が[`$CI_REGISTRY`](../../../ci/variables/predefined_variables.md)に存在する場合にのみ設定されます。[FIPSモード](../../../development/fips_gitlab.md#enable-fips-mode)が有効になっている場合はサポートされていません。 |
| `CS_REGISTRY_USER` | `$CI_REGISTRY_USER` | 認証が必要なDockerレジストリにアクセスするためのユーザー名。デフォルトは、`$CS_IMAGE`が[`$CI_REGISTRY`](../../../ci/variables/predefined_variables.md)に存在する場合にのみ設定されます。[FIPSモード](../../../development/fips_gitlab.md#enable-fips-mode)が有効になっている場合はサポートされていません。 |
| `CS_SEVERITY_THRESHOLD` | `UNKNOWN` | 重大度レベルのしきい値。スキャナーは、このしきい値以上の重大度レベルの脆弱性を出力します。サポートされているレベルは、`UNKNOWN`、`LOW`、`MEDIUM`、`HIGH`、`CRITICAL`です。{{< icon name="warning" >}}GitLab 17.8で、**[デフォルト値が`MEDIUM`に変更](https://gitlab.com/gitlab-org/gitlab/-/issues/439782)**されました。 |
| `CS_TRIVY_JAVA_DB` | `"registry.gitlab.com/gitlab-org/security-products/dependencies/trivy-java-db"` | [trivy-java-db](https://github.com/aquasecurity/trivy-java-db)脆弱性データベースの代替場所を指定します。 |
| `SECURE_LOG_LEVEL` | `info` | 最小ログ生成レベルを設定します。このログ生成レベル以上のメッセージが出力されます。重大度が最も高いものから最も低いものへ順に、ログ生成レベルは、`fatal`、`error`、`warn`、`info`、`debug`です。 |
| `TRIVY_TIMEOUT` | `5m0s` | スキャンのタイムアウトを設定します。 |
**脚注:**
1. 修正ステータスの情報は、ソフトウェアベンダーからの正確な修正可用性データとコンテナイメージのオペレーティングシステムパッケージメタデータに大きく依存します。また、個々のコンテナスキャナーによる解釈の影響も受けます。コンテナスキャナーが脆弱性に対して修正されたパッケージの可用性を誤って報告している場合、`CS_IGNORE_STATUSES`を使用すると、この設定が有効になっている場合に、検出結果の誤検出または誤判定フィルタリングにつながる可能性があります。
### サポートされているディストリビューション
次のLinuxディストリビューションがサポートされています。
- Alma Linux
- alpine Linux
- Amazon Linux
- CentOS
- CBL-Mariner
- Debian
- Distroless
- Oracle Linux
- Photon OS
- Red Hat（RHEL）
- Rocky Linux
- SUSE
- Ubuntu
#### FIPS対応イメージ
GitLabは、コンテナスキャンイメージの[FIPS対応Red Hat UBI](https://www.redhat.com/en/blog/introducing-red-hat-universal-base-image)バージョンも提供しています。したがって、標準イメージをFIPS対応イメージに置き換えることができます。イメージを設定するには、`CS_IMAGE_SUFFIX`を`-fips`に設定するか、`CS_ANALYZER_IMAGE`変数を標準タグに`-fips`拡張子を加えたものに変更します。
{{< alert type="note" >}}
GitLabインスタンスでFIPSモードが有効になっている場合、`-fips`フラグは`CS_ANALYZER_IMAGE`に自動的に追加されます。
{{< /alert >}}
[FIPSモード](../../../development/fips_gitlab.md#enable-fips-mode)が有効になっている場合、認証済みレジストリのイメージのコンテナスキャンはサポートされません。`CI_GITLAB_FIPS_MODE`が`"true"`で、`CS_REGISTRY_USER`または`CS_REGISTRY_PASSWORD`が設定されている場合、アナライザーはエラーで終了し、スキャンを実行しません。
### コンテナスキャンテンプレートをオーバーライドする
ジョブ定義をオーバーライドする場合（`variables`のようなプロパティを変更する場合など）は、テンプレートを含めた後でジョブを宣言してオーバーライドし、追加のキーを指定する必要があります。
この例では、`GIT_STRATEGY`を`fetch`に設定します。
```yaml
include:
- template: Jobs/Container-Scanning.gitlab-ci.yml
container_scanning:
variables:
GIT_STRATEGY: fetch
```
### デフォルトブランチイメージを設定する
デフォルトでは、コンテナスキャンは、イメージの命名規則が、ブランチ固有の識別子をイメージ名ではなくイメージタグに格納することを想定しています。イメージ名がデフォルトブランチと非デフォルトブランチで異なる場合、以前に検出された脆弱性は、マージリクエストで新しく検出されたものとして表示されます。
デフォルトブランチと非デフォルトブランチで同じイメージに異なる名前が付けられている場合は、`CS_DEFAULT_BRANCH_IMAGE`変数を使用すると、そのイメージのデフォルトブランチでの名前を示すことができます。これにより、GitLabは、非デフォルトブランチでスキャンを実行するときに、脆弱性がすでに存在するかどうかを正しく判断します。
例として、以下を想定します。
- 非デフォルトブランチは、命名規則`$CI_REGISTRY_IMAGE/$CI_COMMIT_BRANCH:$CI_COMMIT_SHA`でイメージを公開します。
- デフォルトブランチは、命名規則`$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA`でイメージを公開します。
この例では、次のCI/CD設定を使用して、脆弱性が複製されないようにすることができます。
```yaml
include:
- template: Jobs/Container-Scanning.gitlab-ci.yml
container_scanning:
variables:
CS_DEFAULT_BRANCH_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
before_script:
- export CS_IMAGE="$CI_REGISTRY_IMAGE/$CI_COMMIT_BRANCH:$CI_COMMIT_SHA"
- |
if [ "$CI_COMMIT_BRANCH" == "$CI_DEFAULT_BRANCH" ]; then
export CS_IMAGE="$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"
fi
```
`CS_DEFAULT_BRANCH_IMAGE`は、特定の`CS_IMAGE`に対して同じである必要があります。変更された場合、重複する脆弱性のセットが作成され、手動で無視する必要があります。
[Auto DevOps](../../../topics/autodevops/_index.md)を使用している場合、`CS_DEFAULT_BRANCH_IMAGE`は自動的に`$CI_REGISTRY_IMAGE/$CI_DEFAULT_BRANCH:$CI_APPLICATION_TAG`に設定されます。
### カスタムSSL CA公開認証局を使用する
`ADDITIONAL_CA_CERT_BUNDLE` CI/CD変数を使用して、カスタムSSL CA公開認証局を設定できます。これは、HTTPSを使用するレジストリからDockerイメージをフェッチするときに、ピアを検証するために使用されます。`ADDITIONAL_CA_CERT_BUNDLE`値には、[X.509 PEM公開鍵証明書のテキスト表現](https://www.rfc-editor.org/rfc/rfc7468#section-5.1)が含まれている必要があります。たとえば、`.gitlab-ci.yml`ファイルでこの値を設定するには、以下を実行します。
```yaml
container_scanning:
variables:
ADDITIONAL_CA_CERT_BUNDLE: |
-----BEGIN CERTIFICATE-----
MIIGqTCCBJGgAwIBAgIQI7AVxxVwg2kch4d56XNdDjANBgkqhkiG9w0BAQsFADCB
...
jWgmPqF3vUbZE0EyScetPJquRFRKIesyJuBFMAs=
-----END CERTIFICATE-----
```
`ADDITIONAL_CA_CERT_BUNDLE`値は、[UIのカスタム変数](../../../ci/variables/_index.md#for-a-project)として設定することもできます。`file`として設定する場合は、証明書のパスが必要です。変数として設定する場合は、証明書のテキスト表現が必要です。
### 脆弱性の許可リスト
{{< details >}}
- プラン: Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
{{< /details >}}
特定の脆弱性を許可リストに登録するには、次の手順に従います。
1. 「[コンテナスキャンテンプレートをオーバーライドする](#overriding-the-container-scanning-template)」の手順に従って、`.gitlab-ci.yml`ファイルに`GIT_STRATEGY: fetch`を設定します。
1. `vulnerability-allowlist.yml`という名前のYAMLファイルで、許可リストに登録されている脆弱性を定義します。これは、[`vulnerability-allowlist.yml`データ形式](#vulnerability-allowlistyml-data-format)で説明されている形式を使用する必要があります。
1. `vulnerability-allowlist.yml`ファイルをプロジェクトのGitリポジトリのルートフォルダーに追加します。
#### `vulnerability-allowlist.yml`データ形式
`vulnerability-allowlist.yml`ファイルはYAMLファイルで、_誤検出_であるか_適用されない_ため存在が**許可**されている脆弱性のCVE IDリストを指定します。
`vulnerability-allowlist.yml`ファイルに一致するエントリが見つかった場合、次のようになります。
- アナライザーが`gl-container-scanning-report.json`ファイルを生成する際、脆弱性は**含まれません**。
- パイプラインのセキュリティタブに脆弱性が**表示されません**。セキュリティタブの信頼できる情報源であるJSONファイルに含まれていないからです。
`vulnerability-allowlist.yml`ファイルの例:
```yaml
generalallowlist:
CVE-2019-8696:
CVE-2014-8166: cups
CVE-2017-18248:
images:
registry.gitlab.com/gitlab-org/security-products/dast/webgoat-8.0@sha256:
CVE-2018-4180:
your.private.registry:5000/centos:
CVE-2015-1419: libxml2
CVE-2015-1447:
```
この例では、以下が`gl-container-scanning-report.json`から除外されます。
1. CVE IDを持つすべての脆弱性: _CVE-2019-8696_、_CVE-2014-8166_、_CVE-2017-18248_
1. CVE ID _CVE-2018-4180_を持つ`registry.gitlab.com/gitlab-org/security-products/dast/webgoat-8.0@sha256` コンテナイメージで見つかったすべての脆弱性
1. CVE ID _CVE-2015-1419_、_CVE-2015-1447_ を持つ`your.private.registry:5000/centos`コンテナで見つかったすべての脆弱性
##### ファイル形式
- `generalallowlist`ブロックを使用すると、CVE IDをグローバルに指定できます。一致するCVE IDを持つすべての脆弱性は、スキャンレポートから除外されます。
- `images`ブロックを使用すると、コンテナイメージごとにCVE IDを個別に指定できます。一致するCVE IDを持つ特定のイメージからのすべての脆弱性は、スキャンレポートから除外されます。イメージ名は、スキャンするDockerイメージを指定するために使用される環境変数の1つ（`$CI_APPLICATION_REPOSITORY:$CI_APPLICATION_TAG`や`CS_IMAGE`など）から取得されます。このブロックで指定されたイメージは、この値と一致**する必要があり**、タグの値を含**めてはなりません**。たとえば、`CS_IMAGE=alpine:3.7`を使用してスキャンするイメージを指定する場合、`images`ブロックで`alpine`を使用しますが、`alpine:3.7`は使用できません。
コンテナイメージは、複数の方法で指定できます。
- イメージ名のみ（`centos`など）
- レジストリホスト名を含む完全なイメージ名として（`your.private.registry:5000/centos`など）
- レジストリホスト名とsha256ラベルを含む完全なイメージ名として（`registry.gitlab.com/gitlab-org/security-products/dast/webgoat-8.0@sha256`など）
{{< alert type="note" >}}
CVE IDの後の文字列（前の例の`cups`および`libxml2`）は、オプションのコメント形式です。脆弱性の処理には**影響しません**。コメントを含めて脆弱性を説明できます。
{{< /alert >}}
##### コンテナスキャンジョブログ形式
`container_scanning`ジョブの詳細で、コンテナスキャンアナライザーによって生成されたログを見ることで、スキャンの結果と`vulnerability-allowlist.yml`ファイルの正確性を確認できます。
ログには、検出された脆弱性のリストがテーブルとして含まれます。次に例を示します。
```plaintext
+------------+-------------------------+------------------------+-----------------------+------------------------------------------------------------------------+
| STATUS | CVE SEVERITY | PACKAGE NAME | PACKAGE VERSION | CVE DESCRIPTION |
+------------+-------------------------+------------------------+-----------------------+------------------------------------------------------------------------+
| Approved | High CVE-2019-3462 | apt | 1.4.8 | Incorrect sanitation of the 302 redirect field in HTTP transport metho |
| | | | | d of apt versions 1.4.8 and earlier can lead to content injection by a |
| | | | | MITM attacker, potentially leading to remote code execution on the ta |
| | | | | rget machine. |
+------------+-------------------------+------------------------+-----------------------+------------------------------------------------------------------------+
| Unapproved | Medium CVE-2020-27350 | apt | 1.4.8 | APT had several integer overflows and underflows while parsing .deb pa |
| | | | | ckages, aka GHSL-2020-168 GHSL-2020-169, in files apt-pkg/contrib/extr |
| | | | | acttar.cc, apt-pkg/deb/debfile.cc, and apt-pkg/contrib/arfile.cc. This |
| | | | | issue affects: apt 1.2.32ubuntu0 versions prior to 1.2.32ubuntu0.2; 1 |
| | | | | .6.12ubuntu0 versions prior to 1.6.12ubuntu0.2; 2.0.2ubuntu0 versions |
| | | | | prior to 2.0.2ubuntu0.2; 2.1.10ubuntu0 versions prior to 2.1.10ubuntu0 |
| | | | | .1; |
+------------+-------------------------+------------------------+-----------------------+------------------------------------------------------------------------+
| Unapproved | Medium CVE-2020-3810 | apt | 1.4.8 | Missing input validation in the ar/tar implementations of APT before v |
| | | | | ersion 2.1.2 could result in denial of service when processing special |
| | | | | ly crafted deb files. |
+------------+-------------------------+------------------------+-----------------------+------------------------------------------------------------------------+
```
対応するCVE IDが`vulnerability-allowlist.yml`ファイルに追加されると、ログ内の脆弱性は`Approved`としてマークされます。
### オフライン環境でコンテナスキャンを実行する
{{< details >}}
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab Self-Managed
{{< /details >}}
インターネット経由での外部リソースへのアクセスが制限されている環境やアクセスが断続的な環境のインスタンスでは、コンテナスキャンジョブを正常に実行するためにいくつかの調整が必要です。詳細については、「[オフライン環境](../offline_deployments/_index.md)」を参照してください。
#### オフラインコンテナスキャンの要件
オフライン環境でコンテナスキャンを実行するには、以下が必要です。
- [`docker`または`kubernetes`executor](#enabling-the-analyzer)を備えたGitLab Runner
- コンテナスキャンイメージのコピーを含む、ローカルDockerコンテナレジストリを設定すること。これらのイメージは、それぞれのレジストリにあります。
| GitLabアナライザー | コンテナレジストリ |
| --- | --- |
| [Container-Scanning](https://gitlab.com/gitlab-org/security-products/analyzers/container-scanning) | [Container-Scanningコンテナレジストリ](https://gitlab.com/security-products/container-scanning/container_registry/) |
GitLab Runnerでは、[デフォルトで`pull policy`が`always`](https://docs.gitlab.com/runner/executors/docker.html#using-the-always-pull-policy)になっています。つまり、ローカルコピーが利用可能な場合でも、RunnerはGitLabコンテナレジストリからDockerイメージをプルしようとします。ローカルで利用可能なDockerイメージのみを使用する場合は、オフライン環境でGitLab Runnerの[`pull_policy`を`if-not-present`に設定できます](https://docs.gitlab.com/runner/executors/docker.html#using-the-if-not-present-pull-policy)。ただし、オフライン環境でない場合は、プルポリシーの設定を`always`のままにしておくことをおすすめします。これにより、CI/CDパイプラインで更新されたスキャナーを使用できるようになります。
##### カスタム公開認証局（CA）のサポート
バージョン[4.0.0](https://gitlab.com/gitlab-org/security-products/analyzers/container-scanning/-/releases/4.0.0)で、Trivyのカスタム公開認証局（CA）のサポートが導入されました。
#### Dockerレジストリ内でGitLabコンテナスキャンアナライザーイメージを利用できるようにする
コンテナスキャンでは、`registry.gitlab.com`から次のイメージを[ローカルDockerコンテナレジストリ](../../packages/container_registry/_index.md)にインポートします。
```plaintext
registry.gitlab.com/security-products/container-scanning:7
registry.gitlab.com/security-products/container-scanning/trivy:7
```
DockerイメージをローカルのオフラインDockerレジストリにインポートするプロセスは、**ネットワークのセキュリティポリシー**によって異なります。IT部門に相談して、外部リソースをインポートまたは一時的にアクセスするための承認済みプロセスを確認してください。これらのスキャナーは[定期的に更新](../_index.md#vulnerability-scanner-maintenance)されています。また、自分で随時更新できる場合もあります。
詳細については、[パイプラインでイメージを更新する方法に関する特定の手順](#automating-container-scanning-vulnerability-database-updates-with-a-pipeline)を参照してください。
Dockerイメージをファイルとして保存および転送する方法の詳細については、[`docker save`](https://docs.docker.com/reference/cli/docker/image/save/)、[`docker load`](https://docs.docker.com/reference/cli/docker/image/load/)、[`docker export`](https://docs.docker.com/reference/cli/docker/container/export/)、[`docker import`](https://docs.docker.com/reference/cli/docker/image/import/)に関するDockerドキュメントを参照してください。
#### ローカルコンテナスキャナーアナライザーを使用するようにコンテナスキャンCI/CD変数を設定する
1. `.gitlab-ci.yml`ファイルで[コンテナスキャンテンプレートをオーバーライド](#overriding-the-container-scanning-template)して、ローカルDockerコンテナレジストリでホストされているDockerイメージを参照します。
```yaml
include:
- template: Jobs/Container-Scanning.gitlab-ci.yml
container_scanning:
image: $CI_REGISTRY/namespace/container-scanning
```
1. ローカルDockerコンテナレジストリが`HTTPS`経由で安全に実行されているが、自己署名証明書を使用している場合は、`.gitlab-ci.yml`の上記の`container_scanning`セクションで`CS_DOCKER_INSECURE: "true"`を設定する必要があります。
#### パイプラインを使用したコンテナスキャンの脆弱性データベース更新を自動化する
プリセットスケジュールで最新の脆弱性データベースをフェッチするように、[スケジュールされたパイプライン](../../../ci/pipelines/schedules.md)を設定することをおすすめします。パイプラインでこれを自動化すると、毎回手動で実行する必要がなくなります。テンプレートとして、次の`.gitlab-ci.yml`の例を使用できます。
```yaml
variables:
SOURCE_IMAGE: registry.gitlab.com/security-products/container-scanning:7
TARGET_IMAGE: $CI_REGISTRY/namespace/container-scanning
image: docker:latest
update-scanner-image:
services:
- docker:dind
script:
- docker pull $SOURCE_IMAGE
- docker tag $SOURCE_IMAGE $TARGET_IMAGE
- echo "$CI_REGISTRY_PASSWORD" | docker login $CI_REGISTRY --username $CI_REGISTRY_USER --password-stdin
- docker push $TARGET_IMAGE
```
上記のテンプレートは、ローカルインストールで実行されているGitLab Dockerレジストリで機能します。ただし、GitLab以外のDockerレジストリを使用している場合は、ローカルレジストリの詳細に合わせて`$CI_REGISTRY`の値と`docker login`の認証情報を変更する必要があります。
#### 外部プライベートレジストリのイメージをスキャンする
外部プライベートレジストリ内のイメージをスキャンするには、スキャンするイメージにアクセスする前にコンテナスキャンアナライザーが自身を認証できるように、アクセス認証情報を設定する必要があります。
GitLab[コンテナレジストリ](../../packages/container_registry/_index.md)を使用する場合は、`CS_REGISTRY_USER`および`CS_REGISTRY_PASSWORD`の[設定変数](#available-cicd-variables)が自動的に設定されるため、この設定をスキップできます。
次の例は、プライベート[Google Container Registry](https://cloud.google.com/artifact-registry)でイメージをスキャンするために必要な設定を示しています。
```yaml
include:
- template: Jobs/Container-Scanning.gitlab-ci.yml
container_scanning:
variables:
CS_REGISTRY_USER: _json_key
CS_REGISTRY_PASSWORD: "$GCP_CREDENTIALS"
CS_IMAGE: "gcr.io/path-to-you-registry/image:tag"
```
この設定をコミットする前に、[Google Cloud Platform Container Registryドキュメント](https://cloud.google.com/container-registry/docs/advanced-authentication#json-key)の説明に従って、JSONキーを含む`GCP_CREDENTIALS`の[CI/CD変数](../../../ci/variables/_index.md#for-a-project)を追加します。また、次のようになります。
- 変数の値が**変数をマスク**オプションのマスキング要件に適合しない場合があるため、値がジョブログに公開される可能性があります。
- **変数の保護**オプションを選択すると、保護されていないフィーチャーブランチでスキャンが実行されない場合があります。
- オプションが選択されていない場合は、読み取り専用権限を持つ認証情報を作成し、定期的にローテーションすることを検討してください。
[FIPSモード](../../../development/fips_gitlab.md#enable-fips-mode)が有効になっている場合、外部プライベートレジストリのイメージのスキャンはサポートされません。
#### Trivy Javaデータベースミラーを作成および使用する
`trivy`スキャナーが使用され、スキャンされるコンテナイメージで`jar`ファイルが検出されると、`trivy`は追加の`trivy-java-db`脆弱性データベースをダウンロードします。デフォルトでは、`trivy-java-db`データベースは`ghcr.io/aquasecurity/trivy-java-db:1`で[OCIアーティファクト](https://oras.land/docs/quickstart/)としてホストされます。このレジストリに[アクセスできない](#running-container-scanning-in-an-offline-environment)場合、または`TOOMANYREQUESTS`という応答が返ってくる場合は、`trivy-java-db`をよりアクセスしやすいコンテナレジストリにミラーリングするという解決策があります。
```yaml
mirror trivy java db:
image:
name: ghcr.io/oras-project/oras:v1.1.0
entrypoint: [""]
script:
- oras login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
- oras pull ghcr.io/aquasecurity/trivy-java-db:1
- oras push $CI_REGISTRY_IMAGE:1 --config /dev/null:application/vnd.aquasec.trivy.config.v1+json javadb.tar.gz:application/vnd.aquasec.trivy.javadb.layer.v1.tar+gzip
```
脆弱性データベースは通常のDockerイメージではないため、`docker pull`を使用してプルすることはできません。GitLab UIでイメージに移動すると、エラーが表示されます。
上記のコンテナレジストリが`gitlab.example.com/trivy-java-db-mirror`の場合、コンテナスキャンジョブは次の方法で設定する必要があります。末尾にタグ`:1`を追加しないでください。`trivy`によって追加されます。
```yaml
include:
- template: Jobs/Container-Scanning.gitlab-ci.yml
container_scanning:
variables:
CS_TRIVY_JAVA_DB: gitlab.example.com/trivy-java-db-mirror
```
## スタンドアロンのコンテナスキャンツールを実行する
[GitLabコンテナスキャンツール](https://gitlab.com/gitlab-org/security-products/analyzers/container-scanning)をDockerコンテナに対して実行できます。CIジョブのコンテキスト内で実行する必要はありません。イメージを直接スキャンするには、次の手順に従います。
1. [Docker Desktop](https://www.docker.com/products/docker-desktop/)または[Docker Machine](https://github.com/docker/machine)を実行します。
1. アナライザーのDockerイメージを実行し、`CI_APPLICATION_REPOSITORY`および`CI_APPLICATION_TAG`変数で分析するイメージとタグを渡します。
```shell
docker run \
--interactive --rm \
--volume "$PWD":/tmp/app \
-e CI_PROJECT_DIR=/tmp/app \
-e CI_APPLICATION_REPOSITORY=registry.gitlab.com/gitlab-org/security-products/dast/webgoat-8.0@sha256 \
-e CI_APPLICATION_TAG=bc09fe2e0721dfaeee79364115aeedf2174cce0947b9ae5fe7c33312ee019a4e \
registry.gitlab.com/security-products/container-scanning
```
結果は`gl-container-scanning-report.json`に保存されます。
## JSON形式のレポート
コンテナスキャンツールはJSONレポートを出力します。これは、CI設定ファイルの[`artifacts:reports`](../../../ci/yaml/_index.md#artifactsreports)キーワードを介して[GitLab Runner](https://docs.gitlab.com/runner/)が認識します。
CIジョブが完了すると、RunnerはこれらのレポートをGitLabにアップロードし、CIジョブアーティファクトで使用できるようになります。GitLab Ultimateでは、対応する[パイプライン](../vulnerability_report/pipeline.md)でこれらのレポートを確認できます。また、これらのレポートは[脆弱性レポート](../vulnerability_report/_index.md)の一部になります。
これらのレポートは、[セキュリティレポートスキーマ](https://gitlab.com/gitlab-org/security-products/security-report-schemas/)で定義された形式に従う必要があります。以下を参照してください。
- [コンテナスキャンレポートの最新のスキーマ](https://gitlab.com/gitlab-org/security-products/security-report-schemas/-/blob/master/dist/container-scanning-report-format.json)
- [コンテナスキャンレポートの例](https://gitlab.com/gitlab-examples/security/security-reports/-/blob/master/samples/container-scanning.json)
詳細については、「[セキュリティスキャナーのインテグレーション](../../../development/integrations/secure.md)」を参照してください。
### CycloneDXソフトウェア部品表
{{< history >}}
- GitLab 15.11で[導入](https://gitlab.com/gitlab-org/gitlab/-/issues/396381)されました。
{{< /history >}}
[JSONレポートファイル](#reports-json-format)に加えて、[コンテナスキャン](https://gitlab.com/gitlab-org/security-products/analyzers/container-scanning)ツールは、スキャンされたイメージの[CycloneDX](https://cyclonedx.org/)ソフトウェア部品表（SBOM）を出力します。このCycloneDX SBOMは`gl-sbom-report.cdx.json`という名前で、`JSON report file`と同じディレクトリに保存されます。この機能は、`Trivy`アナライザーが使用されている場合にのみサポートされます。
このレポートは、[依存関係リスト](../dependency_list/_index.md)で確認できます。
[他のジョブアーティファクトと同じ方法](../../../ci/jobs/job_artifacts.md#download-job-artifacts)でCycloneDX SBOMをダウンロードできます。
## レジストリのコンテナスキャン
{{< details >}}
- プラン: Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
{{< /details >}}
{{< history >}}
- GitLab 17.1で、`enable_container_scanning_for_registry`という名前の[フラグとともに](../../../administration/feature_flags.md)[導入](https://gitlab.com/groups/gitlab-org/-/epics/2340)されました。デフォルトでは無効になっています。
- GitLab 17.2の[GitLab Self-ManagedおよびGitLab Dedicatedで有効](https://gitlab.com/gitlab-org/gitlab/-/issues/443827)になりました。
- GitLab 17.2で[一般提供](https://gitlab.com/gitlab-org/gitlab/-/issues/443827)になりました。機能フラグ`enable_container_scanning_for_registry`が削除されました。
{{< /history >}}
コンテナイメージが`latest`タグでプッシュされると、セキュリティポリシーボットによって、デフォルトブランチに対して新しいパイプラインでコンテナスキャンジョブが自動的にトリガーされます。
通常のコンテナスキャンとは異なり、スキャン結果にセキュリティレポートは含まれません。代わりに、レジストリのコンテナスキャンは、[継続的脆弱性スキャン](../continuous_vulnerability_scanning/_index.md)を利用して、スキャンによって検出されたコンポーネントを検査します。
セキュリティ検出が特定されると、GitLabはこれらの検出結果を[脆弱性レポート](../vulnerability_report/_index.md)に入力します。脆弱性は、脆弱性レポートページの**コンテナレジストリの脆弱性**タブで確認できます。
{{< alert type="note" >}}
レジストリのコンテナスキャンは、新しいアドバイザリーが[GitLab Advisory Database](../gitlab_advisory_database/_index.md)に公開された場合にのみ、脆弱性レポートに情報を入力します。新しく検出されたデータだけでなく、存在するすべてのアドバイザリデータを脆弱性レポートに入力するためのサポートは、[エピック11219](https://gitlab.com/groups/gitlab-org/-/epics/11219)で提案されています。
{{< /alert >}}
### 前提要件
- レジストリのコンテナスキャンを有効にするには、プロジェクトのメンテナーロール以上を持っている必要があります。
- 使用するプロジェクトが空であってはなりません。コンテナイメージの保存のみを目的として空のプロジェクトを利用している場合、この機能は意図したとおりに機能しません。回避策として、プロジェクトにデフォルトブランチへの最初のコミットが含まれていることを確認してください。
- デフォルトでは、1日あたり1プロジェクトにつき`50`回のスキャンに制限されています。
- [コンテナレジストリ通知を設定する](../../../administration/packages/container_registry.md#configure-container-registry-notifications)必要があります。
### レジストリのコンテナスキャンを有効にする
GitLabコンテナレジストリのコンテナスキャンを有効にするには:
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトを検索します。
1. **セキュリティ>セキュリティ設定**を選択します。
1. **レジストリのコンテナスキャン**セクションまでスクロールし、切替をオンにします。
## 脆弱性データベース
すべてのアナライザーイメージは[毎日更新](https://gitlab.com/gitlab-org/security-products/analyzers/container-scanning/-/blob/master/README.md#image-updates)されます。
次のイメージは、アップストリームのアドバイザリーデータベースからのデータを使用します。
- AlmaLinux Security Advisory
- Amazon Linux Security Center
- Arch Linux Security Tracker
- SUSE CVRF
- CWE Advisories
- Debian Security Bug Tracker
- GitHub Security Advisory
- Go Vulnerability Database
- CBL-Mariner Vulnerability Data
- NVD
- OSV
- Red Hat OVAL v2
- Red Hat Security Data API
- Photon Security Advisories
- Rocky Linux UpdateInfo
- Ubuntu CVE Tracker（2021年半ば以降のデータソースのみ）
GitLabでは、これらのスキャナーが提供するソースに加えて、次の脆弱性データベースを保持しています。
- プロプライエタリな[GitLab Advisory Database](https://gitlab.com/gitlab-org/security-products/gemnasium-db)
- オープンソースの[GitLab Advisory Database（オープンソースエディション）](https://gitlab.com/gitlab-org/advisories-community)
GitLab Ultimateプランでは、[GitLab Advisory Database](https://gitlab.com/gitlab-org/security-products/gemnasium-db)のデータがマージされ、外部ソースからのデータが拡張されます。GitLab PremiumプランとFreeプランでは、[GitLab Advisory Database（オープンソースエディション）](https://gitlab.com/gitlab-org/advisories-community)のデータがマージされ、外部ソースからのデータが拡張されます。この拡張は現在、Trivyスキャナーのアナライザーイメージにのみ適用されます。
他のアナライザーのデータベース更新情報については、[メンテナンステーブル](../_index.md#vulnerability-scanner-maintenance)を参照してください。
## 脆弱性のソリューション（自動修正）
{{< details >}}
- プラン: Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
{{< /details >}}
GitLabが自動的に生成するソリューションを適用することで、一部の脆弱性を修正できます。
修正サポートを有効にするには、スキャンツールが[`CS_DOCKERFILE_PATH`](#available-cicd-variables) CI/CD変数で指定された`Dockerfile`にアクセスできる_必要があります_。スキャンツールがこのファイルにアクセスできるようにするには、このドキュメントの「[コンテナスキャンテンプレートをオーバーライドする](#overriding-the-container-scanning-template)」セクションの説明に従って、`.gitlab-ci.yml`ファイルで[`GIT_STRATEGY: fetch`](../../../ci/runners/configure_runners.md#git-strategy)を設定する必要があります。
「[脆弱性のソリューション](../vulnerabilities/_index.md#resolve-a-vulnerability)」の詳細を参照してください。
## トラブルシューティング
### `docker: Error response from daemon: failed to copy xattrs`
Runnerが`docker` executorを使用し、NFSが使用されている場合（`/var/lib/docker`がNFSマウント上にある場合など）は、コンテナスキャンが次のようなエラーで失敗する可能性があります。
```plaintext
docker: Error response from daemon: failed to copy xattrs: failed to set xattr "security.selinux" on /path/to/file: operation not supported.
```
これはDockerのバグの結果であり、現在[修正されています（）](https://github.com/containerd/continuity/pull/138 "fs: add WithAllowXAttrErrors CopyOpt")。エラーを防ぐには、Runnerが使用しているDockerのバージョンが`18.09.03`以上であることを確認してください。詳細については、[イシュー10241（）](https://gitlab.com/gitlab-org/gitlab/-/issues/10241 "コンテナスキャンがNFSマウントで動作しない理由を調査する")を参照してください。
### 警告メッセージ`gl-container-scanning-report.json: no matching files`が表示される
これに関する情報については、[一般的なアプリケーションセキュリティのトラブルシューティングセクション](../../../ci/jobs/job_artifacts_troubleshooting.md#error-message-no-files-to-upload)を参照してください。
### AWS ECRからイメージをスキャンする際に`unexpected status code 401 Unauthorized: Not Authorized`が発生する
このエラーは、AWSリージョンが設定されておらず、スキャナーが認証トークンを取得できない場合に発生する可能性があります。`SECURE_LOG_LEVEL`を`debug`に設定すると、次のようなログメッセージが表示されます。
```shell
[35mDEBUG[0m failed to get authorization token: MissingRegion: could not find region configuration
```
これを解決するには、`AWS_DEFAULT_REGION`をCI/CD変数に追加します。
```yaml
variables:
AWS_DEFAULT_REGION: <AWS_REGION_FOR_ECR>
```
### `unable to open a file: open /home/gitlab/.cache/trivy/ee/db/metadata.json: no such file or directory`
圧縮されたTrivyデータベースはコンテナの`/tmp`フォルダーに保存され、ランタイム時に`/home/gitlab/.cache/trivy/{ee|ce}/db`に展開されます。このエラーは、Runner設定に`/tmp`ディレクトリのボリュームマウントがある場合に発生する可能性があります。
これを解決するには、`/tmp`フォルダーをバインドする代わりに、`/tmp`内の特定のファイルまたはフォルダー（`/tmp/myfile.txt`など）をバインドします。
### `context deadline exceeded`エラーを解決する
このエラーは、タイムアウトが発生したことを意味します。これを解決するには、十分な長さの期間で、`TRIVY_TIMEOUT`環境変数を`container_scanning`ジョブに追加します。
## 変更
コンテナスキャンアナライザーへの変更は、プロジェクトの[変更履歴](https://gitlab.com/gitlab-org/security-products/analyzers/container-scanning/-/blob/master/CHANGELOG.md)に表示されています。

1435
doc-locale/ja-jp/user/application_security/dependency_scanning/_index.md Normal file
View File

File diff suppressed because it is too large Load Diff

887
doc-locale/ja-jp/user/application_security/sast/_index.md Normal file
View File

@ -0,0 +1,887 @@
---
stage: Application Security Testing
group: Static Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: 静的アプリケーションセキュリティテスト（SAST）
---
<style>
table.sast-table tr:nth-child(even) {
background-color: transparent;
}
table.sast-table td {
border-left: 1px solid #dbdbdb;
border-right: 1px solid #dbdbdb;
border-bottom: 1px solid #dbdbdb;
}
table.sast-table tr td:first-child {
border-left: 0;
}
table.sast-table tr td:last-child {
border-right: 0;
}
table.sast-table ul {
font-size: 1em;
list-style-type: none;
padding-left: 0px;
margin-bottom: 0px;
}
table.no-vertical-table-lines td {
border-left: none;
border-right: none;
border-bottom: 1px solid #f0f0f0;
}
table.no-vertical-table-lines tr {
border-top: none;
}
</style>
{{< details >}}
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
{{< /details >}}
静的アプリケーションセキュリティテスト（SAST）では、本番環境に移行する前にソースコードの脆弱性を検出します。CI/CDパイプラインに直接統合されたSASTは、修正が最も簡単で費用対効果の高い開発中にセキュリティ上の問題を特定します。
開発の後半でセキュリティの脆弱性が見つかると、コストのかかる遅延や潜在的な漏えいが発生する可能性があります。SASTスキャンはコミットごとに自動的に実行されるため、ワークフローを中断することなく、すぐにフィードバックを得ることができます。
## 機能
次の表に、各機能を利用可能なGitLabプランを示します。
| 機能 | FreeおよびPremium | Ultimate |
|:-----------------------------------------------------------------------------------------|:-----------------------|:-----------------------|
| [オープンソースアナライザー](#supported-languages-and-frameworks)を使用した基本的なスキャン | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 |
| ダウンロード可能な[SAST JSONレポート](#download-a-sast-report) | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 |
| [GitLab高度なSAST](gitlab_advanced_sast.md)によるクロスファイルスキャン、クロスファンクションスキャン | {{< icon name="dotted-circle" >}} 不可 | {{< icon name="check-circle" >}} 可 |
| [マージリクエストウィジェット](#merge-request-widget)での新しい発見 | {{< icon name="dotted-circle" >}} 不可 | {{< icon name="check-circle" >}} 可 |
| [マージリクエストの変更ビュー](#merge-request-changes-view)での新しい発見 | {{< icon name="dotted-circle" >}} 不可 | {{< icon name="check-circle" >}} 可 |
| [脆弱性管理](../vulnerabilities/_index.md) | {{< icon name="dotted-circle" >}} 不可 | {{< icon name="check-circle" >}} 可 |
| [UIベースのスキャナー設定](#configure-sast-by-using-the-ui) | {{< icon name="dotted-circle" >}} 不可 | {{< icon name="check-circle" >}} 可 |
| [ルールセットのカスタマイズ](customize_rulesets.md) | {{< icon name="dotted-circle" >}} 不可 | {{< icon name="check-circle" >}} 可 |
| [高度な脆弱性追跡](#advanced-vulnerability-tracking) | {{< icon name="dotted-circle" >}} 不可 | {{< icon name="check-circle" >}} 可 |
## 要件
インスタンスでSASTアナライザーを実行する前に、以下があることを確認してください。
- [`docker`](https://docs.gitlab.com/runner/executors/docker.html)または[`kubernetes`](https://docs.gitlab.com/runner/install/kubernetes.html)executorを備えたLinuxベースのGitLab RunnerGitLab.comのためにホストされたRunnerを使用している場合は、デフォルトで有効になっています。
- Windows Runnerはサポートされていません。
- amd64以外のCPUアーキテクチャはサポートされていません。
- GitLab CI/CD設定ファイル（`.gitlab-ci.yml`）には、`test`ステージを含める必要がありますが、これはデフォルトで含まれています。`.gitlab-ci.yml`ファイルでステージを再定義する場合は、`test`ステージが必要です。
## サポートされている言語とフレームワーク
GitLab SASTは、次の言語とフレームワークのスキャンをサポートしています。
利用可能なスキャンオプションは、GitLabのプランによって異なります。
- Ultimateでは、[GitLab高度なSAST](gitlab_advanced_sast.md)のほうがより正確な結果が得られます。サポートされている言語で使用する必要があります。
- 全プランで、オープンソーススキャナーに基づいてGitLabが提供するアナライザーを使用してコードをスキャンできます。
SASTでの言語サポートの計画の詳細については、[カテゴリの方向性](https://about.gitlab.com/direction/application_security_testing/static-analysis/sast/#language-support)ページを参照してください。
| 言語 | [GitLab高度なSAST](gitlab_advanced_sast.md)でサポート（Ultimate のみ） | 別の[アナライザー](analyzers.md)でサポート（全プラン） |
|-----------------------------------------|-----------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Apex（Salesforce） | {{< icon name="dotted-circle" >}} 不可 | {{< icon name="check-circle" >}}可: [PMD-Apex](https://gitlab.com/gitlab-org/security-products/analyzers/pmd-apex) |
| C | {{< icon name="dotted-circle" >}}不可。[エピック14271](https://gitlab.com/groups/gitlab-org/-/epics/14271)で追跡 | {{< icon name="check-circle" >}}可: [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep)（[GitLab管理ルール](rules.md#semgrep-based-analyzer)を使用） |
| C++ | {{< icon name="dotted-circle" >}}不可。[エピック14271](https://gitlab.com/groups/gitlab-org/-/epics/14271)で追跡 | {{< icon name="check-circle" >}}可: [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep)（[GitLab管理ルール](rules.md#semgrep-based-analyzer)を使用） |
| C# | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}}可: [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep)（[GitLab管理ルール](rules.md#semgrep-based-analyzer)を使用） |
| Elixir（Phoenix） | {{< icon name="dotted-circle" >}} 不可 | {{< icon name="check-circle" >}}可: [Sobelow](https://gitlab.com/gitlab-org/security-products/analyzers/sobelow) |
| Go | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}}可: [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep)（[GitLab管理ルール](rules.md#semgrep-based-analyzer)を使用） |
| Groovy | {{< icon name="dotted-circle" >}} 不可 | {{< icon name="check-circle" >}}可: [SpotBugs](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs)（find-sec-bugsプラグイン<sup><b><a href="#spotbugs-footnote">1</a></b></sup>を使用） |
| Java | {{< icon name="check-circle" >}}可。Java Server Pages（JSP）を含む | {{< icon name="check-circle" >}}可: [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep)（[GitLab管理ルール](rules.md#semgrep-based-analyzer)を使用）（Androidを含む） |
| JavaScript（Node.js、Reactを含む） | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}}可: [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep)（[GitLab管理ルール](rules.md#semgrep-based-analyzer)を使用） |
| Kotlin | {{< icon name="dotted-circle" >}}不可。[エピック15173](https://gitlab.com/groups/gitlab-org/-/epics/15173)で追跡 | {{< icon name="check-circle" >}}可: [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep)（[GitLab管理ルール](rules.md#semgrep-based-analyzer)を使用）（Androidを含む） |
| Objective-C（iOS） | {{< icon name="dotted-circle" >}} 不可 | {{< icon name="check-circle" >}}可: [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep)（[GitLab管理ルール](rules.md#semgrep-based-analyzer)を使用） |
| PHP | {{< icon name="dotted-circle" >}}不可。[エピック14273](https://gitlab.com/groups/gitlab-org/-/epics/14273)で追跡 | {{< icon name="check-circle" >}}可: [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep)（[GitLab管理ルール](rules.md#semgrep-based-analyzer)を使用） |
| Python | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}}可: [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep)（[GitLab管理ルール](rules.md#semgrep-based-analyzer)を使用） |
| Ruby（Ruby on Railsを含む） | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}}可: [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep)（[GitLab管理ルール](rules.md#semgrep-based-analyzer)を使用） |
| Scala | {{< icon name="dotted-circle" >}}不可。[エピック15174](https://gitlab.com/groups/gitlab-org/-/epics/15174)で追跡 | {{< icon name="check-circle" >}}可: [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep)（[GitLab管理ルール](rules.md#semgrep-based-analyzer)を使用） |
| Swift（iOS） | {{< icon name="dotted-circle" >}} 不可 | {{< icon name="check-circle" >}}可: [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep)（[GitLab管理ルール](rules.md#semgrep-based-analyzer)を使用） |
| TypeScript | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}}可: [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep)（[GitLab管理ルール](rules.md#semgrep-based-analyzer)を使用） |
| YAML<sup><b><a href="#yaml-footnote">2</a></b></sup> | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}}可: [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep)（[GitLab管理ルール](rules.md#semgrep-based-analyzer)を使用） |
| Java Properties | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}}可: [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep)（[GitLab管理ルール](rules.md#semgrep-based-analyzer)を使用） |
**脚注:**
1. <a id="spotbugs-footnote"></a>SpotBugsベースのアナライザーは、[Gradle](https://gradle.org/)、[Maven](https://maven.apache.org/)、[SBT](https://www.scala-sbt.org/)をサポートしています。また、[Gradleラッパー](https://docs.gradle.org/current/userguide/gradle_wrapper.html)、[Grails](https://grails.org/)、[Mavenラッパー](https://github.com/takari/maven-wrapper)などのバリアントでも使用できます。ただし、SpotBugsには、[Ant](https://ant.apache.org/)ベースのプロジェクトで使用する場合、[制限事項](https://gitlab.com/gitlab-org/gitlab/-/issues/350801)があります。AntベースのJavaまたはScalaプロジェクトには、GitLab高度なSASTまたはSemgrepベースのアナライザーを使用する必要があります。
1. <a id="yaml-footnote"></a>`YAML`のサポートは、次のファイルパターンに制限されています。
- `application*.yml`
- `application*.yaml`
- `bootstrap*.yml`
- `bootstrap*.yaml`
SAST CI/CDテンプレートには、KubernetesマニフェストとHelmチャートをスキャンできるアナライザージョブも含まれています。このジョブはデフォルトでオフになっています。「[Kubesecアナライザーを有効にする](#enabling-kubesec-analyzer)」を参照するか、代わりに、追加のプラットフォームをサポートする[IaCスキャン](../iac_scanning/_index.md)をご検討ください。
サポートされなくなったSASTアナライザーの詳細については、「[サポートが終了したアナライザー](analyzers.md#analyzers-that-have-reached-end-of-support)」を参照してください。
## 高度な脆弱性追跡
{{< details >}}
- プラン: Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
{{< /details >}}
ソースコードは不安定です。デベロッパーが変更を加えると、ソースコードがファイル内またはファイル間で移動する可能性があります。セキュリティアナライザーは、[脆弱性レポート](../vulnerability_report/_index.md)で追跡されている脆弱性をすでに報告している可能性があります。これらの脆弱性は、見つけ出して修正できるように、特定の問題のあるコードフラグメントにリンクされています。コードフラグメントが移動する際の追跡が確実でない場合、同じ脆弱性が再度報告される可能性があるため、脆弱性管理がより困難になります。
GitLab SASTは、高度な脆弱性追跡アルゴリズムを使用して、同じ脆弱性がリファクタリングまたは無関係な変更によってファイル内で移動した場合、より正確に特定します。
高度な脆弱性追跡は、[サポートされている言語](#supported-languages-and-frameworks)と[アナライザー](analyzers.md)のサブセットで使用できます。
- C（Semgrepベースのみ）
- C++（Semgrepベースのみ）
- C#（GitLab高度なSASTとSemgrepベースのアナライザー）
- Go（GitLab高度なSASTとSemgrepベースのアナライザー）
- Java（GitLab高度なSASTとSemgrepベースのアナライザー）
- JavaScript（GitLab高度なSASTとSemgrepベースのアナライザー）
- PHP（Semgrepベースのアナライザーのみ）
- Python（GitLab高度なSASTとSemgrepベースのアナライザー）
- Ruby（Semgrepベースのアナライザーのみ）
より多くの言語とアナライザーのサポートが[このエピック](https://gitlab.com/groups/gitlab-org/-/epics/5144)で追跡されます。
詳細については、機密プロジェクト（`https://gitlab.com/gitlab-org/security-products/post-analyzers/tracking-calculator`）を参照してください。このプロジェクトのコンテンツは、GitLabチームメンバーのみが利用できます。
## 脆弱性の自動修正
{{< history >}}
- GitLab 15.9で、`sec_mark_dropped_findings_as_resolved`という名前の[プロジェクトレベルのフラグ](../../../administration/feature_flags.md)とともに[導入](https://gitlab.com/gitlab-org/gitlab/-/issues/368284)されました。
- GitLab 15.10で、デフォルトで有効になりました。GitLab.comでプロジェクトのフラグを無効にする必要がある場合は、[サポートにお問い合わせください](https://about.gitlab.com/support/)。
- GitLab 16.2で、[機能フラグが削除](https://gitlab.com/gitlab-org/gitlab/-/issues/375128)されました。
{{< /history >}}
関連性の高い脆弱性に集中できるように、GitLab SASTは次の場合に脆弱性を自動的に[解決](../vulnerabilities/_index.md#vulnerability-status-values)します。
- [定義済みのルールを無効する](customize_rulesets.md#disable-predefined-rules)場合
- デフォルトのルールセットからルールを削除する場合
自動解決は、[Semgrepベースのアナライザー](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep)からの検出結果にのみ使用できます。脆弱性管理システムは、自動的に解決された脆弱性にコメントを残すため、脆弱性の履歴記録が残ります。
後でルールを再度有効にすると、トリアージのために検出結果がもう一度開きます。
## サポートされているディストリビューション
デフォルトのスキャナーイメージは、サイズと保守性のためにベースのAlpineイメージ上にビルドされています。
### FIPS対応イメージ
GitLabは、[Red Hat UBI](https://www.redhat.com/en/blog/introducing-red-hat-universal-base-image)ベースのイメージに基づいて、FIPS 140検証済みの暗号学的モジュールを使用するイメージバージョンを提供しています。FIPS対応イメージを使用するには、次のいずれかを実行します。
- `SAST_IMAGE_SUFFIX`を`-fips`に設定します。
- `-fips`拡張子をデフォルトのイメージ名に追加します。
次に例を示します。
```yaml
variables:
SAST_IMAGE_SUFFIX: '-fips'
include:
- template: Jobs/SAST.gitlab-ci.yml
```
FIPS準拠イメージは、GitLab高度なSASTとSemgrepベースのアナライザーでのみ使用できます。
{{< alert type="warning" >}}
FIPS準拠の方法でSASTを使用するには、[他のアナライザーの実行を除外](analyzers.md#customize-analyzers)する必要があります。FIPS対応イメージを使用して、[非rootユーザーのRunner](https://docs.gitlab.com/runner/install/kubernetes_helm_chart_configuration.html#run-with-non-root-user)で高度なSASTまたはSemgrepを実行する場合は、`runners.kubernetes.pod_security_context`の下で`run_as_user`属性を更新して、[イメージによって作成される](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/blob/a5d822401014f400b24450c92df93467d5bbc6fd/Dockerfile.fips#L58)`gitlab`ユーザーのID（`1000`）を使用する必要があります。
{{< /alert >}}
## 脆弱性の詳細
SASTの脆弱性には、検出された脆弱性の主要なCommon Weakness Enumeration（CWE）識別子に従って名前が付けられています。スキャナーが検出した特定の問題の詳細については、各脆弱性の検出結果の説明をお読みください。
SASTカバレッジの詳細については、「[SASTルール](rules.md)」を参照してください。
## SASTレポートのダウンロード
各SASTアナライザーは、ジョブアーティファクトとしてJSONレポートを出力します。ファイルには、検出されたすべての脆弱性の詳細が含まれています。ファイルを[ダウンロード](../../../ci/jobs/job_artifacts.md#download-job-artifacts)して、GitLabの外部で処理できます。
詳細については、以下を参照してください。
- [SASTレポートファイルスキーマ](https://gitlab.com/gitlab-org/security-products/security-report-schemas/-/blob/master/dist/sast-report-format.json)
- [SASTレポートファイルの例](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/blob/main/qa/expect/js/default/gl-sast-report.json)
## SASTの結果を表示する
{{< details >}}
- プラン: Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
{{< /details >}}
Ultimateでは、[SASTレポートファイル](#download-a-sast-report)はGitLabによって処理され、詳細は以下のUIに表示されます。
- [マージリクエストウィジェット](#merge-request-widget)
- [マージリクエストの変更ビュー](#merge-request-changes-view)
- [脆弱性レポート](../vulnerability_report/_index.md)
- [パイプラインセキュリティレポート](../vulnerability_report/pipeline.md)
パイプラインは、SASTやDASTスキャンを含む複数のジョブで構成されています。何らかの理由でジョブが完了しなかった場合、セキュリティダッシュボードにSASTスキャナーの出力は表示されません。たとえば、SASTジョブは完了したがDASTジョブが失敗した場合、セキュリティダッシュボードにSASTの結果は表示されません。失敗した場合、アナライザーは[終了コード](../../../development/integrations/secure.md#exit-code)を出力します。
### マージリクエストウィジェット
ターゲットブランチからのレポートを比較できる場合、SASTの結果がマージリクエストウィジェット領域に表示されます。マージリクエストウィジェットには以下が表示されます。
- MRによって導入された新しいSASTの検出結果
- MRによって解決された既存の検出結果
利用可能な場合は常に、[高度な脆弱性追跡](#advanced-vulnerability-tracking)を使用して結果が比較されます。
![セキュリティマージリクエストウィジェット](img/sast_mr_widget_v16_7.png)
### マージリクエストの変更ビュー
{{< history >}}
- GitLab 16.6で、`sast_reports_in_inline_diff`という名前の[フラグ](../../../administration/feature_flags.md)とともに[導入](https://gitlab.com/groups/gitlab-org/-/epics/10959)されました。デフォルトでは無効になっています。
- GitLab 16.8で、デフォルトで有効になりました。
- GitLab 16.9で、[機能フラグが削除](https://gitlab.com/gitlab-org/gitlab/-/issues/410191)されました。
{{< /history >}}
SASTの結果は、マージリクエストの**変更**ビューに表示されます。SASTの問題を含む行は、ガターの横に記号でマークされます。記号を選択して問題のリストを表示し、問題を選択して詳細を表示します。
![SASTインラインインジケーター](img/sast_inline_indicator_v16_7.png)
## スキャナーをコントリビュートする
[セキュリティスキャナーのインテグレーション](../../../development/integrations/secure.md)に関するドキュメントでは、他のセキュリティスキャナーをGitLabに統合する方法について説明しています。
## 設定
SASTスキャンは、CI/CDパイプラインで実行されます。GitLab管理のCI/CDテンプレートをパイプラインに追加すると、適切な[SASTアナライザー](analyzers.md)が自動的にコードをスキャンし、結果を[SASTレポートアーティファクト](../../../ci/yaml/artifacts_reports.md#artifactsreportssast)として保存します。
プロジェクトのSASTを設定するには、次の手順を実行します。
- [Auto DevOps](../../../topics/autodevops/_index.md)によって提供される[自動SAST](../../../topics/autodevops/stages.md#auto-sast)を使用します。
- [CI/CD YAMLでSASTを設定](#configure-sast-in-your-cicd-yaml)します。
- [UIを使用してSASTを設定](#configure-sast-by-using-the-ui)します。
[スキャン実行を適用](../_index.md#enforce-scan-execution)することで、多くのプロジェクトでSASTを有効にできます。
高度なSAST（GitLab Ultimateでのみ利用可能）を設定するには、この[手順](gitlab_advanced_sast.md#configuration)に従ってください。
必要に応じて、[設定変数を変更](_index.md#available-cicd-variables)したり、[検出ルールをカスタマイズ](customize_rulesets.md)したりできますが、GitLab SASTはデフォルト設定で使用するように設計されています。
### CI/CD YAMLでSASTを設定する
SASTを有効にするには、[`SAST.gitlab-ci.yml`テンプレート](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml)を[含めます](../../../ci/yaml/_index.md#includetemplate)。このテンプレートは、GitLabインストールの一部として提供されます。
次の内容をコピーして、`.gitlab-ci.yml`ファイルの末尾に貼り付けます。`include`行がすでに存在する場合は、その下に`template`行のみを追加します。
```yaml
include:
- template: Jobs/SAST.gitlab-ci.yml
```
含まれているテンプレートは、CI/CDパイプラインにSASTジョブを作成し、プロジェクトのソースコードで潜在的な脆弱性をスキャンします。
結果は、後でダウンロードして分析できる[SASTレポートアーティファクト](../../../ci/yaml/artifacts_reports.md#artifactsreportssast)として保存されます。ダウンロードすると、常に利用可能な最新のSASTアーティファクトを受け取ります。
### 安定版と最新版のSASTテンプレート
SASTには、セキュリティテストをCI/CDパイプラインに組み込むための2つのテンプレートが用意されています。
- [`SAST.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml)（推奨）
安定版テンプレートは、信頼性が高く一貫性のあるSASTエクスペリエンスを提供します。CI/CDパイプラインで安定性と予測可能な動作を必要とするほとんどのユーザーおよびプロジェクトでは、安定したテンプレートを使用する必要があります。
- [`SAST.latest.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/SAST.latest.gitlab-ci.yml)
このテンプレートは、最先端の機能にアクセスしてテストしたい人を対象としています。安定しているとは見なされておらず、次のメジャーリリースで計画されている破壊的な変更が含まれている可能性があります。このテンプレートを使用すると、新しい機能やアップデートが安定版リリースの一部になる前に試すことができるため、潜在的な不安定さをいとわず、新しい機能に関するフィードバックを提供することに意欲的なユーザーに最適です。
### UIを使用してSASTを設定する
UIを使用してSASTを有効化および設定できます。設定はデフォルトのままにすることも、カスタマイズすることも可能です。使用できる方法は、GitLabのライセンスプランによって異なります。
#### カスタマイズしてSASTを設定する
{{< details >}}
- プラン: Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
{{< /details >}}
> GitLab 16.2で、UIから個々のSASTアナライザーの設定オプションを[削除](https://gitlab.com/gitlab-org/gitlab/-/issues/410013)しました。
{{< alert type="note" >}}
この設定ツールは、既存の`.gitlab-ci.yml`ファイルがない場合、または設定ファイルが最小限しかない場合に最もうまく機能します。複雑なGitLab設定ファイルがある場合は、正常に解析されず、エラーが発生する可能性があります。
{{< /alert >}}
カスタマイズしてSASTを有効化および設定するには:
1. 左側のサイドバーで、**検索または移動先**を選択し、プロジェクトを検索します。
1. **セキュリティ>セキュリティ設定**を選択します。
1. プロジェクトのデフォルトブランチの最新のパイプラインが完了し、有効な`SAST`アーティファクトが生成された場合は、**SASTの設定**を選択し、それ以外の場合は静的アプリケーションセキュリティテスト（SAST）行の**SASTの有効化**を選択します。
1. SASTのカスタム値を入力します。
カスタム値は`.gitlab-ci.yml`ファイルに保存されます。SASTの設定ページにないCI/CD変数については、それらの値はGitLab SASTテンプレートから継承されます。
1. **マージリクエストの作成**を選択します。
1. マージリクエストをレビューしてマージします。
これで、パイプラインにSASTジョブが含まれます。
#### デフォルト設定のみでSASTを設定する
{{< alert type="note" >}}
この設定ツールは、既存の`.gitlab-ci.yml`ファイルがない場合、または設定ファイルが最小限しかない場合に最もうまく機能します。複雑なGitLab設定ファイルがある場合は、正常に解析されず、エラーが発生する可能性があります。
{{< /alert >}}
デフォルト設定でSASTを有効化および設定するには:
1. 左側のサイドバーで、**検索または移動先**を選択し、プロジェクトを検索します。
1. **セキュリティ>セキュリティ設定**を選択します。
1. SASTセクションで**マージリクエスト経由で設定**を選択します。
1. マージリクエストをレビューしてマージし、SASTを有効にします。
これで、パイプラインにSASTジョブが含まれます。
### SASTジョブをオーバーライドする
ジョブ定義をオーバーライドする（`variables`、`dependencies`、または[`rules`](../../../ci/yaml/_index.md#rules)のようなプロパティを変更する場合など）には、オーバーライドするSASTジョブと同じ名前でジョブを宣言します。テンプレートの挿入後にこの新しいジョブを配置し、その下に追加のキーを指定します。たとえば、これにより`spotbugs`アナライザーの`FAIL_NEVER`が有効になります。
```yaml
include:
- template: Jobs/SAST.gitlab-ci.yml
spotbugs-sast:
variables:
FAIL_NEVER: 1
```
### マイナーイメージバージョンにピン留めする
GitLab管理のCI/CDテンプレートは、メジャーバージョンを指定し、そのメジャーバージョン内の最新のアナライザーリリースを自動的にプルします。
場合によっては、特定のバージョンを使用しなければならない場合があります。たとえば、以降のリリースでリグレッションを回避しなければならない場合があります。
自動更新の動作をオーバーライドするには、[`SAST.gitlab-ci.yml`テンプレート](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml)を含めた後、CI/CD設定ファイルで`SAST_ANALYZER_IMAGE_TAG` CI/CD変数を設定します。
この変数は、特定のジョブ内でのみ設定してください。[トップレベル](../../../ci/variables/_index.md#define-a-cicd-variable-in-the-gitlab-ciyml-file)で設定すると、設定したバージョンが他のSASTアナライザーに使用されます。
タグは次のように設定できます。
- `3`のようなメジャーバージョン: パイプラインは、このメジャーバージョン内でリリースされるマイナーまたはパッチアップデートを使用します。
- `3.7`のようなマイナーバージョン: パイプラインは、このマイナーバージョン内でリリースされるパッチアップデートを使用します。
- `3.7.0`のようなパッチバージョン: パイプラインはアップデートを受け取りません。
次の例では、`semgrep`アナライザーの特定のマイナーバージョンと、`brakeman`アナライザーの特定のパッチバージョンを使用します。
```yaml
include:
- template: Jobs/SAST.gitlab-ci.yml
semgrep-sast:
variables:
SAST_ANALYZER_IMAGE_TAG: "3.7"
brakeman-sast:
variables:
SAST_ANALYZER_IMAGE_TAG: "3.1.1"
```
### CI/CD変数を使用してプライベートリポジトリの認証情報を渡す
一部のアナライザーでは、分析を実行するためにプロジェクトの依存関係をダウンロードする必要があります。一方、そのような依存関係はプライベートGitリポジトリに存在する可能性があり、ダウンロードするにはユーザー名やパスワードなどの認証情報が必要になります。アナライザーによっては、[カスタムCI/CD変数](#custom-cicd-variables)を介してそのような認証情報をアナライザーに提供できます。
#### CI/CD変数を使用してプライベートMavenリポジトリにユーザー名とパスワードを渡す
プライベートMavenリポジトリにログイン認証情報が必要な場合は、`MAVEN_CLI_OPTS` CI/CD変数を使用できます。
詳細については、[プライベートMavenリポジトリの使用方法](../dependency_scanning/_index.md#authenticate-with-a-private-maven-repository)を参照してください。
### Kubesecアナライザーを有効にする
Kubesecアナライザーを有効にするには、`SCAN_KUBERNETES_MANIFESTS`を`"true"`に設定する必要があります。`.gitlab-ci.yml`で、次のように定義します。
```yaml
include:
- template: Jobs/SAST.gitlab-ci.yml
variables:
SCAN_KUBERNETES_MANIFESTS: "true"
```
### Semgrepベースのアナライザーで他の言語をスキャンする
[Semgrepベースのアナライザー](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep)をカスタマイズして、GitLab管理のルールセットで[サポート](#supported-languages-and-frameworks)されていない言語をスキャンできます。ただし、GitLabではこれらの他の言語のルールセットを提供していなため、それらをカバーするには[カスタムルールセット](customize_rulesets.md#build-a-custom-configuration)を提供する必要があります。また、関連ファイルが変更されたときにジョブが実行されるように、`semgrep-sast` CI/CD ジョブの`rules`を変更する必要もあります。
#### Rustアプリケーションをスキャンする
たとえば、Rustアプリケーションをスキャンするには、次の手順を実行する必要があります。
1. Rustのカスタムルールセットを提供します。リポジトリのルートにある`.gitlab/`ディレクトリに`sast-ruleset.toml`という名前のファイルを作成します。次の例では、SemgrepレジストリのRustのデフォルトルールセットを使用します。
```toml
[semgrep]
description = "Rust ruleset for Semgrep"
targetdir = "/sgrules"
timeout = 60
[[semgrep.passthrough]]
type = "url"
value = "https://semgrep.dev/c/p/rust"
target = "rust.yml"
```
詳細については、[ルールセットのカスタマイズ](customize_rulesets.md#build-a-custom-configuration)を参照してください。
1. `semgrep-sast`ジョブをオーバーライドして、Rust（`.rs`）ファイルを検出するルールを追加します。`.gitlab-ci.yml`ファイルで以下を定義します。
```yaml
include:
- template: Jobs/SAST.gitlab-ci.yml
semgrep-sast:
rules:
- if: $CI_COMMIT_BRANCH
exists:
- '**/*.rs'
# include any other file extensions you need to scan from the semgrep-sast template: Jobs/SAST.gitlab-ci.yml
```
### プリコンパイル
ほとんどのGitLab SASTアナライザーは、最初にコンパイルせずにソースコードを直接スキャンします。ただし、技術的な理由により、SpotBugsベースのアナライザーはコンパイルされたバイトコードをスキャンします。
デフォルトでは、SpotBugsベースのアナライザーが依存関係のフェッチとコードのコンパイルを自動的に試行し、スキャンできるようにします。自動コンパイルは、以下の場合に失敗する可能性があります。
- プロジェクトにカスタムビルド設定が必要な場合
- アナライザーに組み込まれていない言語バージョンを使用している場合
これらの問題を解決するには、アナライザーのコンパイル手順をスキップし、代わりにパイプラインの以前の段階からアーティファクトを直接提供する必要があります。この戦略は、_プリコンパイル_と呼ばれます。
プリコンパイルを使用するには:
1. プロジェクトの依存関係をプロジェクトの作業ディレクトリ内のディレクトリに出力し、[`artifacts: paths`構成を設定](../../../ci/yaml/_index.md#artifactspaths)することにより、そのディレクトリをアーティファクトとして保存します。
1. `COMPILE: "false"` CI/CD変数をアナライザージョブに提供して、自動コンパイルを無効にします。
1. compilationステージをアナライザージョブの依存関係として追加します。
アナライザーがコンパイルされたアーティファクトを認識できるようにするには、ベンダーディレクトリへのパスを明示的に指定する必要があります。この設定は、プロジェクトのセットアップ方法によって異なる場合があります。Mavenプロジェクトの場合は、`MAVEN_REPO_PATH`を使用できます。利用可能なオプションの完全なリストについては、「[アナライザーの設定](#analyzer-settings)」を参照してください。
次の例では、Mavenプロジェクトをプリコンパイルし、SpotBugsベースのSASTアナライザーに提供します。
```yaml
stages:
- build
- test
include:
- template: Jobs/SAST.gitlab-ci.yml
build:
image: maven:3.6-jdk-8-slim
stage: build
script:
- mvn package -Dmaven.repo.local=./.m2/repository
artifacts:
paths:
- .m2/
- target/
spotbugs-sast:
dependencies:
- build
variables:
MAVEN_REPO_PATH: $CI_PROJECT_DIR/.m2/repository
COMPILE: "false"
artifacts:
reports:
sast: gl-sast-report.json
```
### マージリクエストパイプラインでジョブを実行する
「[マージリクエストパイプラインでセキュリティスキャンツールを使用する](../detect/roll_out_security_scanning.md#use-security-scanning-tools-with-merge-request-pipelines)」を参照してください。
### 利用可能なCI/CD変数
SASTは、`.gitlab-ci.yml`の[`variables`](../../../ci/yaml/_index.md#variables)パラメーターを使用して設定できます。
{{< alert type="warning" >}}
これらの変更をデフォルトブランチにマージする前に、GitLabセキュリティスキャンツールのすべてのカスタマイズをマージリクエストでテストする必要があります。そうしないと、誤検出が多数発生するなど、予期しない結果が生じる可能性があります。
{{< /alert >}}
次の例では、SASTテンプレートを含めて、すべてのジョブで`SEARCH_MAX_DEPTH`変数を`10`にオーバーライドします。テンプレートはパイプライン設定の[前に評価](../../../ci/yaml/_index.md#include)されるため、変数の最後の記述が優先されます。
```yaml
include:
- template: Jobs/SAST.gitlab-ci.yml
variables:
SEARCH_MAX_DEPTH: 10
```
#### カスタム公開認証局（CA）
カスタム公開認証局（CA）を信頼するには、SAST環境で信頼するCA証明書のバンドルに`ADDITIONAL_CA_CERT_BUNDLE`変数を設定します。`ADDITIONAL_CA_CERT_BUNDLE`値には、[X.509 PEM公開鍵証明書のテキスト表現](https://www.rfc-editor.org/rfc/rfc7468#section-5.1)が含まれている必要があります。たとえば、`.gitlab-ci.yml`ファイルでこの値を設定するには、以下を実行します。
```yaml
variables:
ADDITIONAL_CA_CERT_BUNDLE: |
-----BEGIN CERTIFICATE-----
MIIGqTCCBJGgAwIBAgIQI7AVxxVwg2kch4d56XNdDjANBgkqhkiG9w0BAQsFADCB
...
jWgmPqF3vUbZE0EyScetPJquRFRKIesyJuBFMAs=
-----END CERTIFICATE-----
```
`ADDITIONAL_CA_CERT_BUNDLE`値は、[UIのカスタム変数](../../../ci/variables/_index.md#for-a-project)として設定することもできます。`file`として設定する場合は、証明書のパスが必要です。変数として設定する場合は、証明書のテキスト表現が必要です。
#### Dockerイメージ
以下は、Dockerイメージ関連のCI/CD変数です。
| CI/CD変数 | 説明 |
|---------------------------|---------------------------------------------------------------------------------------------------------------------------------------|
| `SECURE_ANALYZERS_PREFIX` | デフォルトイメージを提供するDockerレジストリ（プロキシ）の名前をオーバーライドします。詳細については、[アナライザーのカスタマイズ](analyzers.md)を参照してください。 |
| `SAST_EXCLUDED_ANALYZERS` | 実行すべきではないデフォルトイメージの名前。詳細については、[アナライザーのカスタマイズ](analyzers.md)を参照してください。 |
| `SAST_ANALYZER_IMAGE_TAG` | アナライザーイメージのデフォルトバージョンをオーバーライドします。詳細については、[アナライザーイメージバージョンのピン留め](#pinning-to-minor-image-version)を参照してください。 |
| `SAST_IMAGE_SUFFIX` | イメージ名に追加されたサフィックス`-fips`に設定すると、`FIPS-enabled`イメージがスキャンに使用されます。詳細については、「[FIPS対応イメージ](#fips-enabled-images)」を参照してください。 |
#### 脆弱性フィルター
<table class="sast-table">
<thead>
<tr>
<th>CI/CD変数</th>
<th>説明</th>
<th>デフォルト値</th>
<th>アナライザー</th>
</tr>
</thead>
<tbody>
<tr>
<td rowspan="3">
<code>SAST_EXCLUDED_PATHS</code>
</td>
<td rowspan="3">
脆弱性を除外するためのパスのカンマ区切りリスト。この変数の正確な処理は、使用するアナライザーによって異なります。<sup><b><a href="#sast-excluded-paths-description">1</a></b></sup>
</td>
<td rowspan="3">
<code><a href="https://gitlab.com/gitlab-org/gitlab/blob/v17.3.0-ee/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml#L13">spec、test、tests、tmp</a></code>
</td>
<td>
<a href="https://gitlab.com/gitlab-org/security-products/analyzers/semgrep">Semgrep</a><sup><b><a href="#sast-excluded-paths-semgrep">2</a></b>、</sup><sup><b><a href="#sast-excluded-paths-all-other-sast-analyzers">3</a></b></sup>
</td>
</tr>
<tr>
<td>
<a href="gitlab_advanced_sast.md">GitLab高度なSAST</a><sup><b><a href="#sast-excluded-paths-semgrep">2</a></b>、</sup><sup><b><a href="#sast-excluded-paths-all-other-sast-analyzers">3</a></b></sup>
</td>
</tr>
<tr>
<td>
その他すべてのSASTアナライザー<sup><b><a href="#sast-excluded-paths-all-other-sast-analyzers">3</a></b></sup>
</td>
</tr>
<tr>
<td>
<!-- markdownlint-disable MD044 --><code>SAST_SPOTBUGS_EXCLUDED_BUILD_PATHS</code><!-- markdownlint-enable MD044 -->
</td>
<td>
ビルドとスキャンからディレクトリを除外するためのパスのカンマ区切りリスト。
</td>
<td>なし</td>
<td>
<a href="https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs">SpotBugs</a><sup><b><a href="#sast-spotbugs-excluded-build-paths-description">4</a></b></sup>
</td>
</tr>
<tr>
<td rowspan="3">
<code>SEARCH_MAX_DEPTH</code>
</td>
<td rowspan="3">
スキャンする一致ファイルを検索する際に、アナライザーが下降するディレクトリレベルの数。<sup><b><a href="#search-max-depth-description">5</a></b></sup>
</td>
<td rowspan="2">
<code><a href="https://gitlab.com/gitlab-org/gitlab/-/blob/v17.3.0-ee/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml#L54">20</a></code>
</td>
<td>
<a href="https://gitlab.com/gitlab-org/security-products/analyzers/semgrep">Semgrep</a>
</td>
</tr>
<tr>
<td>
<a href="gitlab_advanced_sast.md">GitLab高度なSAST</a>
</td>
</tr>
<tr>
<td>
<code><a href="https://gitlab.com/gitlab-org/gitlab/blob/v17.3.0-ee/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml#L26">4</a></code>
</td>
<td>
その他すべてのSASTアナライザー
</td>
</tr>
</tbody>
</table>
**脚注:**
1. <a id="sast-excluded-paths-description"></a>ビルドツールで使用される一時ディレクトリは、誤検出を生成する可能性があるため、除外しなければならない場合があります。パスを除外するには、デフォルトの除外パスをコピーして貼り付け、除外する独自のパスを**追加**します。デフォルトの除外パスを指定しない場合、デフォルトはオーバーライドされ、指定したパス_のみ_がSASTスキャンから除外されます。
1. <a id="sast-excluded-paths-semgrep"></a>これらのアナライザーでは、`SAST_EXCLUDED_PATHS`が**プリフィルター**として実装されており、スキャンの実行_前_に適用されます。
アナライザーは、パスがコンマ区切りのパターンのいずれかに一致するファイルまたはディレクトリをスキップします。
たとえば、`SAST_EXCLUDED_PATHS`が`*.py,tests`に設定されている場合:
- `*.py`は以下を無視します。
- `foo.py`
- `src/foo.py`
- `foo.py/bar.sh`
- `tests`は以下を無視します。
- `tests/foo.py`
- `a/b/tests/c/foo.py`
各パターンは、[gitignore](https://git-scm.com/docs/gitignore#_pattern_format)と同じ構文を使用するglobスタイルのパターンです。
1. <a id="sast-excluded-paths-all-other-sast-analyzers"></a>これらのアナライザーで、`SAST_EXCLUDED_PATHS`は**ポストフィルター**として実装され、スキャンが実行された_後_に適用されます。
パターンには、glob（サポートされているパターンについては[`doublestar.Match`](https://pkg.go.dev/github.com/bmatcuk/doublestar/v4@v4.0.2#Match)を参照）、またはファイルパスやフォルダパス（`doc,spec`など）を使用できます。親ディレクトリもパターンに一致します。
`SAST_EXCLUDED_PATHS`のポストフィルター実装は、すべてのSASTアナライザーで使用できます。上付き文字**[2](#sast-excluded-paths-semgrep)**が付いたものなど、一部のSASTアナライザーは、`SAST_EXCLUDED_PATHS`をプリフィルターとポストフィルターの両方として実装します。プリフィルターは、スキャン対象のファイル数を減らすため、効率が向上します。
`SAST_EXCLUDED_PATHS`をプリフィルターとポストフィルターの両方としてサポートするアナライザーの場合、最初にプリフィルターが適用され、次にポストフィルターが残りの脆弱性に適用されます。
1. <a id="sast-spotbugs-excluded-build-paths-description"></a>この変数では、パスパターンにはglob（サポートされているパターンについては[`doublestar.Match`](https://pkg.go.dev/github.com/bmatcuk/doublestar/v4@v4.0.2#Match)を参照）を使用できます。パスパターンがサポートされているビルドファイルと一致する場合、ディレクトリはビルドプロセスから除外されます。
- `build.sbt`
- `grailsw`
- `gradlew`
- `build.gradle`
- `mvnw`
- `pom.xml`
- `build.xml`
たとえば、パス`project/subdir/pom.xml`を持つビルドファイルを含む`maven`プロジェクトのビルドとスキャンを除外するには、`project/*/*.xml`や`**/*.xml`など、ビルドファイルに明示的に一致するglobパターン、または`project/subdir/pom.xml`のような完全一致を渡します。
`project`や`project/subdir`など、パターンの親ディレクトリを渡しても、この場合、ビルドファイルはパターンによって明示的に一致_しない_ため、ディレクトリはビルドから除外_されません_。
1. <a id="search-max-depth-description"></a>[SAST CI/CDテンプレート](https://gitlab.com/gitlab-org/gitlab/blob/v17.4.1-ee/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml)は、リポジトリを検索して使用されているプログラミング言語を検出し、一致するアナライザーを選択します。次に、各アナライザーはコードベースを検索し、スキャンする必要がある特定のファイルまたはディレクトリを見つけます。アナライザーの検索フェーズが対象とすべきディレクトリレベルの数を指定するには、`SEARCH_MAX_DEPTH`の値を設定します。
#### アナライザーの設定
一部のアナライザーは、CI/CD変数を使用してカスタマイズできます。
| CI/CD変数 | アナライザー | 説明 |
|-----------------------------|------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `GITLAB_ADVANCED_SAST_ENABLED` | GitLab高度なSAST | `true`に設定して、[GitLab高度なSAST](gitlab_advanced_sast.md)スキャンを有効にします（GitLab Ultimateでのみ使用可能）。デフォルト: `false`。 |
| `SCAN_KUBERNETES_MANIFESTS` | Kubesec | `"true"`に設定して、Kubernetes manifestをスキャンします。 |
| `KUBESEC_HELM_CHARTS_PATH` | Kubesec | `helm`が`kubesec`がスキャンするKubernetes manifestを生成するために使用するHelmチャートへのオプションのパス。依存関係が定義されている場合、必要な依存関係をフェッチするために、`helm dependency build`を`before_script`で実行する必要があります。 |
| `KUBESEC_HELM_OPTIONS` | Kubesec | `helm`実行可能ファイルの追加引数。 |
| `COMPILE` | SpotBugs | プロジェクトのコンパイルと依存関係のフェッチを無効にするには、`false`に設定します。 |
| `ANT_HOME` | SpotBugs | `ANT_HOME`変数。 |
| `ANT_PATH` | SpotBugs | `ant`実行可能ファイルへのパス。 |
| `GRADLE_PATH` | SpotBugs | `gradle`実行可能ファイルへのパス。 |
| `JAVA_OPTS` | SpotBugs | `java`実行可能ファイルの追加引数。 |
| `JAVA_PATH` | SpotBugs | `java`実行可能ファイルへのパス。 |
| `SAST_JAVA_VERSION` | SpotBugs | 使用するJavaのバージョン。[GitLab 15.0以降](https://gitlab.com/gitlab-org/gitlab/-/issues/352549)、サポートされているバージョンは`11`と`17`（デフォルト）です。GitLab 15.0より前、サポートされているバージョンは、`8`（デフォルト）と`11`です。 |
| `MAVEN_CLI_OPTS` | SpotBugs | `mvn`または`mvnw`実行可能ファイルの追加引数。 |
| `MAVEN_PATH` | SpotBugs | `mvn`実行可能ファイルへのパス。 |
| `MAVEN_REPO_PATH` | SpotBugs | Mavenローカルリポジトリへのパス（`maven.repo.local`プロパティのショートカット）。 |
| `SBT_PATH` | SpotBugs | `sbt`実行可能ファイルへのパス。 |
| `FAIL_NEVER` | SpotBugs | コンパイルの失敗を無視するには、`1`に設定します。 |
| `SAST_SEMGREP_METRICS` | Semgrep | 匿名化されたスキャンメトリクスを[r2c](https://semgrep.dev)に送信しないようにするには、`"false"`に設定します。デフォルト: `true`。 |
| `SAST_SCANNER_ALLOWED_CLI_OPTS` | Semgrep | スキャン操作の実行時に、基盤となるセキュリティスキャナーに渡されるコマンドラインインターフェース（CLI）オプション（値、またはフラグを持つ引数）。限られた[オプション](#security-scanner-configuration)セットのみが受け入れられます。CLIオプションとその値は、空白または等号（`=`）文字を使用して区切ります。例: `name1 value1`または`name1=value1`。複数のオプションは空白で区切る必要があります。例: `name1 value1 name2 value2`。GitLab 15.3で[導入](https://gitlab.com/gitlab-org/gitlab/-/issues/368565)されました。 |
| `SAST_RULESET_GIT_REFERENCE` | すべて | カスタムルールセット設定へのパスを定義します。プロジェクトに`.gitlab/sast-ruleset.toml`ファイルがコミットされている場合、そのローカル設定が優先され、`SAST_RULESET_GIT_REFERENCE`のファイルは使用されません。この変数は、Ultimateプランでのみ使用できます。|
| `SECURE_ENABLE_LOCAL_CONFIGURATION` | すべて | カスタムルールセット設定を使用するオプションを有効にします。`SECURE_ENABLE_LOCAL_CONFIGURATION`が`false`に設定されている場合、`.gitlab/sast-ruleset.toml`にあるプロジェクトのカスタムルールセット設定ファイルは無視され、`SAST_RULESET_GIT_REFERENCE`のファイルまたはデフォルト設定が優先されます。 |
#### セキュリティスキャナーの設定
SASTアナライザーは、内部的にOSSセキュリティスキャナーを使用して分析を実行します。セキュリティスキャナーに推奨される設定を行っているため、調整について心配する必要はありません。ただし、まれですが、デフォルトのスキャナー設定が要件に適合しない場合があります。
スキャナーの動作をある程度カスタマイズできるようにするには、基になるスキャナーに制限付きのフラグセットを追加します。`SAST_SCANNER_ALLOWED_CLI_OPTS` CI/CD変数でフラグを指定します。これらのフラグは、スキャナーのCLIオプションに追加されます。
<table class="sast-table">
<thead>
<tr>
<th>アナライザー</th>
<th>CLIオプション</th>
<th>説明</th>
</tr>
</thead>
<tbody>
<tr>
<td rowspan="1">
GitLab高度なSAST
</td>
<td>
<code>--multi-core</code>
</td>
<td>
マルチコアスキャンはデフォルトで有効になっており、コンテナ情報に基づいて利用可能なCPUコアを自動的に検出して利用します。セルフホストRunnerでは、コアの最大数は4に制限されています。<code>--multi-core</code>を特定の値に明示的に設定することで、自動コア検出をオーバーライドできます。マルチコア実行では、シングルコア実行と比較したとき、必要なメモリが比例的に増加します。マルチコアスキャンを無効にするには、環境変数<code>DISABLE_MULTI_CORE</code>を設定します。利用可能なコアまたはメモリリソースを超えると、リソースの競合が発生し、パフォーマンスが最適でなくなる可能性があることに注意してください。
</td>
</tr>
<tr>
<td rowspan="3">
<a href="https://gitlab.com/gitlab-org/security-products/analyzers/semgrep">Semgrep</a>
</td>
<td>
<code>--max-memory</code>
</td>
<td>
1つのファイルでルールを実行する際に使用する、最大システムメモリ（MB単位）を設定します。
</td>
</tr>
<tr>
<td>
<code>--max-target-bytes</code>
</td>
<td>
<p>
スキャン対象ファイルの最大サイズ。これを超えるサイズのインプットプログラムは無視されます。このフィルターを無効にするには、<code>0</code>または負の値を設定します。バイト数は、測定単位の有無にかかわらず指定できます。例:<code>12.5kb</code>、<code>1.5MB</code>、または<code>123</code>。デフォルトは<code>1000000</code>バイトです。
</p>
<p>
<b>注: </b>このフラグはデフォルト値に設定したままにする必要があります。また、このフラグを変更して縮小されたJavaScriptをスキャンすることは避けてください。うまく動作しない可能性があります。バイナリファイルはスキャンされないため、<code>DLL</code>、<code>JAR</code>、またはその他のバイナリファイルのスキャンも避けてください。
</p>
</td>
</tr>
<tr>
<td>
<code>--timeout</code>
</td>
<td>
1つのファイルに対してルールを実行するために費やす最大時間（秒）。時間制限を設けない場合は、<code>0</code>に設定します。タイムアウト値は整数にする必要があります。例: <code>10</code>または<code>15</code>。デフォルトは<code>5</code>です。
</td>
</tr>
<tr>
<td>
<a href="https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs">SpotBugs</a>
</td>
<td>
<code>-effort</code>
</td>
<td>
分析の労力レベルを設定します。有効な値は、精度とより多くの脆弱性を検出する能力の昇順で、<code>min</code>、<code>less</code>、<code>more</code>、<code>max</code>となります。デフォルト値は<code>max</code>に設定されています。プロジェクトのサイズによっては、スキャンを完了するためにより多くのメモリと時間が必要になる場合があります。メモリやパフォーマンスの問題が発生した場合は、分析の労力レベルの値を低くできます。例: <code>-effort less</code>。
</td>
</tr>
</tbody>
</table>
#### カスタムCI/CD変数
前述のSAST設定CI/CD変数だけでなく、[SASTベンダーテンプレート](#configuration)を使用している場合、すべての[カスタム変数](../../../ci/variables/_index.md#define-a-cicd-variable-in-the-ui)が基盤となるSASTアナライザーイメージに伝播されます。
### 分析からコードを除外する
脆弱性の分析から除外するコードの個々の行またはブロックをマークできます。すべての脆弱性を脆弱性管理で管理するか、検出結果ごとにコメント注釈を追加する方法を使用する前に、`SAST_EXCLUDED_PATHS`を使用してスキャンされたファイルパスを調整する必要があります。
Semgrepベースのアナライザーを使用する場合、次のオプションも使用できます。
- コード行を無視する - 行の末尾に`// nosemgrep:`コメントを追加します（プレフィックスは開発言語に従います）。
Javaの例:
```java
vuln_func(); // nosemgrep
```
Pythonの例:
```python
vuln_func(); # nosemgrep
```
- 特定のルールに対してコード行を無視する - 行の末尾に`// nosemgrep: RULE_ID`コメントを追加します（プレフィックスは開発言語に従います）。
- ファイルまたはディレクトリを無視する - リポジトリのルートディレクトリまたはプロジェクトの作業ディレクトリに`.semgrepignore`ファイルを作成し、そこにファイルとフォルダーのパターンを追加します。
詳細については、[Semgrepのドキュメント](https://semgrep.dev/docs/ignoring-files-folders-code)を参照してください。
## オフライン環境でSASTを実行する
{{< details >}}
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab Self-Managed
{{< /details >}}
インターネット経由での外部リソースへのアクセスが制限されている環境やアクセスが断続的な環境のインスタンスでは、SASTジョブを正常に実行するためにいくつかの調整が必要です。詳細については、「[オフライン環境](../offline_deployments/_index.md)」を参照してください。
### オフラインSASTの要件
オフライン環境でSASTを使用するには、以下が必要です。
- [`docker`または`kubernetes`executor](#requirements)を備えたGitLab Runner
- ローカルで利用可能なSAST[アナライザー](https://gitlab.com/gitlab-org/security-products/analyzers)イメージのコピーを含むDockerコンテナレジストリ
- パッケージの証明書チェックの設定（オプション）
GitLab Runnerでは、[デフォルトで`pull_policy`が`always`](https://docs.gitlab.com/runner/executors/docker.html#using-the-always-pull-policy)になっています。つまり、ローカルコピーが利用可能な場合でも、RunnerはGitLabコンテナレジストリからDockerイメージをプルしようとします。ローカルで利用可能なDockerイメージのみを使用する場合は、オフライン環境でGitLab Runnerの[`pull_policy`を`if-not-present`に設定できます](https://docs.gitlab.com/runner/executors/docker.html#using-the-if-not-present-pull-policy)。ただし、オフライン環境でない場合は、プルポリシーの設定を`always`のままにしておくことをおすすめします。これにより、CI/CDパイプラインで更新されたスキャナーを使用できるようになります。
### Dockerレジストリ内でGitLab SASTアナライザーイメージを利用できるようにする
すべての[サポートされている言語とフレームワーク](#supported-languages-and-frameworks)に対応したSASTの場合、`registry.gitlab.com`から次のデフォルトSASTアナライザーイメージを[ローカルのDockerコンテナレジストリ](../../packages/container_registry/_index.md)にインポートします。
```plaintext
registry.gitlab.com/security-products/gitlab-advanced-sast:1
registry.gitlab.com/security-products/kubesec:5
registry.gitlab.com/security-products/pmd-apex:5
registry.gitlab.com/security-products/semgrep:5
registry.gitlab.com/security-products/sobelow:5
registry.gitlab.com/security-products/spotbugs:5
```
DockerイメージをローカルのオフラインDockerレジストリにインポートするプロセスは、**ネットワークのセキュリティポリシー**によって異なります。IT部門に相談して、外部リソースをインポートまたは一時的にアクセスするための承認済みプロセスを確認してください。これらのスキャナーは新しい定義で[定期的に更新](../_index.md#vulnerability-scanner-maintenance)されています。また、自分で随時更新できる場合もあります。
Dockerイメージをファイルとして保存および転送する方法の詳細については、[`docker save`](https://docs.docker.com/reference/cli/docker/image/save/)、[`docker load`](https://docs.docker.com/reference/cli/docker/image/load/)、[`docker export`](https://docs.docker.com/reference/cli/docker/container/export/)、[`docker import`](https://docs.docker.com/reference/cli/docker/image/import/)に関するDockerドキュメントを参照してください。
#### カスタム公開認証局（CA）のサポートが必要な場合
次のバージョンで、カスタム公開認証局（CA）のサポートが導入されました。
| アナライザー | バージョン |
| -------- | ------- |
| `kubesec` | [v2.1.0](https://gitlab.com/gitlab-org/security-products/analyzers/kubesec/-/releases/v2.1.0) |
| `pmd-apex` | [v2.1.0](https://gitlab.com/gitlab-org/security-products/analyzers/pmd-apex/-/releases/v2.1.0) |
| `semgrep` | [v0.0.1](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/releases/v0.0.1) |
| `sobelow` | [v2.2.0](https://gitlab.com/gitlab-org/security-products/analyzers/sobelow/-/releases/v2.2.0) |
| `spotbugs` | [v2.7.1](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs/-/releases/v2.7.1) |
### ローカルのSASTアナライザーを使用するようにSAST CI/CD変数を設定する
次の設定を`.gitlab-ci.yml`ファイルに追加します。ローカルのDockerコンテナレジストリを参照するように、`SECURE_ANALYZERS_PREFIX`を置き換える必要があります。
```yaml
include:
- template: Jobs/SAST.gitlab-ci.yml
variables:
SECURE_ANALYZERS_PREFIX: "localhost:5000/analyzers"
```
SASTジョブは、インターネットアクセスを必要とせずに、SASTアナライザーのローカルコピーを使用してコードをスキャンし、セキュリティレポートを生成するようになりました。
### パッケージの証明書チェックを設定する
SASTジョブがパッケージマネージャーを呼び出す場合は、その証明書の検証を設定する必要があります。オフライン環境では、外部ソースを使用して証明書を検証することはできません。自己署名証明書を使用するか、証明書の検証を無効にします。手順については、パッケージマネージャーのドキュメントを参照してください。
## SELinuxでSASTを実行する
デフォルトで、SASTアナライザーは、SELinuxでホストされているGitLabインスタンスでサポートされています。[オーバーライドされたSASTジョブ](#overriding-sast-jobs)に`before_script`を追加すると、SELinuxでホストされているRunnerの権限が制限されているため、動作しない場合があります。

565
doc-locale/ja-jp/user/gitlab_com/_index.md Normal file
View File

@ -0,0 +1,565 @@
---
stage: none
group: unassigned
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: GitLab.com の設定
---
{{< details >}}
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab.com
{{< /details >}}
このページでは、[GitLab SaaS](https://about.gitlab.com/pricing/)をご利用のお客様が利用できる、GitLab.comで使用されている設定について説明します。
これらの設定の一部については、GitLab.com の[インスタンス設定ページ](https://gitlab.com/help/instance_configuration)を参照してください。
## アカウントと制限の設定
GitLab.comでは、次のアカウント制限が有効になっています。設定がリストにない場合、デフォルト値は[Self-Managedインスタンスと同じ](../../administration/settings/account_and_limit_settings.md)です。
| 設定 | GitLab.comのデフォルト |
|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:-------------------|
| [LFSを含むリポジトリサイズ](../../administration/settings/account_and_limit_settings.md#repository-size-limit) | 10 GB |
| [最大インポートサイズ](../project/settings/import_export.md#import-a-project-and-its-data) | 5 GiB |
| [最大エクスポートサイズ](../project/settings/import_export.md#export-a-project-and-its-data) | 40 GiB |
| [外部オブジェクトストレージからのインポートの最大リモートファイルサイズ](../../administration/settings/import_and_export_settings.md#maximum-remote-file-size-for-imports) | 10 GiB |
| [ダイレクト転送によるソースGitLabインスタンスからのインポート時の最大ダウンロードファイルサイズ](../../administration/settings/import_and_export_settings.md#maximum-download-file-size-for-imports-by-direct-transfer) | 5 GiB |
| 添付ファイルの最大サイズ | 100 MiB |
| [インポートされたアーカイブの最大解凍ファイルサイズ](../../administration/settings/import_and_export_settings.md#maximum-decompressed-file-size-for-imported-archives) | 25 GiB |
| [最大プッシュサイズ](../../administration/settings/account_and_limit_settings.md#max-push-size) | 5 GiB |
リポジトリのサイズ制限に近い場合、または制限を超えている場合は、次のいずれかを実行できます。
- [Gitでリポジトリのサイズを縮小](../project/repository/repository_size.md#methods-to-reduce-repository-size)する。
- [ストレージを追加購入](https://about.gitlab.com/pricing/licensing-faq/#can-i-buy-more-storage)する。
{{< alert type="note" >}}
`git push`とGitLabプロジェクトのインポートは、Cloudflareを介したリクエストごとに5 GiBに制限されています。ファイルアップロード以外のインポートは、この制限の影響を受けません。リポジトリの制限は、パブリックプロジェクトとプライベートプロジェクトの両方に適用されます。
{{< /alert >}}
## バックアップ
[バックアップ戦略を参照してください](https://handbook.gitlab.com/handbook/engineering/infrastructure/production/#backups)。
GitLab.comでプロジェクト全体をバックアップするには、次のいずれかの方法でエクスポートできます。
- [UI経由](../project/settings/import_export.md)。
- [API経由](../../api/project_import_export.md#schedule-an-export)。APIを使用して、エクスポートをAmazon S3などのストレージプラットフォームにプログラムでアップロードすることもできます。
エクスポートでは、プロジェクトのエクスポートに[何が含まれ、何が含まれない](../project/settings/import_export.md#project-items-that-are-exported)かに注意してください。
GitLabはGit上にビルドされているため、別のコンピューターにプロジェクトのリポジトリのクローンを作成することで、リポジトリのみをバックアップできます。同様に、プロジェクトのWikiのクローンを作成してバックアップできます。[2020年8月22日以降にアップロードされた](../project/wiki/_index.md#create-a-new-wiki-page)ファイルはすべて、クローン作成時に含まれます。
## CI/CD
以下は、[GitLab CI/CD](../../ci/_index.md)に関する現在の設定です。ここに記載されていない設定または機能制限はすべて、関連ドキュメントに記載されているデフォルトを使用しています。
| 設定 | GitLab.com | デフォルト（GitLab Self-Managed） |
|----------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------|------------------------|
| アーティファクトの最大サイズ（圧縮） | 1 GB | [アーティファクトの最大サイズ](../../administration/settings/continuous_integration.md#maximum-artifacts-size)を参照してください。 |
| アーティファクトの[有効期限](../../ci/yaml/_index.md#artifactsexpire_in) | 特に指定がない限り30日間 | [アーティファクトのデフォルトの有効期限](../../administration/settings/continuous_integration.md#default-artifacts-expiration)を参照してください。2020年6月22日より前に作成されたアーティファクトには、有効期限はありません。 |
| スケジュールされたパイプラインCron | `*/5 * * * *` | [パイプラインスケジュールの詳細設定](../../administration/cicd/_index.md#change-maximum-scheduled-pipeline-frequency)を参照してください。 |
| アクティブなパイプラインの最大ジョブ数 | Freeプランの場合は`500`、すべてのトライアルプランの場合は`1000`、Premiumの場合は`20000`、Ultimateの場合は`100000` | 「[アクティブなパイプライン内のジョブ数](../../administration/instance_limits.md#number-of-jobs-in-active-pipelines)」を参照してください。 |
| プロジェクトに対するCI/CDサブスクリプションの最大数 | `2` | 「[プロジェクトに対するCI/CDサブスクリプションの数](../../administration/instance_limits.md#number-of-cicd-subscriptions-to-a-project)」を参照してください。 |
| プロジェクト内のパイプライントリガーの最大数 | `25000` | 「[パイプライントリガー数を制限する](../../administration/instance_limits.md#limit-the-number-of-pipeline-triggers)」を参照してください。 |
| プロジェクト内のパイプラインスケジュールの最大数 | Freeプランの場合は`10`、すべての有料プランの場合は`50` | 「[パイプラインスケジュール数](../../administration/instance_limits.md#number-of-pipeline-schedules)」を参照してください。 |
| 各スケジュールに対するパイプラインの最大数 | Freeプランの場合は`24`、すべての有料プランの場合は`288` | 「[1日にパイプラインスケジュールによって作成できるパイプラインの数を制限する](../../administration/instance_limits.md#limit-the-number-of-pipelines-created-by-a-pipeline-schedule-each-day)」を参照してください。 |
| 各セキュリティポリシープロジェクトに対して定義されたスケジュールルールの最大数 | すべての有料プランで無制限 | [セキュリティポリシープロジェクトに対して定義されたスケジュールルールの数](../../administration/instance_limits.md#limit-the-number-of-schedule-rules-defined-for-security-policy-project)を参照してください。 |
| スケジュールされたジョブのアーカイブ | 3か月 | なし。2020年6月22日より前に作成されたジョブは、2020年9月22日以降にアーカイブされました。 |
| 各[単体試験レポート](../../ci/testing/unit_test_reports.md)の最大テストケース数 | `500000` | 無制限。 |
| 登録済みRunnerの最大数 | Freeプラン: 各グループに対して`50`、各プロジェクトに対して`50`<br/>すべての有料プラン: 各グループに対して`1000`、各プロジェクトに対して`1000` | 「[スコープごとの登録Runner数](../../administration/instance_limits.md#number-of-registered-runners-for-each-scope)」を参照してください。 |
| dotenv変数の制限 | Freeプラン: `50`<br>Premiumプラン: `100`<br>Ultimateプラン: `150` | 「[dotenv変数を制限する](../../administration/instance_limits.md#limit-dotenv-variables)」を参照してください。 |
| ダウンストリームパイプラインの最大トリガーレート（特定のプロジェクト、ユーザー、コミットの場合） | 毎分`350` | [ダウンストリームパイプラインの最大トリガーレート](../../administration/settings/continuous_integration.md#maximum-downstream-pipeline-trigger-rate)を参照してください。 |
## コンテナレジストリ
| 設定 | GitLab.com | デフォルト（Self-Managed） |
|:---------------------------------------|:---------------------------------|------------------------|
| ドメイン名 | `registry.gitlab.com` | |
| IPアドレス | `35.227.35.254` | |
| CDNドメイン名 | `cdn.registry.gitlab-static.net` | |
| CDN IPアドレス | `34.149.22.116` | |
| 認証トークンの有効期間（分） | `15` | [コンテナレジストリトークンの有効期間の延長](../../administration/packages/container_registry.md#increase-token-duration)を参照してください。 |
GitLabコンテナレジストリを使用するには、Dockerクライアントが以下にアクセスできる必要があります。
- 認証用のレジストリエンドポイントとGitLab.com
- イメージをダウンロードするためのGoogle Cloud StorageまたはGoogle Cloud Content Delivery Network
GitLab.comはCloudflareによって保護されています。GitLab.comへの受信接続については、CloudflareのCIDRブロック（[IPv4](https://www.cloudflare.com/ips-v4/)および[IPv6](https://www.cloudflare.com/ips-v6/)）を許可する必要がある場合があります。
## メール
メール設定、IPアドレス、エイリアス
### 確認設定
GitLab.comでは、次のメール確認設定が使用されます。
- [`email_confirmation_setting`](../../administration/settings/sign_up_restrictions.md#confirm-user-email)は**Hard**に設定されています。
- [`unconfirmed_users_delete_after_days`](../../administration/moderate_users.md#automatically-delete-unconfirmed-users)は3日に設定されています。
### IPアドレス
GitLab.comは、`mg.gitlab.com`ドメインからメールを送信するために[Mailgun](https://www.mailgun.com/)を使用しており、独自の専用IPアドレスを持っています。
- `23.253.183.236`
- `69.72.35.190`
- `69.72.44.107`
- `159.135.226.146`
- `161.38.202.219`
- `192.237.158.143`
- `192.237.159.239`
- `198.61.254.136`
- `198.61.254.160`
- `209.61.151.122`
`mg.gitlab.com`のIPアドレスは、いつでも変更される可能性があります。
### サービスデスクのエイリアス
GitLab.comには、メールアドレス`contact-project+%{key}@incoming.gitlab.com`を持つサービスデスク用に設定されたメールボックスがあります。このメールボックスを使用するには、プロジェクト設定で[カスタムサフィックス](../project/service_desk/configure.md#configure-a-suffix-for-service-desk-alias-email)を設定します。
## GitLab.comにおけるGitaly RPCの並行処理の制限
リポジトリごとのGitaly RPCの並行処理およびキューイングの制限は、`git clone`などのさまざまな種類のGit操作に対して設定されています。これらの制限を超えると、`fatal: remote error: GitLab is currently unable to handle this request due to load`メッセージがクライアントに返されます。
管理者向けドキュメントについては、「[RPCの並行処理を制限する](../../administration/gitaly/concurrency_limiting.md#limit-rpc-concurrency)」を参照してください。
## GitLab Pages
[GitLab Pages](../project/pages/_index.md)の一部の設定は、[Self-Managedインスタンスのデフォルト](../../administration/pages/_index.md)とは異なります。
| 設定 | GitLab.com |
|:--------------------------------------------------|:-----------------------|
| ドメイン名 | `gitlab.io` |
| IPアドレス | `35.185.44.232` |
| カスタムドメインのサポート | {{< icon name="check-circle" >}} 可 |
| TLS証明書のサポート | {{< icon name="check-circle" >}} 可 |
| サイトの最大サイズ | 1 GB |
| GitLab Pages Webサイトごとのカスタムドメインの数 | 150 |
Pagesサイトの最大サイズは、[GitLab CI/CD](#cicd)の一部であるアーティファクトの最大サイズによって異なります。
[レート制限](#rate-limits-on-gitlabcom)はGitLab Pagesにも存在します。
## 大規模なGitLab.com
GitLab.comでは、GitLab EnterpriseエディションのLinuxパッケージのインストールに加えて、次のアプリケーションと設定を使用してスケールを実現しています。すべての設定は、[Kubernetesの設定](https://gitlab.com/gitlab-com/gl-infra/k8s-workloads/gitlab-com)または[Chef Cookbook](https://gitlab.com/gitlab-cookbooks)として公開されています。
### Consul
サービスディスカバリ:
- [`gitlab-cookbooks` / `gitlab_consul` · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab_consul)
### Elasticクラスター
ElasticsearchとKibanaをモニタリングソリューションの一部として使用しています。
- [`gitlab-cookbooks` / `gitlab-elk` · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-elk)
- [`gitlab-cookbooks` / `gitlab_elasticsearch` · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab_elasticsearch)
### Fluentd
Fluentdを使用してGitLabログを統合しています。
- [`gitlab-cookbooks` / `gitlab_fluentd` · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab_fluentd)
### Grafana
モニタリングデータの視覚化:
- [`gitlab-cookbooks` / `gitlab-grafana` · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-grafana)
### HAProxy
高性能TCP/HTTPロードバランサー:
- [`gitlab-cookbooks` / `gitlab-haproxy` · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-haproxy)
### Prometheus
Prometheusはモニタリングスタックを完了します。
- [`gitlab-cookbooks` / `gitlab-prometheus` · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-prometheus)
### Sentry
オープンソースのエラートラッキング:
- [`gitlab-cookbooks` / `gitlab-sentry` · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-sentry)
## GitLabでホストされるRunner
GitLabでホストされるRunnerを使用して、GitLab.comおよびGitLab DedicatedでCI/CDジョブを実行し、さまざまな環境でアプリケーションをシームレスにビルド、テスト、デプロイできます。
詳細については、[GitLabでホストされるRunner](../../ci/runners/_index.md)を参照してください。
## ホスト名リスト
ローカルHTTP（S）プロキシまたはエンドユーザーのコンピューターを管理するその他のWebブロックソフトウェアで許可リストを設定する際は、次のホスト名を追加してください。GitLab.comのPagesは、次のホスト名からコンテンツを読み込みます。
- `gitlab.com`
- `*.gitlab.com`
- `*.gitlab-static.net`
- `*.gitlab.io`
- `*.gitlab.net`
`docs.gitlab.com`および`about.gitlab.com`経由で提供されるドキュメントおよび企業ページも、一般的なパブリックCDNホスト名から特定のページコンテンツを直接読み込みます。
## インポート
GitLabへのデータのインポートに関する設定。
### デフォルトのインポートソース
デフォルトで使用できる[インポートソース](../project/import/_index.md#supported-import-sources)は、使用するGitLabによって異なります。
- GitLab.com: デフォルトでは、使用可能なすべてのインポートソースが有効になっています。
- GitLab Self-Managed: デフォルトでは、インポートソースは有効になっていないため、[有効にする](../../administration/settings/import_and_export_settings.md#configure-allowed-import-sources)必要があります。
### インポートプレースホルダーユーザーの制限
GitLab.comでのインポート時に作成される[プレースホルダーユーザー](../project/import/_index.md#placeholder-users)の数は、トップレベルのネームスペースごとに制限されています。制限は、プランとシート数によって異なります。詳細については、[GitLab.comのプレースホルダーユーザー制限の表](../project/import/_index.md#placeholder-user-limits)を参照してください。
## IP範囲
GitLab.comは、Web/APIフリートからのトラフィックにIP範囲`34.74.90.64/28`および`34.74.226.0/24`を使用します。この範囲全体がGitLabにのみ割り当てられています。Webhookまたはリポジトリのミラーリングからの接続はこれらのIPから送信されることが予想されるため、許可してください。
GitLab.comはCloudflareによって保護されています。GitLab.comへの受信接続の場合、CloudflareのCIDRブロック（[IPv4](https://www.cloudflare.com/ips-v4/)および[IPv6](https://www.cloudflare.com/ips-v6/)）を許可する必要がある場合があります。
CI/CD Runnerからの発信接続については、静的IPアドレスを提供していません。ほとんどのGitLab.comインスタンスrunnerは、`us-east1`のGoogle Cloudにデプロイされますが、_Linux GPU対応_および_Linux Arm64_は`us-central1`でホストされます。IPベースのファイアウォールを設定するには、[GCPのIPアドレス範囲またはCIDRブロック](https://cloud.google.com/compute/docs/faq#find_ip_range)を調べてください。macOS Runnerは、`us-east-1`リージョンのAWSでホストされ、RunnerマネージャーはGoogle Cloudでホストされます。IPベースのファイアウォールを設定するには、[AWS IPアドレス範囲](https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-ranges.html)と[Google Cloud](https://cloud.google.com/compute/docs/faq#find_ip_range)の両方を許可する必要があります。
## GitLab.comのログ
ログの解析には[Fluentd](https://gitlab.com/gitlab-com/runbooks/tree/master/logging/doc#fluentd)を使用します。Fluentdはログを[Stackdriver Logging](https://gitlab.com/gitlab-com/runbooks/tree/master/logging/doc#stackdriver)と[Cloud Pub/Sub](https://gitlab.com/gitlab-com/runbooks/tree/master/logging/doc#cloud-pubsub)に送信します。Stackdriverは、ログをGoogle Cold Storage（GCS）に長期保存するために使用されます。Cloud Pub/Subは、[`pubsubbeat`](https://gitlab.com/gitlab-com/runbooks/tree/master/logging/doc#pubsubbeat-vms)を使用してログを[Elasticクラスター](https://gitlab.com/gitlab-com/runbooks/tree/master/logging/doc#elastic)に転送するために使用されます。
手順書では、次の詳細情報を確認できます。
- [ログに記録している内容の詳細なリスト](https://gitlab.com/gitlab-com/runbooks/-/tree/master/docs/logging#what-are-we-logging)
- [現在のログ保持ポリシー](https://gitlab.com/gitlab-com/runbooks/-/tree/master/docs/logging#retention)
- [ログインフラストラクチャの図](https://gitlab.com/gitlab-com/runbooks/-/tree/master/docs/logging#logging-infrastructure-overview)
### ジョブログ
デフォルトでは、GitLabはジョブログに有効期限を設定しません。ジョブログは無期限に保持され、期限切れになるようにGitLab.comで設定することはできません。[Jobs APIを使用して手動でジョブログを消去](../../api/jobs.md#erase-a-job)するか、[パイプラインを削除](../../ci/pipelines/_index.md#delete-a-pipeline)することができます。
## レビュアーと担当者の最大数
{{< history >}}
- GitLab 15.6で、担当者の最大数が[導入](https://gitlab.com/gitlab-org/gitlab/-/issues/368936)されました。
- GitLab 15.9で、レビュアーの最大数が[導入](https://gitlab.com/gitlab-org/gitlab/-/issues/366485)されました。
{{< /history >}}
マージリクエストでは、次の最大数が適用されます。
- 担当者の最大数: 200
- レビュアーの最大数: 200
## マージリクエストの制限
{{< history >}}
- GitLab 17.10で、`merge_requests_diffs_limit`という名前の[フラグとともに](../../administration/feature_flags.md)[導入](https://gitlab.com/gitlab-org/gitlab/-/issues/521970)されました。デフォルトでは無効になっています。
- GitLab 17.10の[GitLab.comで有効になりました](https://gitlab.com/gitlab-org/gitlab/-/issues/521970)。
{{< /history >}}
{{< alert type="flag" >}}
この機能の利用可否は、機能フラグによって制御されます。詳細については、履歴を参照してください。
{{< /alert >}}
GitLabでは、各マージリクエストを1,000件の[差分バージョン](../project/merge_requests/versions.md)に制限しています。この制限に達したマージリクエストは、それ以上更新できません。代わりに、影響を受けたマージリクエストをクローズし、新しいマージリクエストを作成してください。
## パスワードの要件
GitLab.comでは、新規アカウントおよびパスワード変更時のパスワードについて、次の要件があります。
- 最小文字数8文字
- 最大文字数128文字
- すべての文字が使用可能（例: `~`、`!`、`@`、`#`、`$`、`%`、`^`、`&`、`*`、`()`、`[]`、`_`、`+`、`=`、`-`）
## プロジェクトとグループの削除
プロジェクトとグループの削除に関連する設定
### グループの遅延削除
{{< details >}}
- プラン: Premium、Ultimate
- 提供形態: GitLab.com
{{< /details >}}
2023年5月8日以降、デフォルトですべてのグループで遅延削除が有効になっています。
グループは7日間の遅延後、完全に削除されます。
Freeプランをご利用の場合、グループはすぐに削除され、復元できません。
[削除対象としてマークされたグループを表示および復元](../group/_index.md#restore-a-group)できます。
### プロジェクトの遅延削除
{{< details >}}
- プラン: Premium、Ultimate
- 提供形態: GitLab.com
{{< /details >}}
2023年5月8日以降、デフォルトですべてのグループでプロジェクトの遅延削除が有効になっています。
プロジェクトは7日間の遅延後、完全に削除されます。
Freeプランをご利用の場合、プロジェクトはすぐに削除され、復元できません。
[削除対象としてマークされたプロジェクトを表示および復元](../project/working_with_projects.md#restore-a-project)できます。
### 無効なプロジェクトの削除
GitLab.comで、[無効なプロジェクトの削除](../../administration/inactive_project_deletion.md)は無効になっています。
## パッケージレジストリの制限
[GitLabパッケージレジストリ](../packages/package_registry/_index.md)にアップロードされるパッケージの[最大ファイルサイズ](../../administration/instance_limits.md#file-size-limits)は、形式によって異なります。
| パッケージの種類 | GitLab.com |
|------------------------|------------------------------------|
| Conan | 5 GB |
| 汎用 | 5 GB |
| Helm | 5 MB |
| Maven | 5 GB |
| NPM | 5 GB |
| NuGet | 5 GB |
| PyPi | 5 GB |
| Terraform | 1 GB |
| 機械学習モデル | 10 GB（アップロードは5 GBに制限） |
## Puma
GitLab.comでは、[Pumaリクエストタイムアウト](../../administration/operations/puma.md#change-the-worker-timeout)のデフォルトである60秒を使用しています。
## GitLab.comのレート制限
{{< alert type="note" >}}
管理者ドキュメントについては、「[レート制限](../../security/rate_limits.md)」を参照してください。
{{< /alert >}}
リクエストがレート制限されている場合、GitLab は`429`ステータスコードで応答します。クライアントは、リクエストを再度試行する前に待機する必要があります。また、「[レート制限の応答](#rate-limiting-responses)」で詳しく説明されているこの応答には、情報ヘッダーもあります。
次の表は、GitLab.comのレート制限について説明しています。
| レート制限 | 設定 |
|:-----------------------------------------------------------------|:------------------------------|
| IPアドレスの保護されたパス | 毎分10件のリクエスト |
| プロジェクト、コミット、またはファイルパスのrawエンドポイントトラフィック | 毎分300件のリクエスト |
| IPアドレスからの認証されていないトラフィック | 毎分500件のリクエスト |
| ユーザーの認証済みAPIトラフィック | 毎分2,000件のリクエスト |
| ユーザーの認証済み非API HTTPトラフィック | 毎分1,000件のリクエスト |
| IPアドレスからのすべてのトラフィック | 毎分2,000件のリクエスト |
| イシューの作成 | 毎分200件のリクエスト |
| イシューおよびマージリクエストに関するノートの作成 | 毎分60件のリクエスト |
| IPアドレスの高度な検索、プロジェクト検索、またはグループ検索のAPI | 毎分10件のリクエスト |
| IPアドレスのGitLab Pagesリクエスト | 50秒ごとに1,000件のリクエスト |
| GitLab PagesドメインのGitLab Pagesリクエスト | 10秒ごとに5,000件のリクエスト |
| IPアドレスのGitLab Pages TLS接続 | 50秒ごとに1,000件のリクエスト |
| GitLab PagesドメインのGitLab Pages TLS接続 | 10秒ごとに400件のリクエスト |
| プロジェクト、ユーザー、またはコミットのパイプライン作成リクエスト | 毎分25件のリクエスト |
| プロジェクトのアラートインテグレーションエンドポイントのリクエスト | 1時間あたり3,600件のリクエスト |
| GitLab Duo `aiAction`のリクエスト | 8時間ごとに160件のリクエスト |
| [プルミラーリング](../project/repository/mirror/pull.md)の間隔 | 5分 |
| ユーザーから`/api/v4/users/:id`へのAPIリクエスト | 10分ごとに300件のリクエスト |
| IPアドレスのGitLabパッケージクラウドのリクエスト（GitLab 16.11で[導入](https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/issues/24083)） | 毎分3,000件のリクエスト |
| GitLabリポジトリファイル | 毎分500件のリクエスト |
| ユーザーフォロワーのリクエスト（`/api/v4/users/:id/followers`） | 毎分100件のリクエスト |
| ユーザーのフォローリクエスト（`/api/v4/users/:id/following`） | 毎分100件のリクエスト |
| ユーザーステータスのリクエスト（`/api/v4/users/:user_id/status`） | 毎分240件のリクエスト |
| ユーザーSSH鍵のリクエスト（`/api/v4/users/:user_id/keys`） | 毎分120件のリクエスト |
| 単一SSH鍵のリクエスト（`/api/v4/users/:id/keys/:key_id`） | 毎分120件のリクエスト |
| ユーザーGPGキーリクエスト（`/api/v4/users/:id/gpg_keys`） | 毎分120件のリクエスト |
| 単一のGPGキーリクエスト（`/api/v4/users/:id/gpg_keys/:key_id`） | 毎分120件のリクエスト |
| ユーザープロジェクトリクエスト（`/api/v4/users/:user_id/projects`） | 毎分300件のリクエスト |
| ユーザーがコントリビュートしたプロジェクトのリクエスト（`/api/v4/users/:user_id/contributed_projects`） | 毎分100件のリクエスト |
| ユーザーのお気に入りプロジェクトのリクエスト（`/api/v4/users/:user_id/starred_projects`） | 毎分100件のリクエスト |
| プロジェクトリストのリクエスト（`/api/v4/projects`） | 10分ごとに2,000件のリクエスト |
| グループプロジェクトのリクエスト（`/api/v4/groups/:id/projects`） | 毎分600件のリクエスト |
| 単一プロジェクトのリクエスト（`/api/v4/projects/:id`） | 毎分400件のリクエスト |
| グループリストのリクエスト（`/api/v4/groups`） | 毎分200件のリクエスト |
| 単一グループのリクエスト（`/api/v4/groups/:id`） | 毎分400件のリクエスト |
[保護パス](#protected-paths-throttle)および[rawエンドポイント](../../administration/settings/rate_limits_on_raw_endpoints.md)のレート制限の詳細については、リンク先をご覧ください。
GitLabは、いくつかのレイヤーでリクエストのレート制限を行うことができます。ここにリストされているレート制限は、アプリケーションで設定されています。これらの制限は、各IPアドレスに対して最も制限の厳しいものです。GitLab.comのレート制限の詳細については、[ハンドブックのドキュメント](https://handbook.gitlab.com/handbook/engineering/infrastructure/rate-limiting)を参照してください。
### エクスポートファイルをアップロードすることによるグループとプロジェクトのインポート
不正利用を防ぐため、以下はレート制限されています。
- プロジェクトとグループのインポート
- ファイルを使用するグループおよびプロジェクトのエクスポート
- エクスポートのダウンロード
詳細については、以下を参照してください。
- [プロジェクトのインポート/エクスポートのレート制限](../project/settings/import_export.md#rate-limits)
- [グループのインポート/エクスポートのレート制限](../project/settings/import_export.md#rate-limits-1)
### IPブロック
IPブロックは、GitLab.comが単一のIPアドレスからシステムが潜在的に悪意のあるものと見なす異常なトラフィックを受信した場合に発生する可能性があります。これは、レート制限の設定に基づく可能性があります。異常なトラフィックが停止すると、次のセクションで説明するように、ブロックの種類に応じてIPアドレスが自動的に解放されます。
GitLab.comへのすべてのリクエストに対して`403 Forbidden`エラーが表示される場合は、ブロックをトリガーしている可能性のある自動プロセスがないか確認してください。サポートが必要な場合は、影響を受けているIPアドレスなどの詳細を添えて[GitLabサポート](https://support.gitlab.com)にお問い合わせください。
#### Gitおよびコンテナレジストリの認証失敗によるBAN
単一のIPアドレスから1分間に300件の認証失敗リクエストを受信した場合、GitLab.comは15分間HTTPステータスコード`403`を返します。
これは、Gitリクエストおよびコンテナレジストリ（`/jwt/auth`）リクエスト（結合）にのみ適用されます。
この制限は、次のようになります。
- 認証に成功したリクエストでリセットされます。たとえば、299件の認証失敗リクエストの後に1件の成功リクエストがあり、その後に299件の認証失敗リクエストが続いても、BANはトリガーされません。
- `gitlab-ci-token`で認証されたJWTリクエストには適用されません。
応答ヘッダーは提供されません。
`git`リクエストは`https`経由で常に最初に認証されていないリクエストを送信します。これにより、プライベートリポジトリでは`401`エラーが発生します。`git`は次に、ユーザー名、パスワード、またはアクセストークン（利用可能な場合）を使用して認証されたリクエストを試行します。これらのリクエストでは、同時にあまりに多くのリクエストが送信されると、一時的なIPブロックにつながる可能性があります。この問題を解決するには、[SSH鍵を使用してGitLabと通信します](../ssh.md)。
### 設定できない制限
設定できないレート制限で、GitLab.comでも使用されているレート制限については、「[設定できない制限](../../security/rate_limits.md#non-configurable-limits)」を参照してください。
### ページネーション応答ヘッダー
パフォーマンス上の理由から、クエリが10,000件を超えるレコードを返す場合、[GitLabは一部のヘッダーを除外](../../api/rest/_index.md#pagination-response-headers)します。
### 保護パスのスロットル
同じIPアドレスが1分間に10件を超えるPOSTリクエストを保護パスに送信すると、GitLab.comは`429` HTTPステータスコードを返します。
どのパスが保護されているかについては、以下のソースを参照してください。これには、ユーザーの作成、ユーザーの確認、ユーザーのサインイン、パスワードのリセットが含まれます。
[ユーザーとIPのレート制限](../../administration/settings/user_and_ip_rate_limits.md#response-headers)には、ブロックされたリクエストに応答するヘッダーのリストが含まれています。
詳細については、「[保護パス](../../administration/settings/protected_paths.md)」を参照してください。
### レート制限の応答
レート制限の応答については、以下を参照してください。
- [ブロックされたリクエストに対する応答のヘッダーリスト](../../administration/settings/user_and_ip_rate_limits.md#response-headers)
- [カスタマイズ可能な応答テキスト](../../administration/settings/user_and_ip_rate_limits.md#use-a-custom-rate-limit-response)
### SSHの最大接続数
GitLab.com は、[MaxStartups設定](https://man.openbsd.org/sshd_config.5#MaxStartups)を使用して、同時実行される認証されていないSSH接続の最大数を定義します。許可されている最大数を超える接続が同時に発生した場合、それらの接続はドロップされ、ユーザーに[`ssh_exchange_identification`エラー](../../topics/git/troubleshooting_git.md#ssh_exchange_identification-error)が表示されます。
### 表示レベル設定
プロジェクト、グループ、スニペットには、GitLab.comで[無効になっている](https://gitlab.com/gitlab-org/gitlab/-/issues/12388)[内部表示レベル](../public_access.md#internal-projects-and-groups)設定があります。
## Sidekiq
GitLab.comは、Rubyジョブのスケジュール設定のために、[Sidekiq](https://sidekiq.org)を[外部プロセス](../../administration/sidekiq/_index.md)として実行します。
現在の設定は、[GitLab.com Kubernetesポッド設定](https://gitlab.com/gitlab-com/gl-infra/k8s-workloads/gitlab-com/-/blob/master/releases/gitlab/values/gprd.yaml.gotmpl)にあります。
## SSH鍵と認証
SSHでの認証に関連する設定。最大接続数については、「[SSHの最大接続数](#ssh-maximum-number-of-connections)」を参照してください。
### 代替SSHポート
GitLab.comには、`git+ssh`に対して[別のSSHポート](https://about.gitlab.com/blog/2016/02/18/gitlab-dot-com-now-supports-an-alternate-git-plus-ssh-port/)を使用してアクセスできます。
| 設定 | 値 |
|------------|---------------------|
| `Hostname` | `altssh.gitlab.com` |
| `Port` | `443` |
次に、`~/.ssh/config`の例を示します。
```plaintext
Host gitlab.com
Hostname altssh.gitlab.com
User git
Port 443
PreferredAuthentications publickey
IdentityFile ~/.ssh/gitlab
```
### SSHホストキーのフィンガープリント
現在のインスタンス設定に移動して、GitLab.comのSSHホストキーのフィンガープリントを確認します。
1. GitLabにサインインします。
1. 左側のサイドバーで、**ヘルプ**（{{< icon name="question-o" >}}）>**ヘルプ**を選択します。
1. ヘルプページで、**現在のインスタンス設定を確認する**を選択します。
インスタンス設定では、**SSHホストキーのフィンガープリント**が表示されます。
| アルゴリズム | MD5（非推奨） | SHA256 |
|------------------|------------------|---------|
| ECDSA | `f1:d0:fb:46:73:7a:70:92:5a:ab:5d:ef:43:e2:1c:35` | `SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw` |
| ED25519 | `2e:65:6a:c8:cf:bf:b2:8b:9a:bd:6d:9f:11:5c:12:16` | `SHA256:eUXGGm1YGsMAS7vkcx6JOJdOGHPem5gQp4taiCfCLB8` |
| RSA | `b6:03:0e:39:97:9e:d0:e7:24:ce:a3:77:3e:01:42:09` | `SHA256:ROQFvPThGrW4RuWLoL9tq9I9zJ42fK4XywyRtbOz/EQ` |
GitLab.comリポジトリに初めて接続するとき、これらのキーのいずれかが出力に表示されます。
### SSH鍵の制限
GitLab.comは、デフォルトの[SSH鍵制限](../../security/ssh_keys_restrictions.md)を使用します。
### SSH`known_hosts`エントリ
SSHで手動フィンガープリントの確認をスキップするには、以下を`.ssh/known_hosts`に追加します。
```plaintext
gitlab.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAfuCHKVTjquxvt6CM6tdG4SLp1Btn/nOeHHE5UOzRdf
gitlab.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCsj2bNKTBSpIYDEGk9KxsGh3mySTRgMtXL583qmBpzeQ+jqCMRgBqB98u3z++J1sKlXHWfM9dyhSevkMwSbhoR8XIq/U0tCNyokEi/ueaBMCvbcTHhO7FcwzY92WK4Yt0aGROY5qX2UKSeOvuP4D6TPqKF1onrSzH9bx9XUf2lEdWT/ia1NEKjunUqu1xOB/StKDHMoX4/OKyIzuS0q/T1zOATthvasJFoPrAjkohTyaDUz2LN5JoH839hViyEG82yB+MjcFV5MU3N1l1QL3cVUCh93xSaua1N85qivl+siMkPGbO5xR/En4iEY6K2XPASUEMaieWVNTRCtJ4S8H+9
gitlab.com ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBFSMqzJeV9rUzU4kWitGjeR4PWSa29SPqJ1fVkhtj3Hw9xjLVXVYrU9QlYWrOLXBpQ6KWjbjTDTdDkoohFzgbEY=
```
## Webhook
次の制限が[Webhook](../project/integrations/webhooks.md)に適用されます。
### レート制限
トップレベルのネームスペースごとに、Webhookを呼び出すことができる1分あたりの回数は制限されます。この制限は、プランとサブスクリプションのシート数によって異なります。
| プラン | GitLab.comのデフォルト |
|----------------------|-------------------------|
| Free | `500` |
| Premium | `99`シート以下: `1,600`<br>`100-399`シート: `2,800`<br>`400`シート以上: `4,000` |
| Ultimateとオープンソース |`999`シート以下: `6,000`<br>`1,000-4,999`シート: `9,000`<br>`5,000`シート以上: `13,000` |
### その他の制限
| 設定 | GitLab.comのデフォルト |
|:--------------------------------------------------------------------|:-----------------------|
| Webhookの数 | プロジェクトごとに100件、グループごとに50件（サブグループのWebhookは親グループの制限にはカウントされません） |
| 最大ペイロードサイズ | 25 MB |
| タイムアウト | 10秒 |
| [Pagesの並列デプロイ](../project/pages/parallel_deployments.md#limits) | 100件の追加のデプロイ（Premiumプラン）、500件の追加のデプロイ（Ultimateプラン） |
GitLab Self-Managedインスタンスの制限については、以下を参照してください。
- [Webhookのレート制限](../../administration/instance_limits.md#webhook-rate-limit)
- [Webhookの数](../../administration/instance_limits.md#number-of-webhooks)
- [Webhookのタイムアウト](../../administration/instance_limits.md#webhook-timeout)
- [Pagesの並列デプロイ](../../administration/instance_limits.md#number-of-parallel-pages-deployments)

493
doc-locale/ja-jp/user/group/_index.md Normal file
View File

@ -0,0 +1,493 @@
---
stage: Tenant Scale
group: Organizations
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: グループ
---
{{< details >}}
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
{{< /details >}}
GitLabでは、グループを使用して、1つまたは複数の関連プロジェクトを同時に管理します。
グループを使用すると、すべてのグループメンバーとコミュニケーションを取り、プロジェクトの権限を管理できます。グループへのアクセス権を持っているユーザーは、そのグループ内のすべてのプロジェクへのアクセス権を取得します。
また、グループ内のプロジェクトのすべてのイシューとマージリクエスト、およびグループのアクティビティーに関する分析を表示することもできます。
大規模な組織の場合は、[サブグループ](subgroups/_index.md)を作成することもできます。
グループの作成と管理の詳細については、「[グループを管理する](manage.md)」を参照してください。
## グループ階層
グループは、ツリー構造で編成されています。
- **トップレベルグループ**は、組織の「ルート」に作成されたグループです。1つの組織に、1つまたは複数のトップレベルグループを含めることができます。トップレベルグループには、1つまたは複数のサブグループを含めることができます。
- **親グループ**は、1つまたは複数のサブグループを含むグループです。
- **サブグループ**は、別のグループに属するグループです。
たとえば、次の図について説明します。
- 組織に4つのグループがあります。1つのトップレベルグループ（T）に1つのサブグループ（G）があり、G内に2つのサブグループ（AとB）が含まれています。
- Tはトップレベルグループであり、Gの親グループです。
- GはTのサブグループ（子）であり、AとBの親グループです。
- AとBはGのサブグループ（子）です。
```mermaid
%%{init: { "fontFamily": "GitLab Sans", 'theme':'neutral' }}%%
flowchart TD
accTitle: Group hierarchy
accDescr: Example of a group hierarchy in an organization
subgraph Organization
T[Group T] --> G[Group G]
G --> A[Group A]
G --> B[Group B]
end
```
## グループ構造
グループの設定方法は、ユースケース、チーム規模、アクセス要件によって異なります。次の表に、グループを構成する最も一般的なモデルを示します。
<!-- vale gitlab_base.Simplicity = NO -->
| モデル | 構造 | ユースケース |
| ----- | --------- | --------- |
| シンプル | すべてのプロジェクトに1つのグループ | シームレスなコラボレーションとリソースへのアクセスを必要とする小規模なチームまたは特定のソリューション（マーケティングWebサイトなど）で作業する。 |
| チーム | さまざまなタイプのチーム（製品チームやエンジニアリングチームなど）向けのさまざまなグループまたはサブグループ | 一部のチームが自律的に作業する場合、または外部チームメンバーからの集中的なリソースと制限されたアクセスを必要とする大規模な組織で作業する。 |
| クライアント | クライアントごとに1つのグループ | 異なるリソースとアクセスレベルを必要とする複数のクライアントにカスタムソリューションを提供する。 |
| 機能 | 1つのタイプの機能（AI/MLなど）に1つのグループまたはサブグループ | 1つの機能に特定の専門家によるリソースとコラボレーションが必要な複雑な製品を開発する。 |
<!-- vale gitlab_base.Simplicity = YES -->
{{< alert type="note" >}}
GitLab Self-Managedで、組織全体の概要を確認する場合は、トップレベルグループを1つ作成する必要があります。すべてのグループの組織ビューを作成するための取り組みについては、[エピック9266を参照してください](https://gitlab.com/groups/gitlab-org/-/epics/9266)。トップレベルグループは、完全な[セキュリティダッシュボードとセキュリティセンター](../application_security/security_dashboard/_index.md)、[脆弱性レポート](../application_security/vulnerability_report/_index.md)、[コンプライアンスセンター](../compliance/compliance_center/_index.md)、[バリューストリーム分析](value_stream_analytics/_index.md)を通じて、組織全体のインサイトを提供します。
{{< /alert >}}
## グループの表示レベル
プロジェクトと同様に、グループは次のユーザーに表示されるように設定できます。
- 匿名ユーザー
- すべての認証済みユーザー
- 明示的なグループメンバーのみ
アプリケーション設定レベルでの[表示レベル](../../administration/settings/visibility_and_access_controls.md#restrict-visibility-levels)の制限は、グループにも適用されます。内部に設定すると、検索ページは匿名ユーザーに対して空になります。グループページには、表示レベルのアイコンがあります。
ユーザーは、直属の親グループよりも高い表示レベルでサブグループまたはプロジェクトを作成できません。
## 複数のグループを表示する
自分がメンバーであるすべてのパブリックグループを検索するには:
1. 左側のサイドバーで、**検索または移動**を選択します。
1. **すべてのグループを表示**を選択します。
1. 右上隅で、**グループを検索する**を選択します。
直接または間接的にメンバーシップを持っているグループを表示するには:
1. 左側のサイドバーで、**検索または移動**を選択します。
1. **すべてのグループを表示**を選択します。
このページには、以下によって自分がメンバーであるグループが表示されます。
- サブグループの親グループのメンバーシップ
- グループまたはサブグループ内のプロジェクトの直接または継承されたメンバーシップ
## 1つのグループを表示する
グループの概要ページには、グループとそのメンバー、サブグループ、プロジェクトに関する次の情報が表示されます。
- グループの説明
- 最近のアクティビティー
- 作成されたマージリクエストとイシューの数
- 追加されたメンバーの数
- サブグループとプロジェクト
- 共有プロジェクト
- アーカイブされたプロジェクト
グループを表示するには:
- 左側のサイドバーで、**検索または移動**を選択し、グループを検索します。
グループのサブグループとプロジェクトを検索し、昇順または降順に並べ替えることができます。
## グループのアクティビティーを表示する
グループのアクティビティーを表示するには:
1. 左側のサイドバーで、**検索または移動**を選択し、グループを検索します。
1. **管理>アクティビティー**を選択します。
1. オプション: コントリビュートの種類でアクティビティーをフィルタリングするには、次のタブを選択します。
- **すべて**: グループメンバーによる、グループおよびグループのプロジェクト内のすべてのコントリビュート
- **プッシュイベント**: グループのプロジェクトでのプッシュイベント
- **マージイベント**: グループのプロジェクトで承認されたマージリクエスト
- **イシューイベント**: グループのプロジェクトでオープンまたはクローズされたイシュー
- **コメント**: グループメンバーによってグループのプロジェクトに投稿されたコメント
- **Wiki**: グループ内のWikiページの更新
- **デザイン**: グループのプロジェクトで追加、更新、削除されたデザイン
- **チーム**: グループのプロジェクトに参加および離脱したグループメンバー
### グループIDを使用してグループにアクセスする
{{< history >}}
- GitLab 17.5で[導入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/165889)されました。
{{< /history >}}
`https://gitlab.example.com/-/g/<id>`で、名前の代わりにIDを使用してグループにアクセスできます。たとえば、グループ`example-group`のIDが`123456`の場合、`https://gitlab.example.com/example-group`または`https://gitlab.example.com/-/g/123456`でグループにアクセスできます。
[GitLab API](../../api/_index.md)を使用してグループを操作する場合は、グループIDが必要になる場合があります。
グループIDをコピーするには:
1. 左側のサイドバーで、**検索または移動**を選択し、グループを検索します。
1. グループの概要ページの右上隅で、**アクション**（{{< icon name="ellipsis_v" >}}）を選択します。
1. **グループIDをコピー**を選択します。
## グループを作成する
グループを作成するには:
<!-- vale gitlab_base.FutureTense = NO -->
1. 左側のサイドバーの上部で、**新規作成**（{{< icon name="plus" >}}）を選択し、**新規グループ**を選択します。
1. **グループを作成**を選択します。
1. **グループ名**テキストボックスに、グループの名前を入力します。グループ名として使用できない単語のリストについては、[予約済みの名前](../reserved_names.md)を参照してください。
1. **グループURL**テキストボックスに、[ネームスペース](../namespace/_index.md)に使用するグループのパスを入力します。
1. グループの[**表示レベル**](../public_access.md)を選択します。
1. オプション: GitLabエクスペリエンスをパーソナライズするには:
- **だれがこのグループを使用しますか？**で、オプションを選択します。
- **このグループを何に使う予定ですか？**ドロップダウンリストから、オプションを選択します。
1. オプション: グループにメンバーを招待するには、**メール1**テキストボックスに、招待するユーザーのメールアドレスを入力します。他のユーザーを招待するには、**他のメンバーを招待**を選択し、ユーザーのメールアドレスを入力します。
1. **グループを作成**を選択します。
<!-- vale gitlab_base.FutureTense = YES -->
<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>グループの詳細については、「[GitLab Namespaces (users, groups and subgroups)](https://youtu.be/r0sJgjR2f5A) GitLabネームスペース（ユーザー、グループ、サブグループ）」をご覧ください。
## グループ名、説明、アバターを編集する
グループの詳細は、グループの一般設定から編集できます。
前提要件:
- グループのオーナーロールを持っている必要があります。
グループの詳細を編集するには:
1. 左側のサイドバーで、**検索または移動**を選択し、グループを検索します。
1. **設定>一般**を選択します。
1. **グループ名**テキストボックスに、グループ名を入力します。[グループ名の制限](../reserved_names.md)を参照してください。
1. オプション: **グループの説明（任意）**テキストボックスに、グループの説明を入力します。説明は500文字に制限されています。
1. オプション: **グループアバター**で、**ファイルを選択**を選択し、画像を選択します。理想的な画像サイズは192 x 192ピクセルで、許可される最大ファイルサイズは200 KBです。
1. **変更の保存**を選択します。
## グループを離脱する
{{< history >}}
- GitLab 16.7で、グループを離脱するためのボタンがアクションメニューに[移動](https://gitlab.com/gitlab-org/gitlab/-/issues/431539)しました。
{{< /history >}}
グループを離脱すると、次のようになります。
- グループ、そのサブグループ、およびプロジェクトのメンバーではなくなり、コントリビュートできなくなります。
- 割り当てられていたすべてのイシューとマージリクエストの割り当てが解除されます。
グループを離脱するには:
1. 左側のサイドバーで、**検索または移動**を選択し、グループを検索します。
1. グループの概要ページの右上隅で、**アクション**（**{ellipsis_v}**）を選択します。
1. **グループを離脱**を選択し、もう一度**グループを離脱**を選択します。
## グループを削除する
{{< history >}}
- GitLab 16.0の[GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/393622)と[GitLab Self-Managed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/119606)で、遅延削除がデフォルトで有効になり、即時削除のオプションが削除されました。
{{< /history >}}
グループとそのコンテンツを削除するには:
1. 左側のサイドバーで、**検索または移動**を選択し、グループを検索します。
1. **設定>一般**を選択します。
1. **高度な設定**セクションを展開します。
1. **グループを削除**セクションで、**グループを削除**を選択します。
1. 確認ダイアログで、グループ名を入力し、**確認**を選択します。
グループダッシュボードからグループを削除することもできます。
1. 左側のサイドバーで、**検索または移動**を選択します。
1. **すべてのグループを表示**を選択します。
1. 削除するグループの（{{< icon name="ellipsis_v" >}}）を選択します。
1. **削除**を選択します。
1. **グループを削除**セクションで、**グループを削除**を選択します。
1. 確認ダイアログで、グループ名を入力し、**確認**を選択します。
GitLab [Premium](https://about.gitlab.com/pricing/premium/)および[Ultimate](https://about.gitlab.com/pricing/ultimate/)では、このアクションにより、バックグラウンドジョブが追加され、グループが削除対象としてマークされます。デフォルトでは、ジョブは削除を7日後にスケジュールします。この保持期間は、[インスタンス設定](../../administration/settings/visibility_and_access_controls.md#deletion-protection)から変更できます。
グループの削除をスケジュールしたユーザーが、削除の実行前にグループへのアクセス権を失った場合（グループを離脱したり、ロールがダウングレードされたり、グループからBANされたりした場合）、削除ジョブは代わりにグループを復元してアーカイブ解除するため、グループは削除対象としてスケジュールされなくなります。
{{< alert type="warning" >}}
ジョブの実行前に、グループの削除をスケジュールしたユーザーがオーナーロールまたは管理者アクセス権を回復した場合、ジョブはグループを完全に削除します。
{{< /alert >}}
### 削除保留中のグループを表示する
{{< details >}}
- プラン: Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
{{< /details >}}
グループで削除保留中のサブグループのリストを表示するには:
1. 左側のサイドバーで、**検索または移動**を選択し、グループを検索します。
1. **サブグループとプロジェクト**を選択します。
削除対象としてマークされているグループには、**削除の保留中**というラベルが付いています。
## グループをすぐに削除する
{{< details >}}
- プラン: Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
{{< /details >}}
{{< history >}}
- GitLab 16.0の[GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/393622)と[GitLab Self-Managed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/119606)で、遅延削除がデフォルトで有効になり、即時削除のオプションが削除されました。
{{< /history >}}
待機しない場合は、グループをすぐに削除できます。
前提要件:
- グループのオーナーロールを持っている必要があります。
- [グループを削除対象としてマーク](#delete-a-group)していること。
削除対象としてマークされたグループをすぐに削除するには:
1. 左側のサイドバーで、**検索または移動**を選択し、グループを検索します。
1. **設定>一般**を選択します。
1. **高度な設定**を展開します。
1. **グループを永久に削除**セクションで、**グループを削除**を選択します。
1. 要求されたら、アクションを確認します。
このアクションにより、グループ、そのサブグループ、プロジェクト、およびイシューやマージリクエストを含むすべての関連リソースが削除されます。
## グループを復元する
{{< details >}}
- プラン: Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
{{< /details >}}
削除対象としてマークされているグループを復元するには:
1. 左側のサイドバーで、**検索または移動**を選択し、グループを検索します。
1. **設定>一般**を選択します。
1. **高度な設定**セクションを展開します。
1. **グループを復元**セクションで、**グループを復元**を選択します。
## グループへのアクセスをリクエストする
ユーザーは、管理者が許可すれば、グループのメンバーになることをリクエストできます。
1. 左側のサイドバーで、**検索または移動**を選択します。
1. **すべてのグループを表示**を選択します。
1. 右上隅で、**グループを検索する**を選択します。
1. **名前で検索**テキストボックスに、参加するグループの名前を入力します。
1. 検索結果で、グループの名前を選択します。
1. グループページで、グループ名の下にある**アクセスをリクエスト**を選択します。
最近アクティブなグループオーナーの上位10人までが、リクエストを記載したメールを受信します。グループオーナーは、リクエストを承認または拒否できます。
リクエストが承認される前に気が変わった場合は、**アクセスリクエストを取り消す**を選択します。
## グループメンバーを表示する
グループのメンバーを表示するには:
1. 左側のサイドバーで、**検索または移動**を選択し、グループを検索します。
1. **管理>メンバー**を選択します。
表には、メンバーについて次の内容が表示されます。
- **アカウント**名とユーザー名
- **メンバーシップ**の[ソース](../project/members/_index.md#membership-types): 透明性を確保するため、GitLabはグループメンバーのすべてのメンバーシップソースを表示します。複数のメンバーシップソースを持つメンバーは、個別のメンバーとして表示およびカウントされます。たとえば、メンバーがグループに直接および継承によって追加されている場合、そのメンバーは異なるソースで**メンバー**テーブルに2回表示され、グループの2人の個々のメンバーとしてカウントされます。
- グループでの[**ロール**](../project/members/_index.md#which-roles-you-can-assign)
- グループメンバーシップの**有効期限**
- アカウントに関連する**アクティビティー**
{{< alert type="note" >}}
グループメンバーの**ソース**の表示に一貫性がない場合があります。詳細については、[イシュー23020](https://gitlab.com/gitlab-org/gitlab/-/issues/23020)を参照してください。
{{< /alert >}}
すべてのネームスペースメンバー（およびそれぞれの占有シート）を表示するには、トップレベルのネームスペースで、[**使用量割り当て**ページを表示](../../subscriptions/gitlab_com/_index.md#view-seat-usage)します。
## グループ内のメンバーをフィルタリングおよび並べ替える
グループ内のメンバーを検索するには、並べ替え、フィルタリング、または検索を実行します。
### グループをフィルタリングする
グループをフィルタリングしてメンバーを見つけます。デフォルトでは、グループとサブグループのすべてのメンバーが表示されます。
グループメンバーのリストでは、エントリに次のバッジが表示されることがあります。
- **SAML**: メンバーに接続されている[SAMLアカウント](saml_sso/_index.md)があることを示します。
- **Enterprise**: トップレベルグループのメンバーが[Enterpriseユーザー](../enterprise_user/_index.md)であることを示します。
1. 左側のサイドバーで、**検索または移動**を選択し、グループを検索します。
1. **管理>メンバー**を選択します。
1. メンバーリストの上にある**メンバーをフィルターする**テキストボックスに、検索条件を入力します。表示するには:
- グループの直接メンバーを表示するには、**メンバーシップ = 直接**を選択します。
- グループの継承、共有、および継承共有メンバーを表示するには、**メンバーシップ = 間接**を選択します。
- 2要素認証が有効または無効になっているメンバーを表示するには、**2FA = 有効**または**2FA = 無効**を選択します。
- [Enterpriseユーザー](../enterprise_user/_index.md)であるトップレベルグループのメンバーを表示するには、**Enterprise = true**を選択します。
### グループを検索する
名前、ユーザー名、または[公開メール](../profile/_index.md#set-your-public-email)でメンバーを検索できます。
1. 左側のサイドバーで、**検索または移動**を選択し、グループを検索します。
1. **管理>メンバー**を選択します。
1. メンバーのリストの上にある**メンバーをフィルターする**ボックスに、検索条件を入力します。
1. **メンバーをフィルターする**ボックスの右側にある虫眼鏡（{{< icon name="search" >}}）を選択します。
### グループ内のメンバーを並べ替える
メンバーを**アカウント**、**アクセス付与日**、**ロール**、または**最終ログイン**で並べ替えることができます。
1. 左側のサイドバーで、**検索または移動**を選択し、グループを検索します。
1. **管理>メンバー**を選択します。
1. メンバーリストの上にある右上隅の**アカウント**リストから、フィルタリング条件を選択します。
1. 並べ替えを昇順と降順で切り替えるには、**アカウント**リストの右側にある矢印（{{< icon name="sort-lowest" >}}または{{< icon name="sort-highest" >}}）を選択します。
## グループにユーザーを追加する
{{< history >}}
- GitLab 16.2で、期限切れになるアクセス権に関するメール通知が[導入](https://gitlab.com/gitlab-org/gitlab/-/issues/12704)されました。
- GitLab 17.4で、サブグループおよびプロジェクトの直接メンバーのアクセス権の有効期限が[削除](https://gitlab.com/gitlab-org/gitlab/-/issues/471051)されました。
{{< /history >}}
ユーザーにグループ内のすべてのプロジェクトへのアクセス権を付与できます。
前提要件:
- グループのオーナーロールを持っている必要があります。
- [サインアップが無効になっている](../../administration/settings/sign_up_restrictions.md#disable-new-sign-ups)場合は、管理者が最初にメールでユーザーを追加する必要があります。
- [ロールの昇格についての管理者](../../administration/settings/sign_up_restrictions.md#turn-on-administrator-approval-for-role-promotions)が有効になっている場合は、管理者が招待を承認する必要があります。
1. 左側のサイドバーで、**検索または移動**を選択し、グループを検索します。
1. **管理>メンバー**を選択します。
1. **メンバーを招待**を選択します。
1. ユーザーは次の操作を行います。
- GitLabアカウントを持っている場合は、ユーザーのユーザー名を入力します。
- GitLabアカウントを持っていない場合は、ユーザーのメールアドレスを入力します。
1. [デフォルトロール](../permissions.md)または[カスタムロール](../custom_roles/_index.md)を選択します。
1. オプション: **アクセス権の有効期限**に、日付を入力または選択します。その日付以降、ユーザーはプロジェクトにアクセスできなくなります。
アクセス権の有効期限を入力した場合、グループメンバーはアクセス権の有効期限が切れる7日前にメール通知を受け取ります。
{{< alert type="warning" >}}
メンテナーは、自分のアクセス権の有効期限を延長する機能を含め、ロールの有効期限が切れるまで完全な権限を持ちます。
{{< /alert >}}
1. **招待**を選択します。ユーザーを次のいずれかで招待した場合:
- GitLabのユーザー名: ユーザーはメンバーリストに追加されます。
- メールアドレス: ユーザーはメールによる招待を受け取り、アカウントを作成するように求められます。招待が承認されない場合、GitLabは2日後、5日後、および10日後にリマインダーメールを送信します。未承認の招待は、90日後に自動的に削除されます。
自動的に追加されないメンバーは、**招待済み**タブに表示されます。このタブには、次のユーザーが含まれます。
- 招待をまだ承諾していないユーザー
- [管理者からの承認](../../administration/moderate_users.md)を待機しているユーザー
- [グループのユーザー上限を超えている](manage.md#user-cap-for-groups)ユーザー
### 昇格保留中のユーザーを表示する
[ロールの昇格に対する管理者の承認](../../administration/settings/sign_up_restrictions.md#turn-on-administrator-approval-for-role-promotions)が有効になっている場合は、既存のユーザーを請求可能なロールに昇格するメンバーシップリクエストには、管理者による承認が必要です。
昇格保留中のユーザーを表示するには:
1. 左側のサイドバーで、**検索または移動**を選択し、グループを検索します。
1. **管理>メンバー**を選択します。
1. **ロールの昇格**タブを選択します。
**ロールの昇格**タブが表示されない場合、グループには保留中の昇格はありません。
## グループからメンバーを削除する
前提要件:
- オーナーロールを持っている必要があります。
- メンバーはグループの直接メンバーシップを持っている必要があります。メンバーシップが親グループから継承されている場合、メンバーは親グループからのみ削除できます。
グループからメンバーを削除するには:
1. 左側のサイドバーで、**検索または移動**を選択し、グループを検索します。
1. **管理>メンバー**を選択します。
1. 削除するメンバーの横にある縦方向の省略記号（{{< icon name="ellipsis_v" >}}）を選択します。
1. **メンバーを削除**を選択します。
1. オプション: **メンバーを削除**確認ダイアログで、次のチェックボックスの一方または両方を選択します。
- **サブグループやプロジェクトから直接ユーザーのメンバーシップを削除する**
- **また、関連するイシューとマージリクエストからこのユーザーのアサインを解除します**
1. **メンバーを削除**を選択します。
GitLab管理者は、[削除されたユーザーが自分自身を再度招待できないようにする](../project/members/_index.md#ensure-removed-users-cannot-invite-themselves-back)こともできます。
## グループにプロジェクトを追加する
グループに新しいプロジェクトを追加するには、次の2つの方法があります。
- グループを選択し、**新規プロジェクト**を選択します。次に、[プロジェクトの作成](../project/_index.md)を続行します。
- プロジェクトの作成中に、ドロップダウンリストからグループを選択します。
![グループを選択する](img/select_group_dropdown_v13_10.png)
### グループにプロジェクトを追加できるユーザーを指定する
デフォルトでは、少なくとも次のロールを持つユーザーが次の操作を実行できます。
- デベロッパーロールは、グループにプロジェクトを作成できます。このデフォルトは変更できます。
- メンテナーロールは、プロジェクトをグループにフォークできます。このデフォルトにより、デベロッパーロールを持つユーザーは保護ブランチを含むプロジェクトをフォークできません。また、このデフォルトは変更できません。
グループでプロジェクトを作成できるロールを指定するには:
1. 左側のサイドバーで、**検索または移動**を選択し、グループを検索します。
1. **設定>一般**を選択します。
1. **権限とグループ機能**セクションを展開します。
1. **プロジェクトの作成に必要な最小ロール**から、オプションを選択します。
1. **変更の保存**を選択します。
この設定をグローバルに変更する方法の詳細については、[プロジェクトの作成に必要なデフォルトの最小ロール](../../administration/settings/visibility_and_access_controls.md#define-which-roles-can-create-projects)を参照してください。

198
doc-locale/ja-jp/user/packages/container_registry/_index.md Normal file
View File

@ -0,0 +1,198 @@
---
stage: Package
group: Container Registry
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: GitLabコンテナレジストリ
---
{{< details >}}
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
{{< /details >}}
統合されたコンテナレジストリを使用して、各GitLabプロジェクトのコンテナイメージを保存できます。
GitLabインスタンスのコンテナレジストリを有効にするには、[管理者ドキュメント](../../../administration/packages/container_registry.md)を参照してください。
{{< alert type="note" >}}
Docker Hubからコンテナイメージをプルする場合は、[GitLab依存プロキシ](../dependency_proxy/_index.md#use-the-dependency-proxy-for-docker-images)を使用すると、レート制限を回避してパイプラインを高速化できます。
{{< /alert >}}
## コンテナレジストリを表示する
プロジェクトまたはグループのコンテナレジストリを表示できます。
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトまたはグループを検索します。
1. **デプロイ>コンテナレジストリ**の順に選択します。
コンテナイメージは、検索、並べ替え、フィルタリング、[削除](delete_container_registry_images.md#use-the-gitlab-ui)できます。ブラウザからURLをコピーすると、フィルタリングしたビューを共有できます。
### コンテナレジストリ内の特定のコンテナイメージのタグを表示する
コンテナレジストリの**タグの詳細**ページを使用して、特定のコンテナイメージに関連付けられているタグのリストを表示できます。
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトまたはグループを検索します。
1. **デプロイ>コンテナレジストリ**の順に選択します。
1. コンテナイメージを選択します。
公開日時、使用ストレージ量、マニフェスト、設定のダイジェストなどの各タグに関する詳細を表示できます。
このページで、タグを検索、並べ替え（タグ名順）、[削除](delete_container_registry_images.md#use-the-gitlab-ui)できます。ブラウザからURLをコピーすると、フィルタリングしたビューを共有できます。
### ストレージ使用量
コンテナレジストリのストレージ使用量を表示して、プロジェクトおよびグループ全体にわたってコンテナリポジトリのサイズを追跡して管理できます。
詳細については、「[コンテナレジストリの使用状況を表示する](../../../user/packages/container_registry/reduce_container_registry_storage.md#view-container-registry-usage)」を参照してください。
## コンテナレジストリからコンテナイメージを使用する
コンテナレジストリでホストされているコンテナイメージをダウンロードして実行するには:
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトまたはグループを検索します。
1. **デプロイ>コンテナレジストリ**の順に選択します。
1. 作業対象のコンテナイメージを検索して、**イメージパスをコピー**（{{< icon name="copy-to-clipboard" >}}）を選択します。
1. コピーしたリンクを使用して`docker run`を実行します。
```shell
docker run [options] registry.example.com/group/project/image [arguments]
```
{{< alert type="note" >}}
プライベートリポジトリからコンテナイメージをダウンロードするには、[コンテナレジストリで認証](authenticate_with_container_registry.md)を行う必要があります。
{{< /alert >}}
コンテナイメージの実行の詳細については、[Dockerのドキュメント](https://docs.docker.com/get-started/)を参照してください。
## コンテナイメージの命名規則
コンテナイメージは、次の命名規則に準拠する必要があります。
```plaintext
<registry server>/<namespace>/<project>[/<optional path>]
```
たとえば、プロジェクトが`gitlab.example.com/mynamespace/myproject`の場合、コンテナイメージの名前は`gitlab.example.com/mynamespace/myproject`にする必要があります。
コンテナイメージ名の最後に、最大2レベルの深さまで追加の名前を付加できます。
たとえば、以下はすべて`myproject`という名前のプロジェクト内のコンテナイメージに有効な名前です。
```plaintext
registry.example.com/mynamespace/myproject:some-tag
```
```plaintext
registry.example.com/mynamespace/myproject/image:latest
```
```plaintext
registry.example.com/mynamespace/myproject/my/image:rc1
```
## コンテナレジストリのリポジトリを移動または名前変更する
コンテナリポジトリのパスは、関連するプロジェクトのリポジトリパスと常に一致するため、コンテナレジストリのみを名前変更または移動することはできません。代わりに、プロジェクト全体を[名前変更](../../project/working_with_projects.md#rename-a-repository)または[移動](../../project/settings/migrate_projects.md)できます。
入力済みのコンテナリポジトリがあるプロジェクトの名前変更は、GitLab.comでのみサポートされています。
GitLab Self-Managedインスタンスでは、グループまたはプロジェクトを移動または名前を変更する前に、すべてのコンテナイメージを削除できます。別の方法として、[イシュー18383](https://gitlab.com/gitlab-org/gitlab/-/issues/18383#possible-workaround)では、この制限を回避するためのコミュニティからの提案が説明されています。[エピック9459](https://gitlab.com/groups/gitlab-org/-/epics/9459)では、コンテナリポジトリがあるプロジェクトとグループをGitLab Self-Managedに移動するためのサポートを追加することが提案されています。
## プロジェクトのコンテナレジストリを無効にする
コンテナレジストリはデフォルトで有効になっています。
ただし、次の手順でプロジェクトのコンテナレジストリを削除できます。
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトを検索します。
1. **設定>一般**を選択します。
1. **可視性、プロジェクトの機能、権限**セクションを展開し、**コンテナレジストリ**を無効にします。
1. **変更の保存**を選択します。
**デプロイ>コンテナレジストリ**エントリがプロジェクトのサイドバーから削除されます。
## コンテナレジストリの表示レベルを変更する
デフォルトでは、コンテナレジストリはプロジェクトへのアクセス権を持つすべてのユーザーに表示されます。ただし、プロジェクトのコンテナレジストリの表示レベルは変更できます。
この設定がユーザーに付与する権限の詳細については、[コンテナレジストリの表示レベル権限](#container-registry-visibility-permissions)を参照してください。
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトを検索します。
1. **設定>一般**を選択します。
1. **可視性、プロジェクトの機能、権限**セクションを展開します。
1. **コンテナレジストリ**で、次のようにドロップダウンリストからオプションを選択します。
- **アクセスできる人すべて**（デフォルト）: コンテナレジストリは、プロジェクトへのアクセス権を持つすべてのユーザーに表示されます。プロジェクトがパブリックの場合、コンテナレジストリもパブリックになります。プロジェクトが内部またはプライベートの場合、コンテナレジストリも内部またはプライベートになります。
- **プロジェクトメンバーのみ**: コンテナレジストリは、少なくともレポーターロールを持つプロジェクトメンバーにのみ表示されます。この表示レベルは、コンテナレジストリの表示レベルが**アクセスできる人すべて**に設定されているプライベートプロジェクトの動作に似ています。
1. **変更の保存**を選択します。
## コンテナレジストリの表示レベル権限
コンテナレジストリの表示機能とコンテナイメージのプル機能は、コンテナレジストリの表示レベル権限によって制御されます。表示レベルは、[UIの表示レベル設定](#change-visibility-of-the-container-registry)または[API](../../../api/container_registry.md#change-the-visibility-of-the-container-registry)で変更できます。コンテナレジストリの更新、コンテナイメージのプッシュまたは削除などの[その他の権限](../../permissions.md)は、この設定の影響を受けません。ただし、コンテナレジストリを無効にすると、すべてのコンテナレジストリ操作が無効になります。
| | | 匿名<br/>（インターネット上のすべてのユーザー） | ゲスト | レポーター、デベロッパー、メンテナー、オーナー |
|-------------------------------------------------------------------------------------------------------------------|-----------------------------------------------|--------------------------------------|-------|----------------------------------------|
| コンテナレジストリの表示レベルがあるパブリックプロジェクト <br/> **アクセスできる人すべて**（UI）または`enabled`（API）に設定する | コンテナレジストリを表示する <br/> イメージをプルする | 可 | 可 | 可 |
| コンテナレジストリの表示レベルがあるパブリックプロジェクト <br/> **プロジェクトメンバーのみ**（UI）または`private`（API）に設定する | コンテナレジストリを表示する <br/> イメージをプルする | 不可 | 不可 | 可 |
| コンテナレジストリの表示レベルがある内部プロジェクト <br/> **アクセスできる人すべて**（UI）または`enabled`（API）に設定する | コンテナレジストリを表示する <br/> イメージをプルする | 不可 | 可 | 可 |
| コンテナレジストリの表示レベルがある内部プロジェクト <br/> **プロジェクトメンバーのみ**（UI）または`private`（API）に設定する | コンテナレジストリを表示する <br/> イメージをプルする | 不可 | 不可 | 可 |
| コンテナレジストリの表示レベルがあるプライベートプロジェクト <br/> **アクセスできる人すべて**（UI）または`enabled`（API）に設定する | コンテナレジストリを表示する <br/> イメージをプルする | 不可 | 不可 | 可 |
| コンテナレジストリの表示レベルがあるプライベートプロジェクト <br/> **プロジェクトメンバーのみ**（UI）または`private`（API）に設定する | コンテナレジストリを表示する <br/> イメージをプルする | 不可 | 不可 | 可 |
| コンテナレジストリが`disabled`のすべてのプロジェクト | コンテナレジストリに対するすべての操作 | 不可 | 不可 | 不可 |
## サポートされているイメージタイプ
{{< history >}}
- GitLab 16.6で、OCI仕様が[導入](https://gitlab.com/groups/gitlab-org/-/epics/10345)されました。
{{< /history >}}
コンテナレジストリは、[Docker V2](https://distribution.github.io/distribution/spec/manifest-v2-2/)と[Open Container Initiative（OCI）](https://github.com/opencontainers/image-spec/blob/main/spec.md)のイメージ形式をサポートしています。さらに、コンテナレジストリは[OCI配布仕様に準拠](https://conformance.opencontainers.org/#gitlab-container-registry)しています。
OCIサポートとは、[Helm 3以降のチャートパッケージ](https://helm.sh/docs/topics/registries/)など、OCIベースのイメージ形式をレジストリでホストできることを意味します。GitLab [API](../../../api/container_registry.md)とUIでのイメージ形式に差異はありません。[イシュー38047](https://gitlab.com/gitlab-org/gitlab/-/issues/38047)では、Helmから始め、この区別について説明しています。
## コンテナイメージの署名
{{< history >}}
- GitLab 17.1で、コンテナイメージの署名の表示が[導入](https://gitlab.com/groups/gitlab-org/-/epics/7856)されました。
{{< /history >}}
GitLabコンテナレジストリでは、[OCI 1.1マニフェストの`subject`フィールド](https://github.com/opencontainers/image-spec/blob/v1.1.0/manifest.md)を使用して、コンテナイメージを[Cosign署名](../../../ci/yaml/signing_examples.md)に関連付けることができます。これにより、該当する署名のタグを検索する必要なく、署名情報は関連付けられたコンテナイメージとともに表示されるようになります。
[コンテナイメージのタグを表示する](#view-the-tags-of-a-specific-container-image-in-the-container-registry)際、関連付けられた署名がある各タグの横にアイコンが表示されます。署名の詳細を表示するには、アイコンをクリックします。
前提要件:
- コンテナイメージに署名するには、Cosign v2.0以降が必要です。
- GitLab Self-Managedの場合、署名を表示するには、[メタデータデータベースで設定されたGitLabコンテナレジストリ](../../../administration/packages/container_registry_metadata_database.md)が必要です。
### OCIリファラーデータを使用してコンテナイメージに署名する
Cosignを使用して署名にリファラーデータを追加するには、次の操作を行う必要があります。
- `COSIGN_EXPERIMENTAL`環境変数を`1`に設定します。
- `--registry-referrers-mode oci-1-1`を署名コマンドに追加します。
次に例を示します。
```shell
COSIGN_EXPERIMENTAL=1 cosign sign --registry-referrers-mode oci-1-1 <container image>
```
{{< alert type="note" >}}
GitLabコンテナレジストリはOCI 1.1マニフェストの`subject`フィールドをサポートしていますが、[OCI 1.1 Referrers API](https://github.com/opencontainers/distribution-spec/blob/v1.1.0/spec.md#listing-referrers)を完全に実装しているわけではありません。
{{< /alert >}}

675
doc-locale/ja-jp/user/packages/npm_registry/_index.md Normal file
View File

@ -0,0 +1,675 @@
---
stage: Package
group: Package Registry
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: パッケージレジストリ内のnpmパッケージ
---
{{< details >}}
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
{{< /details >}}
Node Package Manager（npm）は、JavaScriptおよびNode.jsのデフォルトのパッケージマネージャーです。デベロッパーはnpmを使用して、コードの共有と再利用、依存関係の管理、プロジェクトワークフローの効率化を行います。GitLabでは、npmパッケージはソフトウェア開発ライフサイクルにおいて重要な役割を果たします。
npmパッケージマネージャークライアントが使用する特定のAPIエンドポイントのドキュメントについては、[npm APIドキュメント](../../../api/packages/npm.md)を参照してください。
[npm](../workflows/build_packages.md#npm)パッケージまたは[yarn](../workflows/build_packages.md#yarn)パッケージをビルドする方法については、リンク先を参照してください。
GitLabパッケージレジストリにnpmパッケージを公開する方法については、こちらの[動画デモ](https://youtu.be/yvLxtkvsFDA)をご覧ください。
## パッケージレジストリへの認証
プライベートプロジェクトまたはプライベートグループからパッケージを公開またはインストールするには、パッケージレジストリに対して認証を行う必要があります。プロジェクトまたはグループがパブリックの場合、認証は不要です。プロジェクトが内部の場合、GitLabインスタンスの登録ユーザーである必要があります。匿名ユーザーは内部プロジェクトからパッケージをプルできません。
認証を行うには、以下を使用できます。
- スコープが`api`に設定された[パーソナルアクセストークン](../../profile/personal_access_tokens.md)
- スコープが`read_package_registry`、`write_package_registry`、またはその両方に設定された[デプロイトークン](../../project/deploy_tokens/_index.md)
- [CI/CDジョブトークン](../../../ci/jobs/ci_job_token.md)
組織で2要素認証（2FA）を使用している場合は、スコープが`api`に設定されたパーソナルアクセストークンを使用する必要があります。CI/CDパイプラインでパッケージを公開する場合は、CI/CDジョブトークンを使用する必要があります。詳細については、[トークンに関するガイダンス](../package_registry/_index.md#authenticate-with-the-registry)参照してください。
ここに記載されている方法以外の認証方法は使用しないでください。ドキュメント化されていない認証方法は、将来削除される可能性があります。
### `.npmrc`ファイルを使用する場合
`package.json`と同じディレクトリに`.npmrc`ファイルを作成または編集します。`.npmrc`ファイルに次の行を含めます。
```shell
//<domain_name>/api/v4/projects/<project_id>/packages/npm/:_authToken="${NPM_TOKEN}"
```
{{< alert type="warning" >}}
リポジトリにコミットできる`.npmrc`ファイルやその他のファイルに、GitLabトークン（またはその他のトークン）を直接ハードコーディングしないでください。
{{< /alert >}}
次に例を示します。
{{< tabs >}}
{{< tab title="インスタンスの場合" >}}
```shell
//<domain_name>/api/v4/packages/npm/:_authToken="${NPM_TOKEN}"
```
`<domain_name>`をドメイン名に置き換えます。たとえば、`gitlab.com`などです。
{{< /tab >}}
{{< tab title="グループの場合" >}}
```shell
//<domain_name>/api/v4/groups/<group_id>/-/packages/npm/:_authToken="${NPM_TOKEN}"
```
必ず以下を置き換えてください。
- `<domain_name>`をドメイン名に置き換えます。たとえば、`gitlab.com`などです。
- `<group_id>`をグループのホームページのグループIDに置き換えます。
{{< /tab >}}
{{< tab title="プロジェクトの場合" >}}
```shell
//<domain_name>/api/v4/projects/<project_id>/packages/npm/:_authToken="${NPM_TOKEN}"
```
必ず以下を置き換えてください。
- `<domain_name>`をドメイン名に置き換えます。たとえば、`gitlab.com`などです。
- `<project_id>`を[プロジェクトの概要ページ](../../project/working_with_projects.md#access-a-project-by-using-the-project-id)のプロジェクトIDに置き換えます。
{{< /tab >}}
{{< /tabs >}}
### `npm config set`を使用する場合
以下を実行します。
```shell
npm config set -- //<domain_name>/:_authToken=<token>
```
npmのバージョンによっては、URLを変更する必要が生じる場合があります。
- npmバージョン7以前では、完全なURLをエンドポイントに使用してください。
- バージョン8以降では、`_authToken`パラメーターに対して、[完全なURLの代わりにURIフラグメントを使用](https://docs.npmjs.com/cli/v8/configuring-npm/npmrc/?v=true#auth-related-configuration)できます。[グループ固有のエンドポイント](https://gitlab.com/gitlab-org/gitlab/-/issues/299834)はサポートされていません。
次に例を示します。
{{< tabs >}}
{{< tab title="インスタンスの場合" >}}
```shell
npm config set -- //<domain_name>/api/v4/packages/npm/:_authToken=<token>
```
必ず以下を置き換えてください。
- `<domain_name>`をドメイン名に置き換えます。たとえば、`gitlab.com`などです。
- `<token>`をデプロイトークン、グループアクセストークン、プロジェクトアクセストークン、またはパーソナルアクセストークンに置き換えます。
{{< /tab >}}
{{< tab title="グループの場合" >}}
```shell
npm config set -- //<domain_name>/api/v4/groups/<group_id>/-/packages/npm/:_authToken=<token>
```
必ず以下を置き換えてください。
- `<domain_name>`をドメイン名に置き換えます。たとえば、`gitlab.com`などです。
- `<group_id>`をグループのホームページのグループIDに置き換えます。
- `<token>`をデプロイトークン、グループアクセストークン、プロジェクトアクセストークン、またはパーソナルアクセストークンに置き換えます。
{{< /tab >}}
{{< tab title="プロジェクトの場合" >}}
```shell
npm config set -- //<domain_name>/api/v4/projects/<project_id>/packages/npm/:_authToken=<token>
```
必ず以下を置き換えてください。
- `<domain_name>`をドメイン名に置き換えます。たとえば、`gitlab.com`などです。
- `<project_id>`を[プロジェクトの概要ページ](../../project/working_with_projects.md#access-a-project-by-using-the-project-id)のプロジェクトIDに置き換えます。
- `<token>`をデプロイトークン、グループアクセストークン、プロジェクトアクセストークン、またはパーソナルアクセストークンに置き換えます。
{{< /tab >}}
{{< /tabs >}}
## レジストリURLを設定する
GitLabパッケージレジストリからパッケージを公開またはインストールするには、正しいレジストリURLを使用するようにnpmを設定する必要があります。設定方法とURL構造は、パッケージを公開するかインストールするかによって異なります。
レジストリURLを設定する前に、さまざまな設定方法のスコープを理解することが重要です。
- `.npmrc`ファイル: ファイルを含むフォルダーに対してローカルに設定されます。
- `npm config set`コマンド: グローバルnpm設定を変更し、システムで実行されるすべてのnpmコマンドに影響します。
- `publishConfig`（`package.json`内）: この設定はパッケージに固有であり、そのパッケージを公開するときにのみ適用されます。
{{< alert type="warning" >}}
`npm config set`を実行すると、グローバルnpm設定が変更されます。この変更は、現在の作業ディレクトリに関係なく、システムで実行されるすべてのnpmコマンドに影響します。特に共有システムでは、この方法を使用する際は注意が必要です。
{{< /alert >}}
### パッケージを公開する場合
パッケージを公開する場合は、プロジェクトエンドポイントを使用します。
```shell
https://gitlab.example.com/api/v4/projects/<project_id>/packages/npm/
```
`gitlab.example.com`をGitLabインスタンスのドメインに、`<project_id>`をプロジェクトIDに置き換えます。このURLを設定するには、次のいずれかの方法を使用します。
{{< tabs >}}
{{< tab title="`.npmrc`ファイル" >}}
プロジェクトのルートで`.npmrc`ファイルを作成または編集します。
```plaintext
@scope:registry=https://gitlab.example.com/api/v4/projects/<project_id>/packages/npm/
//gitlab.example.com/api/v4/projects/<project_id>/packages/npm/:_authToken="${NPM_TOKEN}"
```
{{< /tab >}}
{{< tab title="`npm config`" >}}
`npm config set`コマンドを使用します。
```shell
npm config set @scope:registry=https://gitlab.example.com/api/v4/projects/<project_id>/packages/npm/
```
{{< /tab >}}
{{< tab title="`package.json`" >}}
`package.json`に`publishConfig`セクションを追加します。
```shell
{
"publishConfig": {
"@scope:registry": "https://gitlab.example.com/api/v4/projects/<project_id>/packages/npm/"
}
}
```
{{< /tab >}}
{{< /tabs >}}
`@scope`をパッケージのスコープに置き換えます。
### パッケージをインストールする場合
パッケージをインストールするときは、プロジェクト、グループ、またはインスタンスのエンドポイントを使用できます。URL構造はそれぞれに応じて異なります。これらのURLを設定するには、次のいずれかの方法を使用します。
{{< tabs >}}
{{< tab title="`.npmrc`ファイル" >}}
プロジェクトのルートにある`.npmrc`ファイルを作成または編集します。ニーズに基づいて適切なURLを使用します。
- プロジェクトの場合:
```shell
@scope:registry=https://gitlab.example.com/api/v4/projects/<project_id>/packages/npm/
```
- グループの場合:
```shell
@scope:registry=https://gitlab.example.com/api/v4/groups/<group_id>/-/packages/npm/
```
- インスタンスの場合:
```shell
@scope:registry=https://gitlab.example.com/api/v4/packages/npm/
```
{{< /tab >}}
{{< tab title="`npm config`" >}}
適切なURLを指定して`npm config set`コマンドを使用します。
- プロジェクトの場合:
```shell
npm config set @scope:registry=https://gitlab.example.com/api/v4/projects/<project_id>/packages/npm/
```
- グループの場合:
```shell
npm config set @scope:registry=https://gitlab.example.com/api/v4/groups/<group_id>/-/packages/npm/
```
- インスタンスの場合:
```shell
npm config set @scope:registry=https://gitlab.example.com/api/v4/packages/npm/
```
{{< /tab >}}
{{< /tabs >}}
`gitlab.example.com`、`<project_id>`、`<group_id>`、`@scope`を、GitLab インスタンスとパッケージの適切な値に置き換えます。
レジストリURLを設定したら、パッケージレジストリに対して認証を行うことができます。
## GitLabパッケージレジストリに公開する
npmパッケージをGitLabパッケージレジストリに公開するには、[認証](#authenticate-to-the-package-registry)されている必要があります。
### 命名規則
パッケージのインストール方法によっては、命名規則に従う必要がある場合があります。
パッケージのインストールには、次の3つのAPIエンドポイントのいずれかを使用できます。
- **インスタンス**: 異なるGitLabグループまたは独自のネームスペースに多数のnpmパッケージがある場合に使用します。
- **グループ**: 同じグループまたはサブグループの異なるプロジェクトに多数のnpmパッケージがある場合に使用します。
- **プロジェクト**: npmパッケージの数が少なく、それらが同じGitLabグループにない場合に使用します。
[プロジェクト](#install-from-a-project)または[グループ](#install-from-a-group)からパッケージをインストールする場合、命名規則に従う必要はありません。
[インスタンス](#install-from-an-instance)からパッケージをインストールする場合は、[スコープ](https://docs.npmjs.com/misc/scope/)を使用してパッケージに名前を付ける必要があります。スコープ付きパッケージは`@`で始まり、`@owner/package-name`の形式になります。`.npmrc`ファイルで、および`package.json`で`publishConfig`オプションを使用して、パッケージのスコープを設定できます。
- `@scope`に使用される値は、パッケージのソースコードを含むプロジェクトのルートではなく、パッケージをホストしているプロジェクトのルートです。スコープは小文字にする必要があります。
- パッケージ名は任意に設定できます。
| プロジェクトURL | パッケージレジストリ | スコープ | パッケージのフルネーム |
| ------------------------------------------------------- | ------------------- | --------- | ---------------------- |
| `https://gitlab.com/my-org/engineering-group/analytics` | 分析 | `@my-org` | `@my-org/package-name` |
`package.json`ファイル内のパッケージの名前が、次の規則に一致していることを確認してください。
```shell
"name": "@my-org/package-name"
```
### コマンドラインでパッケージを公開する
[認証](#authenticate-to-the-package-registry)を設定したら、次のコマンドでNPMパッケージを公開します。
```shell
npm publish
```
`.npmrc`ファイルを認証に使用している場合は、予想される環境変数を設定します。
```shell
NPM_TOKEN=<token> npm publish
```
アップロードされたパッケージに複数の`package.json`ファイルがある場合、最初に見つかったファイルのみが使用され、その他は無視されます。
### CI/CDパイプラインでパッケージを公開する
CI/CDパイプラインを使用して公開する場合は、[定義済み変数](../../../ci/variables/predefined_variables.md)の`${CI_PROJECT_ID}`と`${CI_JOB_TOKEN}`を使用して、プロジェクトのパッケージレジストリで認証できます。GitLabはこれらの変数を使用して、CI/CDジョブの実行中に認証を行うための`.npmrc`ファイルを作成します。
{{< alert type="note" >}}
`.npmrc`ファイルを生成する際は、ポートがデフォルトポートである場合は`${CI_SERVER_HOST}`の後にポートを指定しないでください。`http` URLはデフォルトで`80`に、`https` URLはデフォルトで`443`になります。
{{< /alert >}}
`package.json`を含むGitLabプロジェクトで、`.gitlab-ci.yml`ファイルを編集または作成します。次に例を示します。
```yaml
default:
image: node:latest
stages:
- deploy
publish-npm:
stage: deploy
script:
- echo "@scope:registry=https://${CI_SERVER_HOST}/api/v4/projects/${CI_PROJECT_ID}/packages/npm/" > .npmrc
- echo "//${CI_SERVER_HOST}/api/v4/projects/${CI_PROJECT_ID}/packages/npm/:_authToken=${CI_JOB_TOKEN}" >> .npmrc
- npm publish
```
`@scope`を、公開するパッケージの[スコープ](https://docs.npmjs.com/cli/v10/using-npm/scope/)に置き換えます。
パイプラインで`publish-npm`ジョブが実行されると、パッケージがパッケージレジストリに公開されます。
## パッケージをインストールする
複数のパッケージの名前とバージョンが同じ場合、パッケージをインストールすると、最後に公開されたパッケージが取得されます。
GitLabのプロジェクト、グループ、またはインスタンスからパッケージをインストールできます。
- **インスタンス**: 異なるGitLabグループまたは独自のネームスペースに多数のnpmパッケージがある場合に使用します。
- **グループ**: 同じGitLabグループの異なるプロジェクトに多数のnpmパッケージがある場合に使用します。
- **プロジェクト**: npmパッケージの数が少なく、それらが同じGitLabグループにない場合に使用します。
### インスタンスからインストールする
前提要件:
- パッケージが、スコープ付き[命名規則](#naming-convention)に従って公開されていること。
1. [パッケージレジストリに対して認証](#authenticate-to-the-package-registry)します。
1. レジストリを次のように設定します。
```shell
npm config set @scope:registry https://<domain_name>.com/api/v4/packages/npm/
```
- `@scope`を、パッケージをインストールするプロジェクトの[トップレベルグループ](#naming-convention)に置き換えます。
- `<domain_name>`をドメイン名に置き換えます（例: `gitlab.com`）。
1. パッケージをインストールします。
```shell
npm install @scope/my-package
```
### グループからインストールする
{{< history >}}
- GitLab 16.0で、`npm_group_level_endpoints`という名前の[フラグとともに](../../../administration/feature_flags.md)[導入](https://gitlab.com/gitlab-org/gitlab/-/issues/299834)されました。デフォルトでは無効になっています。
- GitLab 16.1で[一般提供](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121837)になりました。機能フラグ`npm_group_level_endpoints`が削除されました。
{{< /history >}}
1. [パッケージレジストリに対して認証](#authenticate-to-the-package-registry)します。
1. レジストリを次のように設定します。
```shell
npm config set @scope:registry=https://<domain_name>/api/v4/groups/<group_id>/-/packages/npm/
```
- `@scope`を、パッケージをインストールするグループの[トップレベルグループ](#naming-convention)に置き換えます。
- `<domain_name>`をドメイン名に置き換えます（例: `gitlab.com`）。
- `<group_id>`を、グループのホームページのグループIDに置き換えます。
1. パッケージをインストールします。
```shell
npm install @scope/my-package
```
### プロジェクトからインストールする
1. [パッケージレジストリに対して認証](#authenticate-to-the-package-registry)します。
1. レジストリを次のように設定します。
```shell
npm config set @scope:registry=https://<domain_name>/api/v4/projects/<project_id>/packages/npm/
```
- `@scope`を、パッケージをインストールするプロジェクトの[トップレベルグループ](#naming-convention)に置き換えます。
- `<domain_name>`をドメイン名に置き換えます（例: `gitlab.com`）。
- `<project_id>`を、[プロジェクトの概要ページ](../../project/working_with_projects.md#access-a-project-by-using-the-project-id)のプロジェクトIDに置き換えます。
1. パッケージをインストールします。
```shell
npm install @scope/my-package
```
### npmjs.comへのパッケージ転送
{{< history >}}
- GitLab 12.9で[導入](https://gitlab.com/gitlab-org/gitlab/-/issues/55344)されました。
- GitLab 17.0で、必要なロールがメンテナーからオーナーに[変更](https://gitlab.com/gitlab-org/gitlab/-/issues/370471)されました。
{{< /history >}}
npmパッケージがパッケージレジストリにない場合、GitLabはHTTPリダイレクトで応答し、リクエストクライアントがリクエストを[npmjs.com](https://www.npmjs.com/)に再送信できるようにします。
管理者は、[継続的インテグレーションの設定](../../../administration/settings/continuous_integration.md)でこの動作を無効にできます。
グループオーナーは、グループの**パッケージとレジストリ**の設定でこの動作を無効にできます。
改善点は[エピック3608](https://gitlab.com/groups/gitlab-org/-/epics/3608)で追跡されています。
## パッケージを非推奨にする
{{< history >}}
- GitLab 16.0で[導入](https://gitlab.com/gitlab-org/gitlab/-/issues/396763)されました。
{{< /history >}}
パッケージを非推奨にすると、パッケージのフェッチ時に非推奨の警告を表示できます。
前提要件:
- パッケージを削除するために必要な[権限](../../permissions.md)を持っていること。
- [パッケージレジストリに対して認証](#authenticate-to-the-package-registry)されていること。
コマンドラインから、以下を実行します。
```shell
npm deprecate @scope/package "Deprecation message"
```
CLIは`@scope/package`のバージョン範囲も受け入れます。次に例を示します。
```shell
npm deprecate @scope/package "All package versions are deprecated"
npm deprecate @scope/package@1.0.1 "Only version 1.0.1 is deprecated"
npm deprecate @scope/package@"< 1.0.5" "All package versions less than 1.0.5 are deprecated"
```
パッケージが非推奨になると、そのステータスが`deprecated`に更新されます。
### 非推奨の警告を削除する
パッケージの非推奨の警告を削除するには、メッセージに`""`（空の文字列）を指定します。次に例を示します。
```shell
npm deprecate @scope/package ""
```
パッケージの非推奨の警告が削除されると、そのステータスが`default`に更新されます。
## 役立つヒント
### 他の組織からnpmパッケージをインストールする
パッケージのリクエストをGitLab外部の組織やユーザーにルーティングできます。
これを行うには、`.npmrc`ファイルに以下の行を追加します。`@my-other-org`を、プロジェクトのリポジトリを所有するネームスペースまたはグループに置き換え、組織のURLを使用します。名前は大文字と小文字が区別され、グループまたはネームスペースの名前と完全に一致する必要があります。
```shell
@scope:registry=https://my_domain_name.com/api/v4/packages/npm/
@my-other-org:registry=https://my_domain_name.example.com/api/v4/packages/npm/
```
### npmメタデータ
GitLabパッケージレジストリは、次の属性をnpmクライアントに公開します。これらは[省略されたメタデータ形式](https://github.com/npm/registry/blob/main/docs/responses/package-metadata.md#abbreviated-version-object)に類似しています。
- `name`
- `versions`
- `name`
- `version`
- `deprecated`
- `dependencies`
- `devDependencies`
- `bundleDependencies`
- `peerDependencies`
- `bin`
- `directories`
- `dist`
- `engines`
- `_hasShrinkwrap`
- `hasInstallScript`: このバージョンにインストールスクリプトがある場合は`true`。
### npmディストリビューションタグを追加する
新しく公開されたパッケージに[ディストリビューションタグ](https://docs.npmjs.com/cli/dist-tag/)を追加できます。タグはオプションであり、一度に1つのパッケージにのみ割り当てることができます。
タグを指定せずにパッケージを公開すると、`latest`タグがデフォルトで追加されます。タグまたはバージョンを指定せずにパッケージをインストールすると、`latest`タグが使用されます。
サポートされている`dist-tag`コマンドの例:
```shell
npm publish @scope/package --tag # Publish a package with new tag
npm dist-tag add @scope/package@version my-tag # Add a tag to an existing package
npm dist-tag ls @scope/package # List all tags under the package
npm dist-tag rm @scope/package@version my-tag # Delete a tag from the package
npm install @scope/package@my-tag # Install a specific tag
```
#### CI/CDから
{{< history >}}
- GitLab 15.10で[導入](https://gitlab.com/gitlab-org/gitlab/-/issues/258835)されました。
{{< /history >}}
[`CI_JOB_TOKEN`](../../../ci/jobs/ci_job_token.md)または[デプロイトークン](../../project/deploy_tokens/_index.md)を使用して、GitLab CI/CDジョブで`npm dist-tag`コマンドを実行できます。
前提要件:
- npmバージョン6.9.1以降が必要です。以前のバージョンでは、npm 6.9.0のバグによりディストリビューションタグの削除に失敗します。
次に例を示します。
```yaml
npm-deploy-job:
script:
- echo "//${CI_SERVER_HOST}/api/v4/projects/${CI_PROJECT_ID}/packages/npm/:_authToken=${CI_JOB_TOKEN}">.npmrc
- npm dist-tag add @scope/package@version my-tag
```
### サポートされているCLIコマンド
GitLab npmリポジトリは、npm CLI（`npm`）とyarn CLI（`yarn`）の次のコマンドをサポートしています。
- `npm install`: npmパッケージをインストールします。
- `npm publish`: npmパッケージをレジストリに公開します。
- `npm dist-tag add`: npmパッケージにディストリビューションタグを追加します。
- `npm dist-tag ls`: パッケージのディストリビューションタグを一覧表示します。
- `npm dist-tag rm`: ディストリビューションタグを削除します。
- `npm ci`: `package-lock.json`ファイルから直接npmパッケージをインストールします。
- `npm view`: パッケージのメタデータを表示します。
- `npm pack`: パッケージからtarballを作成します。
- `npm deprecate`: パッケージのバージョンを非推奨にします。
## トラブルシューティング
### npmログが正しく表示されない
次のエラーが発生する可能性があります。
```shell
npm ERR! A complete log of this run can be found in: .npm/_logs/<date>-debug-0
```
ログが`.npm/_logs/`ディレクトリに表示されない場合は、ログをルートディレクトリにコピーして、そこで表示できます。
```yaml
script:
- npm install --loglevel verbose
- cp -r /root/.npm/_logs/ .
artifacts:
paths:
- './_logs'
```
npmログは、アーティファクトとして`/root/.npm/_logs/`にコピーされます。
### `npm install`または`yarn`で`404 Not Found`エラーが発生している
`CI_JOB_TOKEN`を使用して別のプロジェクトの依存関係を持つnpmパッケージをインストールすると、404 Not Found エラーが発生します。パッケージとそのすべての依存関係へのアクセス権を持つトークンで認証する必要があります。
パッケージとその依存関係が同じグループ内の別々のプロジェクトにある場合は、[グループデプロイトークン](../../project/deploy_tokens/_index.md#create-a-deploy-token)を使用できます。
```ini
//gitlab.example.com/api/v4/packages/npm/:_authToken=<group-token>
@group-scope:registry=https://gitlab.example.com/api/v4/packages/npm/
```
パッケージとその依存関係が複数のグループに分散している場合は、すべてのグループまたは個々のプロジェクトへのアクセス権を持つユーザーからの[パーソナルアクセストークン](../../profile/personal_access_tokens.md)を使用できます。
```ini
//gitlab.example.com/api/v4/packages/npm/:_authToken=<personal-access-token>
@group-1:registry=https://gitlab.example.com/api/v4/packages/npm/
@group-2:registry=https://gitlab.example.com/api/v4/packages/npm/
```
{{< alert type="warning" >}}
パーソナルアクセストークンは慎重に扱う必要があります。パーソナルアクセストークンの管理（短い有効期限の設定や最小限のスコープの使用など）に関するガイダンスについては、[トークンのセキュリティに関する考慮事項](../../../security/tokens/_index.md#security-considerations)を参照してください。
{{< /alert >}}
### `npm publish`がデフォルトのnpmレジストリ（`registry.npmjs.org`）をターゲットにしている
`package.json`ファイルと`.npmrc`ファイルで、パッケージスコープが一貫して設定されていることを確認してください。
たとえば、GitLabのプロジェクト名が`@scope/my-package`の場合、`package.json`ファイルは次のようになります。
```json
{
"name": "@scope/my-package"
}
```
そして、`.npmrc`ファイルは次のようになります。
```shell
@scope:registry=https://your_domain_name/api/v4/projects/your_project_id/packages/npm/
//your_domain_name/api/v4/projects/your_project_id/packages/npm/:_authToken="${NPM_TOKEN}"
```
### `npm install`が`npm ERR! 403 Forbidden`を返す
このエラーが発生した場合は、以下を確認してください。
- パッケージレジストリがプロジェクト設定で有効になっている。パッケージレジストリはデフォルトで有効になっていますが、[無効にする](../package_registry/_index.md#turn-off-the-package-registry)こともできます。
- トークンの有効期限が切れておらず、適切な権限がある。
- 指定されたスコープ内に、同じ名前またはバージョンのパッケージがまだ存在しない。
- スコープ付きパッケージのURLの末尾にスラッシュが含まれてる。
- 正しい例: `//gitlab.example.com/api/v4/packages/npm/`
- 誤った例:`//gitlab.example.com/api/v4/packages/npm`
### `npm publish`が`npm ERR! 400 Bad Request`を返す
このエラーが発生した場合は、次のいずれかの問題が原因である可能性があります。
### パッケージ名が命名規則を満たしていない
パッケージ名が[`@scope/package-name`パッケージの命名規則](#naming-convention)を満たしていない可能性があります。
名前が、大文字と小文字を含め、規則に正確に合致していることを確認してください。その後、再度公開してみてください。
### パッケージがすでに存在する
パッケージが同じルートネームスペース内の別のプロジェクトにすでに公開されているため、同じ名前を使用して再度公開することはできません。
これは、以前に公開されたパッケージが同じ名前で、バージョンが異なる場合でも当てはまります。
### Package JSONファイルが大きすぎる
`package.json`ファイルは`20,000`文字を超えないようにしてください。

224
doc-locale/ja-jp/user/packages/package_registry/_index.md Normal file
View File

@ -0,0 +1,224 @@
---
stage: Package
group: Package Registry
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: パッケージレジストリ
---
{{< details >}}
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
{{< /details >}}
{{< history >}}
- 13.3で、GitLab PremiumからGitLab Freeに[移行](https://gitlab.com/gitlab-org/gitlab/-/issues/221259)しました。
{{< /history >}}
GitLabパッケージレジストリを使用すると、GitLabをさまざまな[サポート対象パッケージマネージャー](supported_package_managers.md)のプライベートまたはパブリックレジストリとして使用できます。パッケージを公開および共有して、ダウンストリームプロジェクトで依存関係として使用できます。
## パッケージのワークフロー
GitLabパッケージレジストリを使用して、独自のカスタムパッケージワークフローをビルドする方法を説明します。
- すべてのパッケージを1つのプロジェクトに公開するには、[プロジェクトをパッケージレジストリとして使用](../workflows/project_registry.md)します。
- 1つの[モノレポプロジェクト](../workflows/working_with_monorepos.md)から複数の異なるパッケージを公開します。
## パッケージを表示する
プロジェクトまたはグループのパッケージを表示できます。
1. プロジェクトまたはグループに移動します。
1. **デプロイ>パッケージレジストリ**に移動します。
このページで、パッケージを検索、並べ替え、フィルタリングできます。ブラウザからURLをコピーして貼り付けることで、検索結果を共有できます。
パッケージマネージャーの設定や特定のパッケージのインストールに役立つコードスニペットも見つけることができます。
グループ内のパッケージを表示する場合:
- グループとそのプロジェクトに公開されているすべてのパッケージが表示されます。
- アクセスできるプロジェクトのみが表示されます。
- プロジェクトが非公開の場合、またはプロジェクトのメンバーでない場合、そのプロジェクトのパッケージは表示されません。
パッケージの作成方法とアップロード方法については、[パッケージタイプ](supported_package_managers.md)の手順に従ってください。
## レジストリで認証する
認証は、使用されているパッケージマネージャーによって異なります。特定のパッケージタイプでサポートされている認証プロトコルについては、「[認証プロトコル](supported_functionality.md#authentication-protocols)」を参照してください。
ほとんどのパッケージタイプで、次の認証情報タイプが有効になっています。
- [パーソナルアクセストークン](../../profile/personal_access_tokens.md): ユーザー権限で認証します。パッケージレジストリの個人使用およびローカル使用に適しています。
- [プロジェクトデプロイトークン](../../project/deploy_tokens/_index.md): プロジェクト内のすべてのパッケージへのアクセスを許可します。多くのユーザーへのプロジェクトアクセス権の付与と取り消しに適しています。
- [グループデプロイトークン](../../project/deploy_tokens/_index.md): グループとそのサブグループ内のすべてのパッケージへのアクセスを許可します。多数のパッケージへのアクセス権をユーザーセットに付与および取り消すのに適しています。
- [ジョブトークン](../../../ci/jobs/ci_job_token.md): パイプラインを実行しているユーザーに対して、ジョブを実行しているプロジェクト内のパッケージへのアクセスを許可します。他の外部プロジェクトへのアクセスを設定できます。
- 組織で2要素認証（2FA）を使用している場合は、スコープが`api`に設定されたパーソナルアクセストークンを使用する必要があります。
- CI/CDパイプラインを使用してパッケージを公開する場合は、CI/CDジョブトークンを使用する必要があります。
{{< alert type="note" >}}
パッケージレジストリへの認証を設定する場合:
- **パッケージレジストリ**プロジェクト設定が[オフになっている](#turn-off-the-package-registry)場合、オーナーロールを持っていても、パッケージレジストリを操作すると`403 Forbidden`エラーが発生します。
- [外部認証](../../../administration/settings/external_authorization.md)がオンになっている場合、デプロイトークンでパッケージレジストリにアクセスすることはできません。
{{< /alert >}}
## GitLab CI/CDを使用する
[GitLab CI/CD](../../../ci/_index.md)を使用して、パッケージをビルドしたり、パッケージレジストリにインポートしたりできます。
### パッケージをビルドするには
`CI_JOB_TOKEN`を使用してGitLabで認証できます。
まず、利用可能な[CI/CDテンプレート](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates)を使用します。
CI/CDでのGitLabパッケージレジストリの使用に関する詳細は、以下を参照してください。
- [汎用](../generic_packages/_index.md#publish-a-package)
- [Maven](../maven_repository/_index.md#create-maven-packages-with-gitlab-cicd)
- [NPM](../npm_registry/_index.md#publish-a-package-with-a-cicd-pipeline)
- [NuGet](../nuget_repository/_index.md#publish-a-nuget-package-by-using-cicd)
- [PyPi](../pypi_repository/_index.md#authenticate-with-the-gitlab-package-registry)
- [Terraform](../terraform_module_registry/_index.md#authenticate-to-the-terraform-module-registry)
CI/CDを使用してパッケージをビルドする場合、パッケージの詳細を表示すると、拡張されたアクティビティー情報が表示されます。
![パッケージCI/CDアクティビティー](img/package_activity_v12_10.png)
パッケージを公開したパイプラインとそれをトリガーしたコミットおよびユーザーを表示できます。ただし、履歴は特定のパッケージの5つの更新に制限されています。
### パッケージをインポートするには
別のレジストリにビルドされたパッケージがすでにある場合は、[パッケージインポーター](https://gitlab.com/gitlab-org/ci-cd/package-stage/pkgs_importer)を使用してGitLabパッケージレジストリにパッケージをインポートできます。
サポートされているパッケージのリストについては、「[他のリポジトリからパッケージをインポートする](supported_functionality.md#importing-packages-from-other-repositories)」を参照してください。
## ストレージ使用量を削減する
パッケージレジストリのストレージ使用量を削減する方法については、「[パッケージレジストリのストレージ使用量を削減する](reduce_package_registry_storage.md)」を参照してください。
## パッケージレジストリを無効にする
パッケージレジストリは自動的に有効になっています。
GitLab Self-Managedインスタンスでは、管理者はGitLabサイドバーから**パッケージとレジストリ**メニュー項目を削除できます。詳細については、「[GitLabパッケージレジストリの管理](../../../administration/packages/_index.md)」を参照してください。
プロジェクトのパッケージレジストリを特別に削除することもできます。
1. プロジェクトで、**設定>一般**に移動します。
1. **可視性、プロジェクトの機能、権限**セクションを展開し、**パッケージ**機能を無効にします。
1. **変更の保存**を選択します。
**デプロイ>パッケージレジストリ**エントリがサイドバーから削除されます。
## パッケージレジストリの表示レベル権限
[プロジェクト権限](../../permissions.md)は、どのメンバーとユーザーがパッケージをダウンロード、プッシュ、または削除できるかを決定します。
パッケージレジストリの表示レベルはリポジトリとは無関係で、プロジェクトの設定から制御できます。たとえば、パブリックプロジェクトがあり、リポジトリの表示レベルを**プロジェクトメンバーのみ**に設定した場合、パッケージレジストリはパブリックになります。**パッケージレジストリ**の切替をオフにすると、すべてのパッケージレジストリ操作がオフになります。
| プロジェクトの表示レベル | アクション | 最低限必要な[ロール](../../permissions.md#roles) |
|--------------------|-----------------------|---------------------------------------------------------|
| パブリック | パッケージレジストリを表示する | 該当なし。インターネット上の誰でもこのアクションを実行できます。 |
| パブリック | パッケージを公開する | デベロッパー |
| パブリック | パッケージをプルする | 該当なし。インターネット上の誰でもこのアクションを実行できます。 |
| 内部 | パッケージレジストリを表示する | ゲスト |
| 内部 | パッケージを公開する | デベロッパー |
| 内部 | パッケージをプルする | ゲスト（1） |
| プライベート | パッケージレジストリを表示する | レポーター |
| プライベート | パッケージを公開する | デベロッパー |
| プライベート | パッケージをプルする | レポーター（1） |
### 誰でもパッケージレジストリからプルできるようにする
{{< history >}}
- GitLab 15.7で[導入](https://gitlab.com/gitlab-org/gitlab/-/issues/385994)されました。
- GitLab 17.4で、NuGetグループエンドポイントをサポートするように[変更](https://gitlab.com/gitlab-org/gitlab/-/issues/468058)されました。
- GitLab 17.5で、Mavenグループエンドポイントをサポートするように[変更](https://gitlab.com/gitlab-org/gitlab/-/issues/468059)されました。
- GitLab 17.5で、Terraformモジュールネームスペースエンドポイントをサポートするように[変更](https://gitlab.com/gitlab-org/gitlab/-/issues/468062)されました。
{{< /history >}}
プロジェクトの表示レベルに関係なく、誰でもパッケージレジストリからプルできるようにするには:
1. 左側のサイドバーで、**検索または移動**を選択し、プライベートまたは内部プロジェクトを検索します。
1. **設定>一般**を選択します。
1. **可視性、プロジェクトの機能、権限**を展開します。
1. **パッケージレジストリからだれでもプルできるようにする**切替をオンにします。
1. **変更の保存**を選択します。
インターネット上の誰でもプロジェクトのパッケージレジストリにアクセスできます。
#### 誰でもプルできる機能を無効にする
前提要件:
- 管理者である必要があります。
**パッケージレジストリからだれでもプルできるようにする**切替をグローバルに非表示にするには:
- [アプリケーション設定を更新](../../../api/settings.md#update-application-settings)して、`package_registry_allow_anyone_to_pull_option`を`false`にします。
**パッケージレジストリからだれでもプルできるようにする**切替をオンにしたプロジェクトでも、匿名ダウンロードはオフになります。
誰でもパッケージレジストリからプルできるようにすると、いくつかの既知の問題が発生します。
- プロジェクトのエンドポイントがサポートされています。
- グループのNuGetレジストリエンドポイントがサポートされています。ただし、NuGetクライアントが認証情報を送信する方法により、匿名ダウンロードは許可されていません。この設定がオンになっていても、GitLabユーザーのみパッケージレジストリからプルできます。
- グループのMavenレジストリエンドポイントがサポートされています。
- ネームスペースのTerraformモジュールレジストリエンドポイントがサポートされています。
- 他のグループおよびインスタンスのエンドポイントは完全にはサポートされていません。グループエンドポイントのサポートは、[エピック14234](https://gitlab.com/groups/gitlab-org/-/epics/14234)で提案されています。
- Composerにはグループエンドポイントしかないため、[Composer](../composer_repository/_index.md#install-a-composer-package)では機能しません。
- Conanでは機能しますが、[`conan search`](../conan_repository/_index.md#search-for-conan-packages-in-the-package-registry)を使用すると機能しません。
## 監査イベント
{{< details >}}
- プラン: Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
{{< /details >}}
{{< history >}}
- GitLab 17.10で、`package_registry_audit_events`という名前の[フラグとともに](../../../administration/feature_flags.md)[導入](https://gitlab.com/gitlab-org/gitlab/-/issues/329588)されました。デフォルトでは無効になっています。
{{< /history >}}
パッケージが公開または削除されたときに、監査イベントを作成します。ネームスペースのオーナーは、[GraphQL API](../../../api/graphql/reference/_index.md#packagesettings)を介して`audit_events_enabled`設定を有効にできます。
次の場所に、監査イベントを表示できます。
- パッケージのプロジェクトがグループにある場合は、[**グループ監査イベント**](../../compliance/audit_events.md#group-audit-events)ページに表示されます。
- パッケージのプロジェクトがユーザーネームスペースにある場合は、[**プロジェクト監査イベント**](../../compliance/audit_events.md#project-audit-events)ページに表示されます。
## コントリビュートを受け入れる
次の表に、コントリビュートを受け入れているサポート対象外のパッケージマネージャー形式を示します。GitLabへのコントリビュート方法については、[開発ガイドライン](../../../development/packages/_index.md)を参照してください。
<!-- vale gitlab_base.Spelling = NO -->
| 形式 | ステータス |
| --------- | ------------------------------------------------------------- |
| Chef | [\#36889](https://gitlab.com/gitlab-org/gitlab/-/issues/36889) |
| CocoaPods | [\#36890](https://gitlab.com/gitlab-org/gitlab/-/issues/36890) |
| Conda | [\#36891](https://gitlab.com/gitlab-org/gitlab/-/issues/36891) |
| CRAN | [\#36892](https://gitlab.com/gitlab-org/gitlab/-/issues/36892) |
| Opkg | [\#36894](https://gitlab.com/gitlab-org/gitlab/-/issues/36894) |
| P2 | [\#36895](https://gitlab.com/gitlab-org/gitlab/-/issues/36895) |
| Puppet | [\#36897](https://gitlab.com/gitlab-org/gitlab/-/issues/36897) |
| RPM | [\#5932](https://gitlab.com/groups/gitlab-org/-/epics/5128) |
| SBT | [\#36898](https://gitlab.com/gitlab-org/gitlab/-/issues/36898) |
| Swift | [\#12233](https://gitlab.com/gitlab-org/gitlab/-/issues/12233) |
| Vagrant | [\#36899](https://gitlab.com/gitlab-org/gitlab/-/issues/36899) |
<!-- vale gitlab_base.Spelling = YES -->

479
doc-locale/ja-jp/user/profile/_index.md Normal file
View File

@ -0,0 +1,479 @@
---
stage: Software Supply Chain Security
group: Authentication
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: ユーザーアカウント
---
{{< details >}}
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
{{< /details >}}
各GitLabアカウントには、ユーザープロファイルがあり、ユーザー自身とユーザーのGitLabアクティビティーに関する情報が含まれています。
プロファイルには設定も含まれており、これを使用してGitLabのエクスペリエンスをカスタマイズできます。
## ユーザープロファイルにアクセスする
プロファイルにアクセスするには:
1. 左側のサイドバーで、アバターを選択します。
1. 自分の名前またはユーザー名を選択します。
## ユーザー設定にアクセスする
ユーザー設定にアクセスするには:
1. 左側のサイドバーで、アバターを選択します。
1. **プロファイルを編集**を選択します。
## サポートPINを生成または変更する
GitLabサポートは、ユーザーの身元を確認するために、個人識別番号（PIN）を求める場合があります。PINは作成後7日で有効期限切れになります。
新しいサポートPINを生成するには:
1. 左側のサイドバーで、アバターを選択します。
1. **プロファイルを編集**を選択します。
1. 左側のサイドバーで、**アカウント**を選択します。
1. **新しいPINを生成する**を選択します。
## サポートPINにアクセスする
以前にサポートPINを作成した場合、PINはユーザープロファイルからアクセスでき、作成後7日で有効期限切れになります。
サポートPINにアクセスするには:
1. 左側のサイドバーで、アバターを選択します。
1. **プロファイルを編集**を選択します。
1. 左側のサイドバーで、**アカウント**を選択します。
## ユーザー名を変更する
ユーザー名には一意の[ネームスペース](../namespace/_index.md)があり、ユーザー名を変更すると更新されます。ユーザー名を変更する前に、[リダイレクトが動作する仕組み](../project/repository/_index.md#repository-path-changes)を参照してください。ネームスペースを更新したくない場合は、新しいユーザーまたはグループを作成し、代わりにプロジェクトをそこに転送できます。
前提要件:
- ネームスペースは次の条件を満たしている必要があります。
- [コンテナレジストリ](../packages/container_registry/_index.md)タグ付きのプロジェクトを含まないこと。
- [GitLab Pages](../project/pages/_index.md)をホストするプロジェクトがないこと。詳細については、[GitLabチームハンドブックのユーザー名の変更](https://handbook.gitlab.com/handbook/tools-and-tips/#change-your-username-at-gitlabcom)を参照してください。
- ユーザー名:
- 2～255文字である必要があります。
- アクセント記号なしの文字、数字、`_`、`-`、`.`のみを含める必要があります。
- 次の条件を満たしている必要があります。
- `_`、`-`、または`.`で開始しないこと。
- 絵文字を含まないこと。
- `.`または`.<reserved file extension>`で終わらないこと（例: `jon.png`、`jon.git`、`jon.atom`）。ただし、`jonpng`は有効です。
ユーザー名を変更するには:
1. 左側のサイドバーで、アバターを選択します。
1. **プロファイルを編集**を選択します。
1. 左側のサイドバーで、**アカウント**を選択します。
1. **ユーザー名を変更**セクションで、パスとして新しいユーザー名を入力します。
1. **ユーザー名を更新**を選択します。
## メールをユーザープロファイルに追加する
新しいメールアドレスをアカウントに追加するには:
1. 左側のサイドバーで、アバターを選択します。
1. **プロファイルを編集**を選択します。
1. 左側のサイドバーで、**メール**を選択します。
1. **新しいメールアドレスを追加**を選択します。
1. **メール**テキストボックスに、新しいメールアドレスを入力します。
1. **メールアドレスを追加**を選択します。
1. 受信した確認メールでメールアドレスを確認します。
新しいメールアドレスは、セカンダリメールアドレスとして追加されます。セカンダリメールアドレスは、パスワードのリセットに使用できますが、認証には使用できません。[プライマリメールアドレス](#change-your-primary-email)を更新できます。
{{< alert type="note" >}}
[メールを非公開にする](#set-your-public-email)と、コミットのマッチング、[プロジェクトのインポート](../project/import/_index.md)、[グループの移行](../group/import/_index.md)に使用できなくなります。
{{< /alert >}}
## ユーザープロファイルからメールアドレスを削除する
{{< history >}}
- GitLab 17.0で、未確認のセカンダリメールアドレスの自動削除が[導入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/151562)されました。
{{< /history >}}
セカンダリメールアドレスをアカウントから削除できます。プライマリメールアドレスは削除できません。
削除されたメールアドレスがいずれかのユーザーメールに使用されている場合、それらのユーザーメールは代わりにプライマリメールアドレスに送信されます。
未確認のセカンダリメールアドレスは、3日後に自動的に削除されます。
{{< alert type="note" >}}
[イシュー438600](https://gitlab.com/gitlab-org/gitlab/-/issues/438600)により、グループ通知は削除されたメールアドレスに引き続き送信されます。
{{< /alert >}}
アカウントからメールアドレスを削除するには:
1. 左側のサイドバーで、アバターを選択します。
1. **プロファイルを編集**を選択します。
1. 左側のサイドバーで、**メール**を選択します。
1. **削除**（{{< icon name="remove" >}}）を選択し、**削除**することを確認します。
[APIを使用してセカンダリメールアドレスを削除](../../api/user_email_addresses.md#delete-an-email-address)することもできます。
## ユーザープロファイルページを非公開にする
ユーザープロファイルを自分とGitLab管理者にのみ表示するようにできます。
{{< alert type="note" >}}
GitLab管理者は、この設定を[無効](../../administration/settings/account_and_limit_settings.md#prevent-users-from-making-their-profiles-private)にして、すべてのプロファイルを強制的に公開できます。
{{< /alert >}}
プロファイルを非公開にするには:
1. 左側のサイドバーで、アバターを選択します。
1. **プロファイルを編集**を選択します。
1. **プライベートプロファイル**チェックボックスをオンにします。
1. **プロファイル設定を更新**を選択します。
以下はユーザープロファイルページ（`https://gitlab.example.com/username`）に表示されません。
- Atomフィード
- アカウントの作成日
- アクティビティー、グループ、コントリビュートしたプロジェクト、パーソナルプロジェクト、お気に入りプロジェクト、スニペットのタブ
{{< alert type="note" >}}
ユーザープロファイルページを非公開にしても、RESTまたはGraphQL APIからすべての公開リソースが非表示になるわけではありません。たとえば、[自動生成されたプライベートコミットメールを使用](#use-an-automatically-generated-private-commit-email)しない限り、コミット署名に関連付けられているメールアドレスにアクセスできます。
{{< /alert >}}
### ユーザーの表示レベル
`/username`にあるユーザーの公開ページは、サインインしているかどうかに関係なく、常に表示されます。
ユーザーの公開ページにアクセスすると、権限のあるプロジェクトのみが表示されます。
[公開レベルが制限されている](../../administration/settings/visibility_and_access_controls.md#restrict-visibility-levels)場合、ユーザープロファイルは認証済みユーザーにのみ表示されます。
## READMEでプロファイルに詳細を追加する
READMEファイルを使用して、プロファイルページに詳細情報を追加できます。READMEファイルに情報を入力すると、その情報がプロファイルページに表示されます。
### 新規プロジェクトから
新しいプロジェクトを作成し、そのREADMEをプロファイルに追加するには:
1. 左側のサイドバーの上部で、**新規作成**（{{< icon name="plus" >}}）を選択し、**新しいプロジェクト/リポジトリ**を選択します。
1. **空のプロジェクトの作成**を選択します。
1. プロジェクトの詳細を入力します。
- **プロジェクト名**フィールドに、新しいプロジェクトの名前を入力します。
- **プロジェクトURL**フィールドで、自分のGitLabユーザー名を選択します。
- **プロジェクトslug**フィールドに、自分のGitLabユーザー名を入力します。これらのフィールドはすべて大文字と小文字が区別されます。ユーザー名に大文字が含まれている場合は、大文字を含めてプロジェクトslugフィールドに入力します。
1. **表示レベル**で、**公開**を選択します。![ホストされた製品の個人プロジェクトの適切なパス](img/personal_readme_setup_v14_5.png)
1. **プロジェクトの設定**で、**リポジトリを初期化しREADMEファイルを生成する**が選択されていることを確認します。
1. **プロジェクトを作成**を選択します。
1. このプロジェクト内にREADMEファイルを作成します。ファイルは、有効な[READMEファイルまたはインデックスファイル](../project/repository/files/_index.md#readme-and-index-files)にすることができます。
1. READMEファイルに[Markdown](../markdown.md)またはその他の[サポートされているマークアップ言語](../project/repository/files/_index.md#supported-markup-languages)を入力します。
GitLabは、コントリビューショングラフの下にREADMEの内容を表示します。
### 既存のプロジェクトから
既存のプロジェクトからREADMEをプロファイルに追加するには、プロジェクトの[パスを更新](../project/working_with_projects.md#rename-a-repository)して、ユーザー名と一致するようにします。
## 外部アカウントをユーザープロファイルページに追加する
{{< history >}}
- GitLab 16.6で、`mastodon_social_ui`という名前の[フラグとともに](../feature_flags.md)Mastodonユーザーアカウントが[導入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/132892)されました。デフォルトでは無効になっています。
- GitLab 16.7で、Mastodonユーザーアカウントが[一般提供](https://gitlab.com/gitlab-org/gitlab/-/issues/428163)になりました。機能フラグ`mastodon_social_ui`が削除されました。
- GitLab 17.4で、`verify_mastodon_user`という名前の[フラグとともに](../feature_flags.md)、GitLabユーザープロファイルを使用してMastodonアカウントを確認する機能が[追加](https://gitlab.com/gitlab-org/gitlab/-/issues/433391)されました。デフォルトでは無効になっています。
{{< /history >}}
SkypeやX（旧Twitter）など、他の特定の外部アカウントへのリンクを追加できます。他のユーザーが他のプラットフォームであなたとつながるのに役立ちます。
他のアカウントへのリンクを追加するには:
1. 左側のサイドバーで、アバターを選択します。
1. **プロファイルを編集**を選択します。
1. **主要設定**セクションで、以下を追加します。
- Discordの[ユーザーID](https://support.discord.com/hc/en-us/articles/206346498-Where-can-I-find-my-User-Server-Message-ID-)。
- LinkedInのプロフィール名。
- Blueskyの[did:plc識別子](https://atproto.com/specs/did)。識別子を検索するには、[ユーザーハンドルを解決](https://bsky.social/xrpc/com.atproto.identity.resolveHandle?handle=USER_HANDLE)します。
- Mastodonハンドル。GitLab 17.4以降では、[GitLabプロファイル](#access-your-user-profile)を使用してMastodonアカウントを確認できます。
- Skypeのユーザー名。
- X（旧Twitter）の@ユーザー名。
ユーザーIDまたはユーザー名は500文字以下である必要があります。
1. **プロファイル設定を更新**を選択します。
## ユーザープロファイルページにプライベートコントリビュートを表示する
ユーザーコントリビュートカレンダーグラフと最近のアクティビティーリストでは、プライベートプロジェクトに対する[コントリビュートアクション](contributions_calendar.md#user-contribution-events)を確認できます。
プライベートコントリビュートを表示するには:
1. 左側のサイドバーで、アバターを選択します。
1. **プロファイルを編集**を選択します。
1. **主要設定**セクションで、**プロファイルにプライベートコントリビュートを含める**チェックボックスをオンにします。
1. **プロファイル設定を更新**を選択します。
## ジェンダー代名詞を追加する
GitLabアカウントにジェンダー代名詞を追加して、プロファイルの名前の横に表示できます。
ジェンダー代名詞を指定するには:
1. 左側のサイドバーで、アバターを選択します。
1. **プロファイルを編集**を選択します。
1. **ジェンダー代名詞**テキストボックスに、自分のジェンダー代名詞を入力します。テキストは50文字以下である必要があります。
1. **プロファイル設定を更新**を選択します。
## 名前の発音を追加する
GitLabアカウントに名前の発音を追加できます。これは、プロファイルの名前の下に表示されます。
名前の発音を追加するには:
1. 左側のサイドバーで、アバターを選択します。
1. **プロファイルを編集**を選択します。
1. **発音**テキストボックスに、名前の発音方法を入力します。発音は、プレーンテキストで255文字以下である必要があります。
1. **プロファイル設定を更新**を選択します。
## ステータスを設定する
ステータスを設定して、他のユーザーに自分の状況を知らせます。他のユーザーは、アバター、名前、またはユーザー名にカーソルをおくと、ステータスを確認できます。[ユーザープロファイルページを非公開](#make-your-user-profile-page-private)にした場合でも、ステータスは公開されます。
ステータスは、以下の要素で構成されています。それぞれを個別に使用して、ステータスを示すことができます。
- ステータスを示す絵文字。
- 空き状況を説明するメッセージ。`:palm_tree:`や`:bulb:`のような絵文字コードを含めることができます。最大100文字。
- `Busy`バッジをステータスに追加するチェックボックス。
現在のステータスを設定するには:
1. 左側のサイドバーで、アバターを選択します。
1. **ステータスの設定**を選択します。以前にステータスを設定した場合は、代わりに**状態を編集**を選択します。
1. オプション: ステータスメッセージを入力します。
1. オプション: **ビジーに設定する**チェックボックスをオンにします。
1. オプション: **次の期間でステータスを初期化する**ドロップダウンリストから値を選択します。
1. **ステータスの設定**を選択します。
ステータスが更新されます。[ユーザー設定](#access-your-user-settings)ページまたは[ユーザーAPI](../../api/users.md#set-your-user-status)からステータスを設定することもできます。
## タイムゾーンを設定する
ローカルタイムゾーンを設定すると、次のことができます。
- プロファイルや、名前の上にカーソルをおくと情報が表示される場所に、自分のローカル時間を表示できます。
- コントリビュートカレンダーをローカル時間に合わせ、コントリビュートした時間をより正確に反映できます。
タイムゾーンを設定するには:
1. 左側のサイドバーで、アバターを選択します。
1. **プロファイルを編集**を選択します。
1. **タイムゾーンの設定**セクションで、ドロップダウンリストからタイムゾーンを選択します。
## コミットに表示されるメールアドレスを変更する
コミットメールとは、GitLabインターフェースを通じて実行されるすべてのGit関連アクションに表示されるメールアドレスです。
自分で確認したメールアドレスはすべて、コミットメールとして使用できます。デフォルトでは、プライマリメールが使用されます。
コミットメールを変更するには:
1. 左側のサイドバーで、アバターを選択します。
1. **プロファイルを編集**を選択します。
1. **コミットメール**ドロップダウンリストで、メールアドレスを選択します。
1. **プロファイル設定を更新**を選択します。
## プライマリメールアドレスを変更する
プライマリメールは、ログイン、コミットメール、通知メールのデフォルトメールアドレスです。
プライマリメールを変更するには:
1. 左側のサイドバーで、アバターを選択します。
1. **プロファイルを編集**を選択します。
1. **メール**フィールドに、新しいメールアドレスを入力します。
1. **プロファイル設定を更新**を選択します。
1. オプション: 以前にこのメールをGitLab.comアカウントに追加していない場合は、確認メールを選択します。
## 公開メールを設定する
公開プロファイルに表示する[設定済みのメールアドレス](#add-emails-to-your-user-profile)を1つ選択できます。
1. 左側のサイドバーで、アバターを選択します。
1. **プロファイルを編集**を選択します。
1. **公開メール**フィールドで、利用可能なメールアドレスを1つ選択します。
1. **プロファイル設定を更新**を選択します。
### 自動生成されたプライベートコミットメールを使用する
GitLabは、自動生成されたプライベートコミットメールアドレスを提供するため、メール情報を非公開にすることができます。
プライベートコミットメールを使用するには:
1. 左側のサイドバーで、アバターを選択します。
1. **プロファイルを編集**を選択します。
1. **コミットメール**ドロップダウンリストで、**プライベートメールを使用する**を選択します。
1. **プロファイル設定を更新**を選択します。
すべてのGit関連のアクションは、プライベートコミットメールを使用します。
完全に匿名性を保つために、次のコマンドを実行して、プライベートコミットメールをコピーし、ローカルマシンで設定することもできます。
```shell
git config --global user.email <your email address>
```
## ユーザーをフォローする
次のいずれかから、ユーザーをフォローまたはフォロー解除できます。
- 自分の[ユーザープロファイル](#access-your-user-profile)
- ユーザー名にカーソルをおくと表示される小さなポップオーバー（GitLab 15.0で[導入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/76050)）
[GitLab 15.5以降](https://gitlab.com/gitlab-org/gitlab/-/issues/360755)では、フォローできるユーザーの最大数は300人です。
[GitLab 16.10以降](https://gitlab.com/gitlab-org/gitlab/-/issues/441774)では、ブロックされたユーザーはユーザープロファイルのフォロワーリストに表示されません。
### 他のユーザーのフォローと他のユーザーからのフォローを無効にする
{{< history >}}
- GitLab 16.0で、`disable_follow_users`という名前の[フラグとともに](../feature_flags.md)[導入](https://gitlab.com/gitlab-org/gitlab/-/issues/325558)されました。
- GitLab 16.3で、[機能フラグが削除](https://gitlab.com/gitlab-org/gitlab/-/issues/420620)されました。
{{< /history >}}
他のユーザーのフォローと他のユーザーからのフォローを無効にできます。
1. 左側のサイドバーで、アバターを選択します。
1. **プロファイルを編集**を選択します。
1. **設定**を選択します。
1. **ユーザーのフォローを有効にする**チェックボックスをオフにします。
1. **変更の保存**を選択します。
{{< alert type="note" >}}
この機能を無効にすると、現在フォローしている/フォローされているすべての接続が削除されます。
{{< /alert >}}
## ユーザーのアクティビティーを表示する
GitLabは、[ユーザーのコントリビュートアクティビティー](contributions_calendar.md)を追跡します。ユーザーのアクティビティーを表示するには:
1. ユーザーのプロフィールに移動します。
1. GitLabメニューで、**アクティビティー**を選択します。
**最新のアクティビティー**コントリビュートのリストが表示されます。
## 自分のアクティビティーを表示する
自分のアクティビティーを表示するには:
1. 左側のサイドバーで、**検索または移動**を選択します。
1. **あなたの作業**を選択します。
1. **アクティビティー**を選択します。
1. オプション: コントリビュートの種類でアクティビティーをフィルタリングするには、**あなたのアクティビティー**タブで、次のタブを選択します。
- **すべて**: グループとプロジェクトで行ったすべてのコントリビュート。
- **プッシュイベント**: プロジェクトで行ったプッシュイベント。
- **マージイベント**: プロジェクトで承認したマージリクエスト。
- **イシューイベント**: プロジェクトでオープンおよびクローズしたイシュー。
- **コメント**: プロジェクトに投稿したコメント。
- **Wiki**: プロジェクトで作成および更新したWikiページ。
- **デザイン**: プロジェクトで追加、更新、および削除したデザイン。
- **チーム**: 参加および離脱したプロジェクト。
## サービスにサインインする
GitLabにサインインするために、通常のユーザー名とパスワードを使用する代わりに、サインインサービスを使用できます。
### サインインサービスを接続する
GitLabへのサインインに使用するサインインサービスを接続するには:
1. 左側のサイドバーで、アバターを選択します。
1. **プロファイルを編集**を選択します。
1. **アカウント**を選択します。
1. **サインインに利用するサービス**セクションを探します。
1. **接続したアカウント**セクションで、サインインするサービスに対応するボタンを選択します。
1. 選択したサービスの手順に従って、サインインを開始します。
### サインインサービスを切断する
GitLabへのサインインに使用されるサインインサービスを切断するには:
1. 左側のサイドバーで、アバターを選択します。
1. **プロファイルを編集**を選択します。
1. **アカウント**を選択します。
1. **サインインに利用するサービス**セクションを探します。
1. **接続したアカウント**セクションで、サインインしたくないサービスに対応するボタンの横にある**切断**を選択します。
## セッションの継続時間
### 2週間サインインしたままにする
デフォルトでは、GitLabからサインアウトするのは、無効な状態が7日間（10080分）続いた後か、ブラウザウィンドウを閉じるかのいずれか早い方です。
GitLab管理者は[このデフォルトを変更](../../administration/settings/account_and_limit_settings.md#customize-the-default-session-duration)できます。
### 無期限にサインインしたままにする
{{< history >}}
- GitLab 16.0で、**ログイン情報を記憶する**設定をオン/オフにする機能が[導入](https://gitlab.com/gitlab-org/gitlab/-/issues/369133)されました。
{{< /history >}}
無期限にサインインしたままにするには、GitLabサインインページの**ログイン情報を記憶する**チェックボックスをオンにします。
サーバーがセッション時間を1週間に設定していても、ブラウザが自動再認証を可能にするセキュアトークンを保存するため、サインインしたままになります。
セキュリティまたはコンプライアンスの目的でセッションを定期的に期限切れにする必要がある環境では、GitLab管理者が[**ログイン情報を記憶する**設定をオフにする](../../administration/settings/account_and_limit_settings.md#session-duration)ことができます。
### サインインに使用されるCookie
サインインすると、次の3つのCookieが設定されます。
- `_gitlab_session`というセッションCookie: このCookieには、設定された有効期限はありません。ただし、`session_expire_delay`に基づいて有効期限切れになります。
- `gitlab_user`というセッションCookie: このCookieは、ユーザーにアクティブなGitLabセッションがあるかどうかを判断するために、[マーケティングサイト](https://about.gitlab.com/)で使用されます。ユーザー情報はCookieに渡されず、ログインから2週間後に有効期限切れになります。
- `remember_user_token`という永続Cookie: これは、サインインページで**ログイン情報を記憶する**を選択した場合にのみ設定されます。
ブラウザを閉じると、通常、`_gitlab_session`および`gitlab_user` Cookieはクライアント側でクリアされます。有効期限切れになったり利用できなくなったりすると、GitLabは次のようになります。
- `remember_user_token` Cookieを使用して新しい`_gitlab_session` Cookieを取得し、ブラウザを閉じてもサインインしたままにします。
- `gitlab_user`を`true`に設定します。
`remember_user_token`と`_gitlab_session` Cookieの両方がなくなったか、有効期限切れになると、再度サインインする必要があります。
{{< alert type="note" >}}
セッションがサインアウトされた場合、または[アクティブなセッションリスト](active_sessions.md)からセッションが取り消された場合、すべての**ログイン情報を記憶する**トークンが取り消されます。他のセッションがアクティブなまま、ブラウザが閉じられたり、既存のセッションが有効期限切れになったりすると、**ログイン情報を記憶する**機能でセッションは復元されません。
{{< /alert >}}
## 関連トピック
- [ユーザーを作成する](account/create_accounts.md)
- [GitLabアカウントにサインインする](../../administration/auth/_index.md)
- [パスワードを変更する](user_passwords.md)
- 次のメールを受信します。
- [不明なIPアドレスまたはデバイスからのサインイン](notifications.md#notifications-for-unknown-sign-ins)
- [不正確な確認コードを使用したサインインの試行](notifications.md#notifications-for-attempted-sign-ins-using-incorrect-verification-codes)
- [GitLabをOAuthプロバイダーとして使用](../../integration/oauth_provider.md)できるアプリケーションを管理する
- APIおよび承認されたアプリケーションを介してアカウントにアクセスするための[パーソナルアクセストークン](personal_access_tokens.md)を管理する
- SSHを使用してアカウントにアクセスするための[SSH鍵](../ssh.md)を管理する
- [ハイライトした構文のテーマを変更する](preferences.md#change-the-syntax-highlighting-theme)
- [アクティブなセッションを表示](active_sessions.md)して必要に応じていずれかを取り消す

122
doc-locale/ja-jp/user/project/codeowners/_index.md Normal file
View File

@ -0,0 +1,122 @@
---
stage: Create
group: Source Code
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
description: Use Code Owners to define experts for your code base, and set review requirements based on file type or location.
title: コードオーナー
---
{{< details >}}
- プラン: Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
{{< /details >}}
コードオーナー機能を使用すると、プロジェクトのコードベースの特定の部分に関する専門知識を持つ担当者を定義できます。リポジトリ内のファイルとディレクトリのオーナーを定義して、以下を行います。
- **オーナーに変更の承認を求めます。**保護ブランチとコードオーナーを組み合わせて、エキスパートが保護ブランチにマージリクエストをマージする前に承認するよう要求します。詳細については、「[コードオーナーと保護ブランチ](#code-owners-and-protected-branches)」を参照してください。
- **オーナーを特定します。**コードオーナーの名前は、所有するファイルとディレクトリに表示されます。
![UIに表示されるコードオーナー](../img/codeowners_in_UI_v15_10.png)
## コードオーナーと承認ルール
コードオーナーとマージリクエストの[承認ルール](../merge_requests/approvals/rules.md)（オプションまたは必須）を組み合わせて柔軟な承認ワークフローをビルドします。
- **コードオーナー**を使用して、品質を確保します。リポジトリ内の特定のパスについて、ドメインの専門知識を持つユーザーを定義します。
- **承認ルール**を使用して、リポジトリ内の特定のファイルパスに対応しない専門分野を定義します。承認ルールは、マージリクエストの作成者が、フロントエンドデベロッパーやセキュリティチームなど、適切なレビュアーを決定するのに役立ちます。
次に例を示します。
| タイプ | 名前 | スコープ | コメント |
|------|------|--------|------------|
| 承認ルール | ユーザーエクスペリエンス | すべてのファイル | ユーザーエクスペリエンス（UX）チームのメンバーが、プロジェクトで行われたすべての変更のユーザーエクスペリエンスをレビューします。 |
| 承認ルール | セキュリティ | すべてのファイル | セキュリティチームのメンバーが、すべての変更に脆弱性がないかレビューします。 |
| コードオーナーの承認ルール | フロントエンド:コードスタイル | `*.css`ファイル | フロントエンドエンジニアが、プロジェクトのスタイル標準への準拠について、CSSファイルへの変更をレビューします。 |
| コードオーナーの承認ルール | バックエンド:コードレビュー | `*.rb`ファイル | バックエンドエンジニアが、Rubyファイルのロジックとコードスタイルをレビューします。 |
<div class="video-fallback">
ビデオによる紹介: <a href="https://www.youtube.com/watch?v=RoyBySTUSB0">Code Owners</a>（コードオーナー）。
</div>
<figure class="video-container">
<iframe src="https://www.youtube-nocookie.com/embed/RoyBySTUSB0" frameborder="0" allowfullscreen></iframe>
</figure>
## コードオーナーと保護ブランチ
[`CODEOWNERS`ファイル](#codeowners-file)で指定されたコードオーナーがマージリクエストの変更をレビューおよび承認するようにするには、マージリクエストのターゲットブランチを[保護](../repository/branches/protected.md)し、[コードオーナーの承認](../repository/branches/protected.md#require-code-owner-approval-on-a-protected-branch)が有効になっている必要があります。
保護ブランチでコードオーナーの承認を有効にすると、次の機能が利用可能になります。
- [コードオーナーからの承認を必須にする](../repository/branches/protected.md#require-code-owner-approval-on-a-protected-branch)。
- [コードオーナーからの複数承認を必須にする](advanced.md#require-multiple-approvals-from-code-owners)。
- [コードオーナーからの承認を任意にする](reference.md#optional-sections)。
### 実践的な例
プロジェクトでは、`config/`ディレクトリに機密情報と重要な情報が含まれています。以下を実行できます。
1. ディレクトリの所有権を割り当てます。これを行うには、`CODEOWNERS`を設定します。
1. デフォルトブランチの保護ブランチを作成します。たとえば、`main`などです。
1. 保護ブランチで**コードオーナーからの承認を必須にする**を有効にします。
1. オプション: `CODEOWNERS`ファイルを編集して、複数承認のルールを追加します。
この設定では、`config/`ディレクトリ内のファイルを変更し、`main`ブランチをターゲットにするマージリクエストには、マージする前に指定されたコードオーナーからの承認が必要です。
## ファイルまたはディレクトリのコードオーナーを表示する
ファイルまたはディレクトリのコードオーナーを表示するには:
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトを検索します。
1. **コード>リポジトリ**を選択します。
1. コードオーナーを表示するファイルまたはディレクトリに移動します。
1. オプション: ブランチまたはタグを選択します。
GitLabでは、ページの上部にコードオーナーが表示されます。
## コードオーナーを設定する
前提要件:
- デフォルトブランチにプッシュする権限またはマージリクエストを作成する権限が必要です。
1. [推奨される場所](#codeowners-file)に`CODEOWNERS`ファイルを作成します。
1. [`CODEOWNERS`構文](reference.md)に従って、ファイルにいくつかのルールを定義します。次に、いくつかの提案を示します。
- [すべての対象となる承認者](../merge_requests/approvals/rules.md#code-owners-as-eligible-approvers)承認ルールを設定します。
- 保護ブランチで[コードオーナーから承認を必須](../repository/branches/protected.md#require-code-owner-approval-on-a-protected-branch)にします。
1. 変更をコミットし、GitLabにプッシュします。
## `CODEOWNERS`ファイル
`CODEOWNERS`ファイルは、GitLabプロジェクトのコード責任者を定義します。目的は次のとおりです。
- 特定のファイルとディレクトリのコードオーナーを定義する。
- 保護ブランチの承認要件を適用する。
- プロジェクトのコード所有権を伝達する。
このファイルは、誰が変更をレビューおよび承認する必要があるかを決定し、適切な専門家がコードの変更に関与するようにします。
各リポジトリで1つの`CODEOWNERS`ファイルを使用します。GitLabは、リポジトリ内の次の場所をこの順序で確認します。最初に見つかった`CODEOWNERS`ファイルが使用され、その他はすべて無視されます。
1. ルートディレクトリ内: `./CODEOWNERS`。
1. `docs`ディレクトリ内: `./docs/CODEOWNERS`。
1. `.gitlab`ディレクトリ内: `./.gitlab/CODEOWNERS`。
詳細については、「[`CODEOWNERS`構文](reference.md)」と「[高度な`CODEOWNERS`設定](advanced.md)」を参照してください。
## プッシュを許可する
**プッシュを許可**されたユーザーは、変更のマージリクエストを作成するか、変更をブランチに直接プッシュするかを選択できます。ユーザーがマージリクエストプロセスをスキップすると、マージリクエストに組み込まれている保護ブランチ機能とコードオーナーの承認もスキップされます。
この権限は、多くの場合、自動化（[内部ユーザー](../../../administration/internal_users.md)およびリリースツールに関連付けられたアカウントに付与されます。
**プッシュを許可**権限が_ない_ユーザーからの変更はすべて、マージリクエストを介してルーティングする必要があります。
## 関連トピック
- [`CODEOWNERS`構文](reference.md)
- [高度な`CODEOWNERS`設定](advanced.md)
- [開発ガイドライン](../../../development/code_owners/_index.md)
- [保護ブランチ](../repository/branches/protected.md)
- [コードオーナーのトラブルシューティング](troubleshooting.md)

226
doc-locale/ja-jp/user/project/deploy_tokens/_index.md Normal file
View File

@ -0,0 +1,226 @@
---
stage: Deploy
group: Environments
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: デプロイトークン
---
{{< details >}}
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
{{< /details >}}
デプロイトークンを使用すると、個々のユーザーアカウントに権限を関連付けなくても、GitLabリソースへの安全なアクセスを提供できます。Git操作、コンテナレジストリ、パッケージレジストリで使用すると、デプロイの自動化に必要なものだけにアクセスできます。
デプロイトークンを使用すると、以下を実現できます。
- 自動化システムから個人の認証情報を削除することで、デプロイの安全性を向上
- トークンごとに特定の権限を付与して、きめ細かいアクセス制御を実現
- 組み込みの認証変数を使用して、CI/CDパイプラインを簡素化
- チームメンバーが変更された場合でも中断されない信頼性の高いデプロイメントプロセスを実現
- 専用のトークンIDでデプロイを追跡することで、監査証跡を改善
- 外部ビルドシステムおよびデプロイメントツールとシームレスに統合
デプロイトークンは、次の値のペアです。
- **username**: HTTP認証フレームワークの`username`。デフォルトのユーザー名の形式は`gitlab+deploy-token-{n}`です。デプロイトークンの作成時に、カスタムユーザー名を指定できます。
- **token**: HTTP認証フレームワークの`password`。
デプロイトークンは、[SSH認証](../../ssh.md)をサポートしていません。
次のエンドポイントへの[HTTP認証](https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication)にデプロイトークンを使用できます。
- GitLabパッケージレジストリパブリックAPI。
- [Gitコマンド](https://git-scm.com/docs/gitcredentials#_description)。
プロジェクトまたはグループレベルでデプロイトークンを作成できます。
- **プロジェクトデプロイトークン**: 権限はプロジェクトにのみ適用されます。
- **グループデプロイトークン**: 権限はグループ内のすべてのプロジェクトに適用されます。
デフォルトでは、デプロイトークンは期限切れになりません。オプションで、作成時に有効期限を設定できます。有効期限は、その日付のUTC午前0時に切れます。
{{< alert type="warning" >}}
[外部認証](../../../administration/settings/external_authorization.md)が有効になっている場合、Git操作およびパッケージレジストリ操作に新規または既存のデプロイトークンを使用することはできません。
{{< /alert >}}
## スコープ
デプロイトークンのスコープによって、実行できるアクションが決まります。
| スコープ | 説明 |
|--------------------------|--------------------------------------------------------------------------------------------------------------|
| `read_repository` | `git clone`を使用したリポジトリへの読み取り専用アクセス。 |
| `read_registry` | プロジェクトの[コンテナレジストリ](../../packages/container_registry/_index.md)内のイメージへの読み取り専用アクセス。 |
| `write_registry` | プロジェクトの[コンテナレジストリ](../../packages/container_registry/_index.md)への書き込みアクセス（プッシュ）。イメージをプッシュするには、読み取りアクセスと書き込みアクセスの両方が必要です。 |
| `read_package_registry` | プロジェクトのパッケージレジストリへの読み取り専用アクセス。 |
| `write_package_registry` | プロジェクトのパッケージレジストリへの書き込みアクセス。 |
## GitLabデプロイトークン
{{< history >}}
- GitLab 15.1で、`ci_variable_for_group_gitlab_deploy_token`という名前の[フラグとともに](../../../administration/feature_flags.md)グループレベルでの`gitlab-deploy-token`のサポートが[導入](https://gitlab.com/gitlab-org/gitlab/-/issues/214014)されました。デフォルトで有効になりました。
- GitLab 15.4で、[機能フラグ`ci_variable_for_group_gitlab_deploy_token`](https://gitlab.com/gitlab-org/gitlab/-/issues/363621)が削除されました。
{{< /history >}}
GitLabデプロイトークンは、特別なタイプのデプロイトークンです。`gitlab-deploy-token`という名前のデプロイトークンを作成すると、そのデプロイトークンは自動的に次の変数としてプロジェクトCI/CDジョブに公開されます。
- `CI_DEPLOY_USER`: ユーザー名
- `CI_DEPLOY_PASSWORD`: トークン
たとえば、GitLabトークンを使用してGitLabコンテナレジストリにサインインするには、次のコマンドを実行します。
```shell
echo "$CI_DEPLOY_PASSWORD" | docker login $CI_REGISTRY -u $CI_DEPLOY_USER --password-stdin
```
{{< alert type="note" >}}
GitLab 15.0以前では、`gitlab-deploy-token`デプロイトークンに対する特別な処理はグループデプロイトークンでは機能しません。グループデプロイトークンをCI/CDジョブで使用できるようにするには、**設定> CI/CD >変数**で`CI_DEPLOY_USER`および`CI_DEPLOY_PASSWORD`のCI/CD変数をグループデプロイトークンの名前とトークンに設定します。
{{< /alert >}}
グループで`gitlab-deploy-token`が定義されている場合、`CI_DEPLOY_USER`および`CI_DEPLOY_PASSWORD`のCI/CD変数はグループ直下の子プロジェクトでのみ使用できます。
### GitLabデプロイトークンのセキュリティ
GitLabデプロイトークンは有効期間が長いため、攻撃者にとって魅力的です。
デプロイトークンの漏えいを防ぐために、[Runner](../../../ci/runners/_index.md)も安全に設定する必要があります。
- マシンが再利用される場合は、Docker `privileged`モードの使用を避ける必要があります。
- ジョブが同じマシンで実行される場合は、[`shell` executor](https://docs.gitlab.com/runner/executors/shell.html)の使用を避ける必要があります。
脆弱なGitLab Runner設定は、他のジョブからのトークンの盗難リスクを増大させます。
### GitLabパブリックAPI
デプロイトークンは、GitLabパブリックAPIでは使用できません。ただし、パッケージレジストリのエンドポイントなど、一部のエンドポイントではデプロイトークンを使用できます。URLに文字列`packages/<format>`が含まれていると、エンドポイントがパッケージレジストリに属していると判断できます。例: `https://gitlab.example.com/api/v4/projects/24/packages/generic/my_package/0.0.1/file.txt`。詳細については、「[レジストリを使用して認証する](../../packages/package_registry/_index.md#authenticate-with-the-registry)」を参照してください。
## デプロイトークンを作成する
ユーザーアカウントとは独立して実行できるデプロイタスクを自動化するためのデプロイトークンを作成します。
前提要件:
- グループデプロイトークンを作成するには、グループのオーナーロールが必要です。
- プロジェクトデプロイトークンを作成するには、プロジェクトのメンテナーロール以上が必要です。
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトまたはグループを検索します。
1. **設定>リポジトリ**を選択します。
1. **デプロイトークン**を展開します。
1. **トークンの追加**を選択します。
1. フィールドに入力し、目的の[スコープ](#scope)を選択します。
1. **デプロイトークンを作成**を選択します。
デプロイトークンの値を記録します。ページを離れるか更新すると、**再度アクセスすることはできません**。
## デプロイトークンを取り消す
不要になったトークンを取り消します。
前提要件:
- グループデプロイトークンを取り消すには、グループのオーナーロールが必要です。
- プロジェクトデプロイトークンを取り消すには、プロジェクトのメンテナーロール以上が必要です。
デプロイトークンを取り消すには:
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトまたはグループを検索します。
1. **設定>リポジトリ**を選択します。
1. **デプロイトークン**を展開します。
1. **アクティブなデプロイトークン**セクションで、取り消すトークンの横にある**取り消し**を選択します。
## リポジトリのクローンを作成する
デプロイトークンを使用してリポジトリのクローンを作成できます。
前提要件:
- `read_repository`スコープを持つデプロイトークン。
デプロイトークンを使用してリポジトリのクローンを作成する例:
```shell
git clone https://<username>:<deploy_token>@gitlab.example.com/tanuki/awesome_project.git
```
## コンテナレジストリからイメージをプルする
デプロイトークンを使用して、コンテナレジストリからイメージをプルできます。
前提要件:
- `read_registry`スコープを持つデプロイトークン。
デプロイトークンを使用してコンテナレジストリからイメージをプルする例:
```shell
echo "$DEPLOY_TOKEN" | docker login -u <username> --password-stdin registry.example.com
docker pull $CONTAINER_TEST_IMAGE
```
## コンテナレジストリにイメージをプッシュする
デプロイトークンを使用して、コンテナレジストリにイメージをプッシュできます。
前提要件:
- `read_registry`および`write_registry`のスコープを持つデプロイトークン。
デプロイトークンを使用して、コンテナレジストリにイメージをプッシュする例:
```shell
echo "$DEPLOY_TOKEN" | docker login -u <username> --password-stdin registry.example.com
docker push $CONTAINER_TEST_IMAGE
```
## パッケージレジストリからパッケージをプルする
デプロイトークンを使用して、パッケージレジストリからパッケージをプルできます。
前提要件:
- `read_package_registry`スコープを持つデプロイトークン。
[選択するパッケージの種類](../../packages/package_registry/supported_functionality.md#authentication-tokens)については、デプロイトークンの認証手順に従ってください。
GitLabレジストリからNuGetパッケージをインストールする例:
```shell
nuget source Add -Name GitLab -Source "https://gitlab.example.com/api/v4/projects/10/packages/nuget/index.json" -UserName <username> -Password <deploy_token>
nuget install mypkg.nupkg
```
## パッケージレジストリにパッケージをプッシュする
デプロイトークンを使用して、GitLabパッケージレジストリにパッケージをプッシュできます。
前提要件:
- `write_package_registry`スコープを持つデプロイトークン。
[選択するパッケージの種類](../../packages/package_registry/supported_functionality.md#authentication-tokens)については、デプロイトークンの認証手順に従ってください。
パッケージレジストリにNuGetパッケージを公開する例:
```shell
nuget source Add -Name GitLab -Source "https://gitlab.example.com/api/v4/projects/10/packages/nuget/index.json" -UserName <username> -Password <deploy_token>
nuget push mypkg.nupkg -Source GitLab
```
## 依存プロキシからイメージをプルする
デプロイトークンを使用して、依存プロキシからイメージをプルできます。
前提要件:
- `read_registry`および`write_registry`のスコープを持つデプロイトークン。
依存プロキシの[認証手順](../../packages/dependency_proxy/_index.md)に従ってください。

347
doc-locale/ja-jp/user/project/members/_index.md Normal file
View File

@ -0,0 +1,347 @@
---
stage: Tenant Scale
group: Organizations
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: プロジェクトのメンバー
---
{{< details >}}
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
{{< /details >}}
メンバーとは、プロジェクトへのアクセス権を持つユーザーとグループのことです。メンバーは、プロジェクトに直接追加することも、グループを通じてアクセス権を継承することもできます。
各メンバーは、プロジェクトで何ができるかを決定するロールを持っています。適切なロールを持つプロジェクトメンバーは、プロジェクトにユーザーを追加したり、プロジェクトからユーザーを削除したり、アクセスリクエストを管理してプロジェクトリソースへのアクセスを制御したりできます。
## メンバーシップの種類
{{< history >}}
- GitLab 16.10で、`webui_members_inherited_users`という名前の[フラグ](../../../administration/feature_flags.md)とともに、招待されたグループメンバーをメンバーページのメンバータブに表示するように[変更](https://gitlab.com/gitlab-org/gitlab/-/issues/219230)されました。デフォルトでは無効になっています。
- GitLab 17.0の[GitLab.comとGitLab Self-Managedで機能フラグ`webui_members_inherited_users`が有効](https://gitlab.com/gitlab-org/gitlab/-/issues/219230)になりました。
- GitLab 17.4で、機能フラグ`webui_members_inherited_users`が[削除](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/163627)されました。招待されたグループのメンバーは、デフォルトで表示されます。
{{< /history >}}
ユーザーは、グループまたはプロジェクトのメンバーに直接的または間接的になることができます。間接的なメンバーシップは、継承、共有、または継承共有される可能性があります。
| メンバーシップの種類 | メンバーシップのプロセス |
| --------------------------------------------- | ------------------ |
| 直接 | ユーザーは、現在のグループまたはプロジェクトに直接追加されます。 |
| 継承 | ユーザーは、現在のグループまたはプロジェクトを含む親グループのメンバーです。 |
| [共有](sharing_projects_groups.md) | ユーザーは、現在のグループまたはプロジェクトに招待されたグループのメンバーです。 |
| [継承共有](sharing_projects_groups.md#invite-a-group-to-a-group) | ユーザーは、現在のグループまたはプロジェクトの祖先に招待されたグループのメンバーです。 |
| 間接 | 継承メンバー、共有メンバー、または継承共有メンバーを指す包括的な用語です。 |
```mermaid
%%{init: { "fontFamily": "GitLab Sans" }}%%
flowchart RL
accTitle: Membership types
accDescr: Describes membership types and their inheritance
subgraph Group A
A(Direct member)
B{{Shared member}}
subgraph Project X
H(Direct member)
C{{Inherited member}}
D{{Inherited shared member}}
E{{Shared member}}
end
A-->|Inherited membership in Project X\nDirect membership in Group A|C
end
subgraph Group C
G(Direct member)
end
subgraph Group B
F(Direct member)
end
F-->|Group B\ninvited to\nGroup A|B
B-->|Inherited membership in Project X\nIndirect membership in Group A|D
G-->|Group C invited to Project X|E
```
![プロジェクトメンバーページ](img/project_members_v17_4.png)
上記の例では、次のようになります。
- **管理者**は、**demo**グループからの継承メンバーです。
- **ユーザー0**は、**demo**グループからの継承メンバーです。
- **ユーザー1**は、このプロジェクトに招待された**Acme**グループからの共有メンバーです。
- **ユーザー2**は、**demo**グループに招待された**Toolbox**グループからの継承共有メンバーです。
- **ユーザー3**は、このプロジェクトに追加された直接メンバーです。
## プロジェクトにユーザーを追加する
{{< history >}}
- GitLab 16.2で、期限切れになるアクセス権に関するメール通知が[導入](https://gitlab.com/gitlab-org/gitlab/-/issues/12704)されました。
- GitLab 17.4で、サブグループおよびプロジェクトの直接メンバーのアクセス権の有効期限が[削除](https://gitlab.com/gitlab-org/gitlab/-/issues/471051)されました。
{{< /history >}}
ユーザーをプロジェクトに追加して直接メンバーにし、アクションを実行する権限を与えます。
前提要件:
- オーナーまたはメンテナーのロールを持っている必要があります。
- [グループメンバーシップのロック](../../group/access_and_permissions.md#prevent-members-from-being-added-to-projects-in-a-group)を無効にする必要があります。
- [サインアップが無効になっている](../../../administration/settings/sign_up_restrictions.md#disable-new-sign-ups)場合は、管理者が最初にメールでユーザーを追加する必要があります。
- [ロールの昇格に対する承認](../../../administration/settings/sign_up_restrictions.md#turn-on-administrator-approval-for-role-promotions)が有効になっている場合は、管理者が招待を承認する必要があります。
プロジェクトにユーザーを追加するには:
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトを検索します。
1. **管理>メンバー**を選択します。
1. **メンバーを招待**を選択します。
1. ユーザーは次の操作を行います。
- GitLabアカウントを持っている場合は、ユーザー名を入力します。
- GitLabアカウントを持っていない場合は、メールアドレスを入力します。
1. [デフォルトロール](../../permissions.md)または[カスタムロール](../../custom_roles/_index.md)を選択します。
1. オプション: **アクセス権の有効期限**を選択します。その日付以降、ユーザーはプロジェクトにアクセスできなくなります。
アクセス権の有効期限を選択した場合、プロジェクトメンバーには、アクセス権の有効期限が切れる7日前にメール通知が送信されます。
{{< alert type="warning" >}}
メンテナーは、自分のアクセス権の有効期限を延長する機能を含め、ロールの有効期限が切れるまで完全な権限を持ちます。
{{< /alert >}}
1. **招待**を選択します。次のようになります。
- GitLabユーザー名を使用した場合は、メンバーリストに追加されます。
- メールアドレスを使用した場合は、招待状がメールアドレスに送信され、アカウントを作成するように求められます。招待が承認されない場合、GitLabは2日後、5日後、および10日後にリマインダーメールを送信します。未承認の招待は、90日後に自動的に削除されます。
### 割り当てることができるロール
割り当てることができる最大のロールは、グループのオーナーロールまたはメンテナーロールを持っているかどうかによって異なります。たとえば、設定できる最大のロールは次のとおりです。
- プロジェクトのオーナーロールを持っている場合は、オーナー（`50`）。
- プロジェクトのメンテナーロールを持っている場合は、メンテナー（`40`）。
オーナー[ロール](../../permissions.md#project-members-permissions)は、グループにのみ追加できます。
### 昇格保留中のユーザーを表示する
[ロールの昇格に対する管理者の承認](../../../administration/settings/sign_up_restrictions.md#turn-on-administrator-approval-for-role-promotions)が有効になっている場合は、既存のユーザーを請求可能なロールに昇格するメンバーシップリクエストには、管理者による承認が必要です。
昇格保留中のユーザーを表示するには:
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトを検索します。
1. **管理>メンバー**を選択します。
1. **ロールの昇格**タブを選択します。
**ロールの昇格**タブが表示されない場合、プロジェクトに保留中の昇格はありません。
## 有効期限とロールを更新する
次のようになります。
- プロジェクトの直接メンバーである場合、**有効期限**フィールドと**ロール**フィールドはプロジェクトで直接更新できます。
- 継承メンバー、共有メンバー、または継承共有メンバーである場合、**有効期限**フィールドと**ロール**フィールドは、メンバーの元のグループで更新する必要があります。
## プロジェクトをグループと共有する
ユーザーを1人ずつ追加する代わりに、[プロジェクトをグループ全体と共有](sharing_projects_groups.md)できます。
## 別のプロジェクトからメンバーをインポートする
別のプロジェクトの直接メンバーを自分のプロジェクトにインポートできます。インポートされたプロジェクトメンバーは、インポート元のプロジェクトと同じ権限を保持します。
{{< alert type="note" >}}
プロジェクトの直接メンバーのみがインポートされます。プロジェクトの継承メンバーまたは共有メンバーはインポートされません。
{{< /alert >}}
前提要件:
- メンテナーまたはオーナーのロールを持っている必要があります。
ターゲットプロジェクトに対するインポートメンバーのロールによって、次のようになります。
- メンテナーの場合、ソースプロジェクトのオーナーロールを持つメンバーは、メンテナーロールでインポートされます。
- オーナーの場合、ソースプロジェクトのオーナーロールを持つメンバーは、オーナーロールでインポートされます。
プロジェクトのメンバーをインポートするには:
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトを検索します。
1. **管理>メンバー**を選択します。
1. **プロジェクトからインポート**を選択します。
1. プロジェクトを選択します。自分がメンテナーであるプロジェクトのみ表示できます。
1. **プロジェクトメンバーのインポート**を選択します。
インポートが成功すると、成功メッセージが表示されます。**メンバー**タブにインポートされたメンバーを表示するには、ページを更新します。
## プロジェクトからメンバーを削除する
次のようになります。
- プロジェクトの直接メンバーである場合は、プロジェクトから直接削除できます。
- 親グループからの継承メンバーである場合は、親グループ自体からのみ削除できます。
前提要件:
- 以下のロールを持つ直接メンバーを削除するには:
- メンテナー、デベロッパー、レポーター、プランナー、またはゲストロールの場合は、メンテナーロールを持っている必要があります。
- オーナーロールの場合は、オーナーロールを持っている必要があります。
- オプション: 割り当てられているすべてのイシューとマージリクエストからメンバーの割り当てを解除していること。
プロジェクトからメンバーを削除するには:
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトを検索します。
1. **管理>メンバー**を選択します。
1. 削除するプロジェクトメンバーの横にある**メンバーを削除**を選択します。
1. オプション: 確認ダイアログで、**また、関連するイシューとマージリクエストからこのユーザーのアサインを解除します**チェックボックスをオンにします。
1. プライベートプロジェクトからの機密情報の漏えいを防ぐために、メンバーがプライベートリポジトリをフォークしたり、Webhookを作成したりしていないことを確認してください。既存のフォークはアップストリームプロジェクトからの変更を引き続き受信し、Webhookは更新を引き続き受信します。グループ内のプロジェクトが[グループ外にフォークされない](../../group/access_and_permissions.md#prevent-project-forking-outside-group)ようにプロジェクトを設定することもできます。
1. **メンバーを削除**を選択します。
## 削除されたユーザーが自分自身を再度招待できないようにする
メンテナーまたはオーナーロールを持つユーザーは、管理者が削除した後、グループまたはプロジェクトに再参加できる競合条件を悪用する可能性があります。
この問題を回避するために、GitLab管理者は以下を実行できます。
- [GitLab Railsコンソール](../../../administration/operations/rails_console.md)から悪意のあるユーザーセッションを削除します。
- 悪意のあるユーザーになりすまして、以下を行います。
- プロジェクトからユーザーを削除します。
- GitLabからユーザーをログアウトします。
- 悪意のあるユーザーアカウントをブロックします。
- 悪意のあるユーザーアカウントを削除します。
- 悪意のあるユーザーアカウントのパスワードを変更します。
## プロジェクトメンバーのフィルタリングと並べ替え
プロジェクト内のメンバーをフィルタリングおよび並べ替えすることができます。
### 直接メンバーを表示する
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトを検索します。
1. **管理>メンバー**を選択します。
1. **メンバーをフィルターする**ボックスで、`Membership` `=` `Direct`を選択します。
1. <kbd>Enter</kbd>キーを押します。
### 間接メンバーを表示する
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトを検索します。
1. **管理>メンバー**を選択します。
1. **メンバーをフィルターする**ボックスで、`Membership` `=` `Indirect`を選択します。
1. <kbd>Enter</kbd>キーを押します。
### プロジェクト内のメンバーを検索する
プロジェクトメンバーを検索するには:
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトを検索します。
1. **管理>メンバー**を選択します。
1. 検索ボックスに、メンバーの名前、ユーザー名、またはメールアドレスを入力します。
1. <kbd>Enter</kbd>キーを押します。
### プロジェクト内のメンバーを並べ替える
メンバーは、次の順序で昇順または降順に並べ替えることができます。
- **アカウント**名
- **アクセス付与**日
- メンバーがプロジェクトで持つ**ロール**
- **ユーザー作成**日
- **最後のアクティビティー**日
- **最終ログイン**日
メンバーを並べ替えるには:
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトを検索します。
1. **管理>メンバー**を選択します。
1. メンバーリストの上部にあるドロップダウンリストから、並べ替えの基準にする項目を選択します。
## プロジェクトへのアクセスをリクエストする
GitLabユーザーは、プロジェクトのメンバーになることをリクエストできます。
1. 左側のサイドバーで、**検索または移動**を選択し、メンバーになるプロジェクトを検索します。
1. 右上隅で、縦方向の省略記号（{{< icon name="ellipsis_v" >}}）を選択し、**アクセスをリクエスト**を選択します。
最近アクティブなプロジェクトのメンテナーまたはオーナーにメールが送信されます。最大10人のプロジェクトメンテナーまたはオーナーに通知されます。プロジェクトのオーナーまたはメンテナーは、リクエストを承認または拒否できます。プロジェクトメンテナーは、オーナーロールのアクセスリクエストを承認できません。
プロジェクトに直接のオーナーまたはメンテナーがいない場合、プロジェクトの親グループの最近アクティブなオーナーが通知を受け取ります。
### プロジェクトへのアクセスリクエストを取り下げる
リクエストが承認される前に、プロジェクトへのアクセスリクエストを取り下げることができます。アクセスリクエストを取り下げるには:
1. 左側のサイドバーで、**検索または移動**を選択し、アクセスをリクエストしたプロジェクトを検索します。
1. プロジェクト名の横にある**アクセスリクエストを取り消す**を選択します。
## ユーザーがプロジェクトへのアクセスをリクエストできないようにする
ユーザーがプロジェクトへのアクセスをリクエストできないようにすることができます。
前提要件:
- プロジェクトのオーナーロールを持っている必要があります。
- プロジェクトはパブリックである必要があります。
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトを検索します。
1. **設定>一般**を選択します。
1. **可視性、プロジェクトの機能、権限**を展開します。
1. **プロジェクトの表示レベル**で、**ユーザーがアクセスをリクエストできます**チェックボックスがオンになっていないことを確認します。
1. **変更の保存**を選択します。
## メンバーシップと表示レベルの権利
グループまたはプロジェクトのメンバーには、メンバーシップの種類に応じて、グループまたはプロジェクトに対するさまざまな[表示レベル](../../public_access.md)と権利が付与されます。
次の表に、プロジェクトメンバーのメンバーシップと表示レベルの権利を示します。
| アクション | 直接プロジェクトメンバー | 継承プロジェクトメンバー | 直接共有プロジェクトメンバー | 継承共有プロジェクトメンバー |
| --- | ------------------- | ---------------------- | -------------------------- | ----------------------------- |
| ボードを生成する | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 |
| 親グループのイシューを表示する<sup>1</sup> | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 |
| 親グループのラベルを表示する | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 |
| 親グループのマイルストーンを表示する | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 |
| 他のグループに共有される | {{< icon name="check-circle" >}} 可 | {{< icon name="dotted-circle" >}} 不可 | {{< icon name="dotted-circle" >}} 不可 | {{< icon name="dotted-circle" >}} 不可 |
| 他のプロジェクトにインポートされる | {{< icon name="check-circle" >}} 可 | {{< icon name="dotted-circle" >}} 不可 | {{< icon name="dotted-circle" >}} 不可 | {{< icon name="dotted-circle" >}} 不可 |
| プロジェクトを他のメンバーと共有する | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 |
**脚注:**
1. ユーザーは、アクセス権を持つプロジェクトのイシューのみ表示できます。
次の表に、グループメンバーのメンバーシップと表示レベルの権利を示します。
| アクション | 直接グループメンバー | 継承グループメンバー | 直接共有グループメンバー | 継承共有グループメンバー |
| --- | ------------------- | ---------------------- | -------------------------- | ----------------------------- |
| ボードを生成する | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 |
| 親グループのイシューを表示する | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 |
| 親グループのラベルを表示する | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 |
| 親グループのマイルストーンを表示する | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 | {{< icon name="check-circle" >}} 可 |
次の例では、`User`は以下のとおりです。
- `subgroup`の直接メンバー。
- `subsubgroup`の継承メンバー。
- `subgroup-2`と`subgroup-3`の間接メンバー。
- `subsubgroup-2`と`subsubgroup-3`の間接継承メンバー。
```mermaid
%%{init: { "fontFamily": "GitLab Sans" }}%%
graph TD
accTitle: Diagram of group inheritance
accDescr: User inheritance, both direct and indirect through subgroups
classDef user stroke:green,color:green;
root --> subgroup --> subsubgroup
root-2 --> subgroup-2 --> subsubgroup-2
root-3 --> subgroup-3 --> subsubgroup-3
subgroup -. shared .-> subgroup-2 -. shared .-> subgroup-3
User-. member .- subgroup
class User user
```

394
doc-locale/ja-jp/user/project/merge_requests/_index.md Normal file
View File

@ -0,0 +1,394 @@
---
stage: Create
group: Code Review
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
description: Propose, review, and collaborate on changes to a project.
title: マージリクエスト
---
{{< details >}}
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
{{< /details >}}
{{< history >}}
- GitLab 16.0で、サイドバーアクションメニューが[変更](https://gitlab.com/gitlab-org/gitlab/-/issues/373757)され、イシュー、インシデント、エピックのアクションも移動しました。
- GitLab 16.9で、[一般提供](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/127001)になりました。機能フラグ`moved_mr_sidebar`が削除されました。
{{< /history >}}
マージリクエストは、チームがコードをレビューし、ディスカッションを行い、コードの変更を追跡するための一元的な場所を提供します。変更を加えた理由を説明するには、マージリクエストをイシューにリンクし、マージリクエストのマージ時にイシューを自動的にクローズします。
マージリクエストは、特定分野の専門家が提案された変更をレビューし、組織のセキュリティ要件が満たされていることを保証するのに役立ちます。開発プロセスの早い段階でマージリクエストを作成すると、チームはバグやコード品質の問題を把握する時間を確保できます。
マージリクエストを表示すると、以下が表示されます。
- リクエストの説明
- コードの変更とインラインコードレビュー
- CI/CDパイプラインに関する情報
- マージ可能性レポート
- コメント
- コミットのリスト
## マージリクエストを作成する
[マージリクエストを作成する](creating_merge_requests.md)さまざまな方法を参照してください。
### マージリクエストテンプレートを使用する
マージリクエストを作成すると、GitLabは[説明テンプレート](../description_templates.md)の存在を確認して、マージリクエストにデータを追加します。GitLabは、1から5の順にこれらの場所を確認し、最初に見つかったテンプレートをマージリクエストに適用します。
| 名前 | プロジェクトUI<br>設定 | グループ<br>`default.md` | インスタンス<br>`default.md` | プロジェクト<br>`default.md` | テンプレートなし |
| :-- | :--: | :--: | :--: | :--: | :--: |
| 標準コミットメッセージ | 1 | 2 | 3 | 4 | 5 |
| `Closes #1234`のような[イシューのクローズパターン](../issues/managing_issues.md#closing-issues-automatically)を含むコミットメッセージ | 1 | 2 | 3 | 4 | 5 \* |
| `1234-example`のような[イシューIDで始まる](../repository/branches/_index.md#prefix-branch-names-with-a-number)ブランチ名 | 1 \* | 2 \* | 3 \* | 4 \* | 5 \* |
{{< alert type="note" >}}
アスタリスク（\*）が付いた項目は、[イシューのクローズパターン](../issues/managing_issues.md#closing-issues-automatically)も付け加えます。
{{< /alert >}}
## マージリクエストを表示する
プロジェクト、グループ、または自分のマージリクエストを表示できます。
{{< tabs >}}
{{< tab title="参加中" >}}
ホームページにすべてのマージリクエストを表示するには、<kbd>Shift</kbd> + <kbd>m</kbd>の[キーボードショートカット](../../shortcuts.md)を使用するか、次の手順に従います。
1. 左側のサイドバーで、**マージリクエスト**アイコンをクリックします。
または:
1. 左側のサイドバーで、**検索または移動先**を選択します。
1. ドロップダウンリストから、**マージリクエスト**を選択します。
{{< /tab >}}
{{< tab title="プロジェクト" >}}
プロジェクトのすべてのマージリクエストを表示するには:
1. 左側のサイドバーで、**検索または移動先**を選択し、プロジェクトを検索します。
1. **コード>マージリクエスト**を選択します。
または、[キーボードショートカット](../../shortcuts.md)を使用するには、<kbd>g</kbd> + <kbd>m</kbd>を押します。
{{< /tab >}}
{{< tab title="グループ内のすべてのプロジェクト" >}}
グループ内のすべてのプロジェクトのマージリクエストを表示するには:
1. 左側のサイドバーで、**検索または移動先**を選択し、グループを検索します。
1. **コード>マージリクエスト**を選択します。
グループにサブグループが含まれている場合、このビューにはサブグループプロジェクトからのマージリクエストも表示されます。
{{< /tab >}}
{{< /tabs >}}
## マージリクエストのリストをフィルタリングする
{{< history >}}
- GitLab 16.6で、`source-branch`によるフィルタリングが[導入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/134555)されました。
- GitLab 16.9で、`merged-by`によるフィルタリングが[導入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/140002)されました。機能フラグ`mr_merge_user_filter`が有効になっている場合にのみ使用できます。
- GitLab 17.0で、`merged-by`によるフィルタリングが[一般提供](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/142666)になりました。機能フラグ`mr_merge_user_filter`が削除されました。
{{< /history >}}
マージリクエストのリストをフィルタリングするには:
1. 左側のサイドバーで、**検索または移動先**を選択し、プロジェクトを検索します。
1. **コード>マージリクエスト**を選択します。
1. マージリクエストのリストの上にある**結果を検索またはフィルタリングします**を選択します。
1. ドロップダウンリストから、フィルタリングする属性を選択します。次に例を示します。
- [**環境またはデプロイ日別**](#by-environment-or-deployment-date)。
- **ID**: フィルター`#30`を入力して、マージリクエスト30のみを返します。
- ユーザーフィルター: 次のいずれかのフィルターを入力（またはドロップダウンリストから選択）して、ユーザーのリストを表示します。
- **承認したユーザー**: ユーザーがすでに承認したマージリクエスト。PremiumおよびUltimateのみ。
- **承認者**: このユーザーが承認する資格のあるマージリクエスト（詳細については、「[コードオーナー](../codeowners/_index.md)」を参照してください）。PremiumおよびUltimateのみ。
- **マージしたユーザー**: このユーザーがマージしたマージリクエスト。
- **レビュアー**: このユーザーがレビューしたマージリクエスト。
1. 属性のフィルタリングに使用する演算子を選択または入力します。次の演算子を使用できます。
- `=`: 等しい
- `!=`: 等しくない
1. 属性をフィルタリングするテキストを入力します。一部の属性は、**なし**または**任意**でフィルタリングできます。
1. このプロセスを繰り返して、論理`AND`で結合された、より多くの属性でフィルタリングします。
1. **ソート方向**（降順の場合は{{< icon name="sort-lowest" >}}、昇順の場合は{{< icon name="sort-highest" >}}）を選択します。
### 環境またはデプロイ日別
デプロイデータ（環境や日付など）でマージリクエストをフィルタリングするには、次のいずれかを入力（またはドロップダウンリストから選択）します。
- 環境
- デプロイ前
- デプロイ後
{{< alert type="note" >}}
[fast-forwardのマージ方法](methods/_index.md#fast-forward-merge)ではマージコミットが作成されないため、この方法を使用するプロジェクトは結果を返しません。
{{< /alert >}}
環境でフィルタリングする場合、選択できるすべての環境がドロップダウンリストに表示されます。
`Deployed-before`（デプロイ前）または`Deployed-after`（デプロイ後）でフィルタリングする場合:
- 日付は、（マージコミットによってトリガーされた）環境へのデプロイが正常に完了した時点を指します。
- デプロイ日は手動で入力する必要があります。
- デプロイ日の形式は`YYYY-MM-DD`です。日付と時刻の両方を指定する場合は、二重引用符（`"`）で囲みます（`"YYYY-MM-DD HH:MM"`）。
## マージリクエストに変更を加える
マージリクエストに変更を加える権限がある場合は、いくつかの方法で既存のマージリクエストに変更を加えることができます。これらの方法は、変更の複雑さと、開発環境へのアクセス権が必要かどうかに応じて異なります。
- [Web IDEで変更を編集する](../web_ide/_index.md)には、ブラウザで「<kbd>.</kbd>」キーの[キーボードショートカット](../../shortcuts.md)を使用します。複数のファイルを編集する場合、またはGitコマンドに慣れていない場合は、このブラウザベースの方法を使用します。Web IDEからテストを実行することはできません。
- ファイルを編集し、その後のテストを実行するための機能をすべて備えた環境が必要な場合は、[Gitpodで変更を編集](../../../integration/gitpod.md#launch-gitpod-in-gitlab)します。Gitpodは、[GitLab Development Kit（GDK）](https://gitlab.com/gitlab-org/gitlab-development-kit)の実行をサポートしています。Gitpodを使用するには、[ユーザーアカウントでGitpodを有効にする](../../../integration/gitpod.md#enable-gitpod-in-your-user-preferences)必要があります。
- Gitおよびコマンドラインに精通している場合は、[コマンドラインから変更をプッシュ](../../../topics/git/commands.md)します。
## ユーザーをマージリクエストに割り当てる
マージリクエストをユーザーに割り当てるには、マージリクエストのテキストエリアで`/assign @user`[クイックアクション](../quick_actions.md#issues-merge-requests-and-epics)を使用するか、次の手順に従います。
1. 左側のサイドバーで、**検索または移動先**を選択し、プロジェクトを検索します。
1. **コード>マージリクエスト**を選択し、マージリクエストを検索します。
1. 右側のサイドバーで、右側のサイドバーを展開し、**担当者**セクションを見つけます。
1. **編集**を選択します。
1. 割り当てるユーザーを検索し、ユーザーを選択します。GitLab Freeでは、マージリクエストごとに1人の担当者を許可しますが、GitLab PremiumおよびGitLab Ultimateでは、複数の担当者を許可します。
![マージリクエストサイドバーに表示された2人の担当者](img/merge_request_assignees_v16_0.png)
GitLabは、ユーザーの**アサインされたマージリクエスト**ページにマージリクエストを追加します。
## マージリクエストをマージする
[マージリクエストのレビュープロセス](reviews/_index.md)中に、レビュアーは変更に関するフィードバックを提供します。レビュアーが変更に満足している場合は、一部のマージチェックが失敗していても[自動マージ](auto_merge.md)を有効にすることができます。すべてのマージチェックに合格すると、マージリクエストは自動的にマージされ、それ以上の操作は必要ありません。
デフォルトのマージ権限:
- デフォルトブランチ（通常は`main`）は保護されています。
- メンテナー以上のロールのみがデフォルトブランチにマージできます。
- デベロッパーは、保護されていないブランチをターゲットとする任意のマージリクエストをマージできます。
特定のマージリクエストをマージする権限があるかどうかを判断するために、GitLabは以下を確認します。
- プロジェクトでの[ロール](../../permissions.md#roles)（デベロッパー、メンテナー、オーナーなど）
- ターゲットブランチの[ブランチ保護](../repository/branches/protected.md)
## マージリクエストをクローズする
マージリクエストでの作業を完全に停止する場合は、[削除する](manage.md#delete-a-merge-request)のではなく、クローズしてください。
前提要件:
- マージリクエストの作成者または担当者である必要があります。または
- プロジェクトのデベロッパー、メンテナー、またはオーナー[ロール](../../permissions.md)を持っている必要があります。
プロジェクトでマージリクエストをクローズするには:
1. 左側のサイドバーで、**検索または移動先**を選択し、プロジェクトを検索します。
1. **コード>マージリクエスト**を選択し、マージリクエストを検索します。
1. ページの下部にあるコメントボックスまでスクロールします。
1. コメントボックスの後の**マージリクエストをクローズ**を選択します。
GitLabはマージリクエストをクローズしますが、マージリクエスト、そのコメント、および関連するパイプラインのレコードを保持します。
### マージ時にソースブランチを削除する
次のように、マージリクエストのソースブランチを削除できます。
- マージリクエストを作成するときに、**マージリクエストが承認されたときにソースブランチを削除します。**を選択します。
- マージリクエストをマージするときに、メンテナーロールを持っている場合は、**ソースブランチを削除**を選択します。
管理者は、プロジェクトの設定でこのオプションをデフォルトにすることができます。
delete-branchアクションは、自動マージを設定するユーザーまたはマージリクエストをマージするユーザーによって実行されます。ユーザーに正しいロールがない場合（フォークされたプロジェクトなど）、ソースブランチの削除は失敗します。
### ターゲットブランチのマージ時にマージリクエストを更新する
{{< details >}}
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
{{< /details >}}
マージリクエストは多くの場合連鎖しており、1つのマージリクエストは別のマージリクエストで追加または変更されたコードに依存しています。個々のマージリクエストを小さく保つことをサポートするために、GitLabは、ターゲットブランチが`main`にマージされるときに、最大4つのオープンマージリクエストを更新できます。次に例を示します。
- **マージリクエスト1**: `feature-alpha`を`main`にマージします。
- **マージリクエスト2**: `feature-beta`を`feature-alpha`にマージします。
これらのマージリクエストが同時にオープンになっていて、マージリクエスト1（`feature-alpha`）が`main`にマージされる場合、GitLabはマージリクエスト2の宛先を`feature-alpha`から`main`に更新します。
相互接続されたコンテンツ更新を含むマージリクエストは、通常、次のいずれかの方法で処理されます。
- 最初に、マージリクエスト1が`main`にマージされます。次に、マージリクエスト2のターゲットが`main`に変更されます。
- マージリクエスト2が`feature-alpha`にマージされます。更新されたマージリクエスト1は、`feature-alpha`と`feature-beta`の内容を含むようになり、`main`にマージされます。
この機能は、マージリクエストがマージされた場合にのみ機能します。マージ後に**ソースブランチを削除**を選択しても、オープンマージリクエストのターゲットは変更されません。この改善は、[フォローアップとして提案されています](https://gitlab.com/gitlab-org/gitlab/-/issues/321559)。
## マージリクエストのワークフロー
チームで作業するソフトウェアデベロッパー向け:
1. 新しいブランチをチェックアウトし、マージリクエストを通じて変更を送信します。
1. チームからフィードバックを集めます。
1. [コード品質レポート](../../../ci/testing/code_quality.md)でコードを最適化する実装に取り組みます。
1. GitLab CI/CDの[単体試験レポート](../../../ci/testing/unit_test_reports.md)で変更を確認します。
1. [ライセンス承認ポリシー](../../compliance/license_approval_policies.md)を使用して、ライセンスがプロジェクトと互換性のない依存関係の使用を回避します。
1. マネージャーに[承認](approvals/_index.md)をリクエストします。
1. マネージャー:
1. 最終レビューでコミットをプッシュします。
1. [マージリクエストを承認](approvals/_index.md)します。
1. [自動マージ](auto_merge.md)（旧**パイプラインが成功したときにマージ**）に設定します。
1. GitLab CI/CDの[手動ジョブ](../../../ci/jobs/job_control.md#create-a-job-that-must-be-run-manually)で、変更が本番環境にデプロイされます。
1. 実装が顧客に正常に送信されました。
会社のWebサイト用のWebページを作成するWebデベロッパー向け:
1. 新しいブランチをチェックアウトし、マージリクエストを通じて新しいページを送信します。
1. レビュアーからフィードバックを集めます。
1. [Review Apps](../../../ci/review_apps/_index.md)で変更をプレビューします。
1. Webデザイナーに実装をリクエストします。
1. マネージャーに[承認](approvals/_index.md)をリクエストします。
1. 承認後、GitLabは以下を実行します。
- コミットを[スカッシュ](squash_and_merge.md)します。
- コミットをマージします。
- [GitLab Pagesを使用して、stagingステージに変更をデプロイします](https://about.gitlab.com/blog/2021/02/05/ci-deployment-and-environments/)。
1. 本番環境チームは、マージコミットを本番環境に[cherry-pick](cherry_pick_changes.md)します。
## マージリクエストのアクティビティーをフィルタリングする
{{< history >}}
- GitLab 15.11で、`mr_activity_filters`という名前の[フラグとともに](../../../administration/feature_flags.md)[導入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/115383)されました。デフォルトでは無効になっています。
- GitLab 16.0の[GitLab.comで有効](https://gitlab.com/gitlab-org/gitlab/-/issues/387070)になりました。
- デフォルトで、GitLab 16.3の[GitLab Self-Managedで有効](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/126998)になりました。
- GitLab 16.5で、[一般提供](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/132355)になりました。機能フラグ`mr_activity_filters`が削除されました。
- GitLab 16.9で、ボットコメントのフィルタリングが[導入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/128473)されました。
{{< /history >}}
マージリクエストの履歴を把握するには、アクティビティーフィードをフィルタリングして、自分に関係のある項目のみを表示します。
1. 左側のサイドバーで、**検索または移動先**を選択し、プロジェクトを検索します。
1. **コード>マージリクエスト**を選択します。
1. マージリクエストを選択します。
1. **アクティビティー**までスクロールします。
1. ページの右側で、**アクティビティーをフィルタリング**を選択して、フィルターオプションを表示します。すでにフィルターオプションを選択している場合、このフィールドには**アクティビティー+他5件**のように、選択内容の概要が表示されます。
1. 表示するアクティビティーのタイプを選択します。オプションには以下が含まれます。
- 担当者とレビュアー
- 承認
- ボットからのコメント
- ユーザーからのコメント
- コミットとブランチ
- 編集
- ラベル
- ロック状態
- メンション
- マージリクエストのステータス
- トラッキング
1. オプション: **ソート**（{{< icon name="sort-lowest" >}}）を選択して、ソート順を逆にします。
選択内容は、すべてのマージリクエストで保持されます。右側のソートボタンをクリックして、ソート順を変更することもできます。
## スレッドを解決する
マージリクエストでの会話を終了する場合は、[スレッドを解決](../../discussions/_index.md#resolve-a-thread)します。
GitLabでは、マージリクエストの右上隅に未解決スレッドの数が次のように表示されます: **7件の未解決スレッド**。
### マージリクエスト内のすべての未解決スレッドをイシューに移動する
マージリクエストに複数の未解決スレッドがある場合は、イシューを作成して個別に解決できます。
1. 左側のサイドバーで、**検索または移動先**を選択し、プロジェクトを検索します。
1. **コード>マージリクエスト**を選択し、マージリクエストを検索します。
1. マージリクエストの右上にある**未解決スレッド**ドロップダウンリストで、**スレッドオプション**（{{< icon name="ellipsis_v" >}}）を選択します。
1. **新しいイシューですべて解決する**を選択します。
1. 新しいイシューのフィールドに入力し、**イシューを作成する**を選択します。
GitLabはすべてのスレッドを解決済みにし、マージリクエストから新しく作成されたイシューにリンクを追加します。
### マージリクエスト内の1つの未解決スレッドをイシューに移動する
マージリクエストに1つの特定の未解決スレッドがある場合は、イシューを作成して個別に解決できます。
1. 左側のサイドバーで、**検索または移動先**を選択し、プロジェクトを検索します。
1. **コード>マージリクエスト**を選択し、マージリクエストを検索します。
1. マージリクエストで、移動するスレッドを検索します。
1. スレッドへの最後の返信の下、**スレッドを解決します。**の横にある**スレッドを解決するためのイシューを作成**（{{< icon name="issue-new" >}}）を選択します。
1. 新しいイシューのフィールドに入力し、**イシューを作成する**を選択します。
GitLabはスレッドを解決済みにし、マージリクエストから新しく作成されたイシューにリンクを追加します。
### すべてのスレッドが解決されるまでマージを禁止する
スレッドが未解決のままマージリクエストがマージされるのを防ぐことができます。この設定を有効にすると、少なくとも1つのスレッドが未解決のままである間、マージリクエストの**未解決スレッド**カウンターはオレンジ色で表示されます。
1. 左側のサイドバーで、**検索または移動先**を選択し、プロジェクトを検索します。
1. **設定>マージリクエスト**を選択します。
1. **マージチェック**セクションで、**すべてのスレッドが解決している**チェックボックスをオンにします。
1. **変更の保存**を選択します。
### 期限切れになったときにマージリクエストのスレッドを自動的に解決する
記述されている行が新しいプッシュによって変更されたときに、スレッドを自動的に解決するようにマージリクエストを設定できます。
1. 左側のサイドバーで、**検索または移動先**を選択し、プロジェクトを検索します。
1. **設定>マージリクエスト**を選択します。
1. **マージオプション**セクションで、**期限切れになったときにマージリクエストの差分スレッドを自動的に解決します**を選択します。
1. **変更の保存**を選択します。
これで、プッシュによって差分セクションが古くなると、スレッドが解決されるようになります。変更されていない行のスレッドと、最上位の解決可能なスレッドは解決されません。
## 通知とTo Doを移動する
{{< details >}}
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab Self-Managed
{{< /details >}}
{{< history >}}
- GitLab 16.5で、`notifications_todos_buttons`という名前の[フラグとともに](../../../administration/feature_flags.md)[導入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/132678)されました。デフォルトでは無効になっています。
- [イシュー、インシデント](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/133474)、[エピック](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/133881)も更新されました。
{{< /history >}}
{{< alert type="flag" >}}
GitLab Self-Managedでは、デフォルトでこの機能は利用できません。管理者が`notifications_todos_buttons`という名前の[機能フラグを有効にする](../../../administration/feature_flags.md)と、この機能を使用できるようになります。GitLab.comとGitLab Dedicatedでは、この機能は使用できません。
{{< /alert >}}
この機能フラグを有効にすると、通知ボタンとTo Doアイテムボタンがページ右上隅に移動します。
- マージリクエストでは、これらのボタンはタブの右端に表示されます。
- イシュー、インシデント、エピックでは、これらのボタンは右側のサイドバー上部に表示されます。
## 関連トピック
- [マージリクエストを作成する](creating_merge_requests.md)
- [マージリクエストをレビューする](reviews/_index.md)
- [マージリクエストを認証する](authorization_for_merge_requests.md)
- [テストとレポート](../../../ci/testing/_index.md)
- [GitLabのキーボードショートカット](../../shortcuts.md)
- [コメントとスレッド](../../discussions/_index.md)
- [コード変更を提案する](reviews/suggestions.md)
- [CI/CDパイプライン](../../../ci/_index.md)
- マージリクエストの[プッシュオプション](../../../topics/git/commit.md)

186
doc-locale/ja-jp/user/project/repository/_index.md Normal file
View File

@ -0,0 +1,186 @@
---
stage: Create
group: Source Code
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
description: How to create, clone, and use GitLab repositories.
title: リポジトリ
---
{{< details >}}
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
{{< /details >}}
[リポジトリ](https://git-scm.com/book/en/v2/Git-Basics-Getting-a-Git-Repository)は、コードを保存し、変更を加え、バージョン管理を使用して変更を追跡する場所です。各[プロジェクト](../_index.md)にはリポジトリが含まれており、プロジェクトなしにリポジトリは存在できません。
## リポジトリを作成する
リポジトリを作成するには:
- [プロジェクトを作成する](../_index.md)または
- [既存のプロジェクトをフォークする](forking_workflow.md)
## リポジトリにファイルを追加する
リポジトリにファイルを追加できます。
- [プロジェクトを作成する](../_index.md)場合、または
- プロジェクトの作成後、次のオプションを使用します。
- [Webエディタ](web_editor.md#upload-a-file)
- [ユーザーインターフェース（UI）](#add-a-file-from-the-ui)
- [コマンドライン](../../../topics/git/add_files.md)
### UIからファイルを追加する
GitLab UIからファイルを追加またはアップロードするには:
<!-- Original source for this list: doc/user/project/repository/web_editor.md#upload-a-file -->
<!-- For why we duplicated the info, see https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111072#note_1267429478 -->
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトを検索します。
1. ファイルをアップロードするディレクトリに移動します。
1. ディレクトリ名の横にあるプラスアイコン（{{< icon name="plus" >}}）>**ファイルをアップロード**を選択します。
1. ファイルをドロップまたはアップロードします。
1. コミットメッセージを入力します。
1. オプション: 変更を加えてマージリクエストを作成するには、**ターゲットブランチ**に、リポジトリの[デフォルトブランチ](branches/default.md)ではないブランチ名を入力します。
1. **ファイルをアップロード**を選択します。
## リポジトリへの変更をコミットする
リポジトリ内のブランチへの変更をコミットできます。コマンドラインを使用する場合は、[`git commit`](../../../topics/git/commands.md#git-commit)を使用します。
コミットを使用してコミュニケーションとコラボレーションを改善する方法、パイプラインをトリガーまたはスキップする方法、変更を元に戻す方法については、「[コミット](../merge_requests/commits.md)」を参照してください。
## リポジトリのクローンを作成する
以下を使用してリポジトリのクローンを作成できます。
- コマンドライン:
- [SSHを使用してクローンを作成する](../../../topics/git/clone.md#clone-with-ssh)
- [HTTPSを使用してクローンを作成する](../../../topics/git/clone.md#clone-with-https)
- GitLab UI:
- [Apple Xcodeでクローンを作成して開く](../../../topics/git/clone.md#clone-and-open-in-apple-xcode)
- [Visual Studio Codeでクローンを作成して開く](../../../topics/git/clone.md#clone-and-open-in-visual-studio-code)
- [IntelliJ IDEAでクローンを作成して開く](../../../topics/git/clone.md#clone-and-open-in-intellij-idea)
## リポジトリのソースコードをダウンロードする
リポジトリのソースコードをダウンロードすると、圧縮され、アーカイブファイルとして保存されます。リポジトリに保存されているソースコードをダウンロードするには:
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトを検索します。
1. ファイルリストの上にある**コード**を選択します。
1. オプションから、ダウンロードするファイルを選択します。
- **ソースコード:**
表示している現在のブランチからソースコードをダウンロードします。利用可能な拡張子: `zip`、`tar`、`tar.gz`、`tar.bz2`。
- **ディレクトリ:**
特定のディレクトリをダウンロードします。サブディレクトリを表示している場合にのみ表示されます。利用可能な拡張子: `zip`、`tar`、`tar.gz`、`tar.bz2`。
- **アーティファクト:**
最新のCI/CDジョブからアーティファクトをダウンロードします。
生成されたアーカイブのチェックサムは、リポジトリ自体が変更されていなくても変更される可能性があります。たとえば、GitまたはGitLabが使用するサードパーティライブラリが変更された場合に発生します。
## リポジトリの言語
GitLabは、デフォルトブランチで使用されているプログラミング言語を検出します。この情報は、**プロジェクトの概要**ページに表示されます。
![リポジトリ言語バー](img/repository_languages_v15_2.png)
新しいファイルが追加されると、この情報の更新に最大5分かかる場合があります。
### リポジトリ言語を追加する
すべてのファイルが検出され、**プロジェクトの概要**ページにリストされるわけではありません。ドキュメント、ベンダーコード、[ほとんどのマークアップ言語](files/_index.md#supported-markup-languages)は除外されます。サポートされているファイルと言語のリストを表示するには、[サポートされているデータ型](https://github.com/github/linguist/blob/master/lib/linguist/languages.yml)を参照してください。
この動作を変更し、デフォルト設定に追加のファイルタイプを含めるには:
1. リポジトリのルートディレクトリに、`.gitattributes`という名前のファイルを作成します。
1. 特定のファイルタイプを含めるようにGitLabに指示する行を追加します。たとえば、`.proto`ファイルを有効にするには、以下を追加します。
```plaintext
*.proto linguist-detectable=true
```
この機能は、過剰なCPUを使用する可能性があります。問題が発生した場合は、「[リポジトリの言語: 過剰なCPU使用率](files/_index.md#repository-languages-excessive-cpu-use)」のトラブルシューティングセクションを参照してください。
## リポジトリのコントリビューター分析
選択したプロジェクトブランチへのコミット数の経時的な折れ線グラフ、および各プロジェクトメンバーによるコミット数の折れ線グラフを表示できます。詳細については、「[コントリビューター分析](../../analytics/contributor_analytics.md)」を参照してください。
## リポジトリの履歴グラフ
リポジトリグラフには、ブランチやマージなど、リポジトリネットワークの視覚的な履歴が表示されます。このグラフは、リポジトリ内の変更の流れを確認するのに役立ちます。
リポジトリの履歴グラフを表示するには、プロジェクトの**コード>リポジトリグラフ**に移動します。
![リポジトリ内のコミットの流れを示すグラフ。](img/repo_graph_v17_9.png)
## リポジトリパスの変更
リポジトリパスが変更されると、GitLabはリダイレクトを使用して、古い場所から新しい場所への移行を処理します。
[ユーザーの名前を変更](../../profile/_index.md#change-your-username)したり、[グループパスを変更](../../group/manage.md#change-a-groups-path)したり、[リポジトリの名前を変更](../working_with_projects.md#rename-a-repository)したりすると、次のようになります。
- ネームスペースのURLとその配下にあるすべて（プロジェクトなど）は、新しいURLにリダイレクトされます。
- ネームスペース配下のプロジェクトのGitリモートURLは、新しいリモートURLにリダイレクトされます。場所が変更されたリポジトリにプッシュまたはプルすると、リモートを更新するように促す警告メッセージが表示されます。名前変更後も、自動化スクリプトまたはGitクライアントは引き続き動作します。
- リダイレクトは、元のパスが別のグループ、ユーザー、またはプロジェクトによって要求されない限り使用できます。
- [APIリダイレクト](../../../api/rest/_index.md#redirects)は、明示的にフォローする必要がある場合があります。
パスを変更した後、次のリソースで既存のURLを更新する必要があります。
- [インクルードステートメント](../../../ci/yaml/includes.md)（[`include:component`](../../../ci/components/_index.md)を除く）: そうしないと、パイプラインは構文エラーで失敗します。CI/CDコンポーネントの参照は、リダイレクトに従うことができます。
- 数値のネームスペースおよびプロジェクトIDの代わりに[エンコードされたパス](../../../api/rest/_index.md#namespaced-paths)を使用するネームスペースAPIコール。
- [Dockerイメージ参照](../../../ci/yaml/_index.md#image)。
- プロジェクトまたはネームスペースを指定する変数。
- [CODEOWNERSファイル](../codeowners/_index.md#codeowners-file)。
## 関連トピック
- [VS Code用GitLabワークフロー拡張機能](../../../editor_extensions/visual_studio_code/_index.md)
- [ロックファイルを使用して変更の競合を防ぐ](../file_lock.md)
- [リポジトリAPI](../../../api/repositories.md)
- [ファイル](files/_index.md)
- [ブランチ](branches/_index.md)
- [ディレクトリを作成する](web_editor.md#create-a-directory)
- [ファイル履歴を検索する](files/git_history.md)
- [行ごとの変更を識別する（Git blame）](files/git_blame.md)
## トラブルシューティング
### リポジトリへのプッシュのシーケンスを検索する
コミットが「見つからない」と思われる場合は、リポジトリへのプッシュのシーケンスを検索します。[このStackOverflowの記事](https://stackoverflow.com/questions/13468027/the-mystery-of-the-missing-commit-across-merges)では、強制プッシュなしでこの状態になる方法が説明されています。別の原因として、`git reset`操作でHEAD refを変更する[サーバーフック](../../../administration/server_hooks.md)が誤って設定されていることが考えられます。
ターゲットブランチの以下のサンプルコードからの出力を確認すると、出力のステップ実行時に、from/toコミットに不連続性が見られます。新しいプッシュの`commit_from`は、前のプッシュの`commit_to`と等しくなければなりません。そのシーケンスの中断は、1つ以上のコミットがリポジトリの履歴から「失われた」ことを示します。
[Railsコンソール](../../../administration/operations/rails_console.md#starting-a-rails-console-session)を使用して、次の例では、最後の100件のプッシュをチェックし、`commit_from`エントリと`commit_to`エントリを出力します。
```ruby
p = Project.find_by_full_path('project/path')
p.events.pushed_action.last(100).each do |e|
printf "%-20.20s %8s...%8s (%s)", e.push_event_payload[:ref], e.push_event_payload[:commit_from], e.push_event_payload[:commit_to], e.author.try(:username)
end ; nil
```
シーケンスの中断を示す出力例（4行目）:
```plaintext
master f21b07713251e04575908149bdc8ac1f105aabc3...6bc56c1f46244792222f6c85b11606933af171de root
master 6bc56c1f46244792222f6c85b11606933af171de...132da6064f5d3453d445fd7cb452b148705bdc1b root
master 132da6064f5d3453d445fd7cb452b148705bdc1b...a62e1e693150a2e46ace0ce696cd4a52856dfa65 root
master 58b07b719a4b0039fec810efa52f479ba1b84756...f05321a5b5728bd8a89b7bf530aa44043c951dce root
master f05321a5b5728bd8a89b7bf530aa44043c951dce...7d02e575fd790e76a3284ee435368279a5eb3773 root
```
### エラー: Xcodeがリポジトリのクローン作成に失敗する
GitLabは、[許可されたSSH鍵のリストを制限する](../../../security/ssh_keys_restrictions.md)オプションを提供します。SSH鍵が許可リストにない場合は、`The repository rejected the provided credentials`のようなエラーが発生する可能性があります。
この問題を解決するには、[サポートされているSSH鍵タイプ](../../ssh.md#supported-ssh-key-types)のガイドラインに適合する新しいSSH鍵ペアを作成します。サポートされているSSH鍵を生成したら、リポジトリのクローン作成を再度試してください。

618
doc-locale/ja-jp/user/project/working_with_projects.md Normal file
View File

@ -0,0 +1,618 @@
---
stage: Tenant Scale
group: Organizations
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: プロジェクトを管理する
---
{{< details >}}
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
{{< /details >}}
GitLabでのほとんどの作業は、[プロジェクト](_index.md)内で行われます。ファイルとコードはプロジェクトに保存され、ほとんどの機能はプロジェクトのスコープ内にあります。
## プロジェクトの概要
{{< history >}}
- プロジェクトの作成日は、GitLab 16.10で[導入](https://gitlab.com/gitlab-org/gitlab/-/issues/19452)されました。
{{< /history >}}
プロジェクトを選択すると、**プロジェクトの概要**ページにプロジェクトの次の内容が表示されます。
- リポジトリ内のファイル
- プロジェクト情報（説明）
- トピック
- バッジ
- プロジェクト内のお気に入り、フォーク、コミット、ブランチ、タグ、リリース、環境の数
- プロジェクトのストレージサイズ
- オプションのファイルと設定
- `README`またはインデックスファイル
- Wikiページ
- ライセンス
- 変更履歴
- コントリビュートのガイドライン
- Kubernetesクラスター
- CI/CDの設定
- インテグレーション
- GitLab Pages
- 作成日
パブリックプロジェクト、および[プロジェクトのコードを表示する権限](../permissions.md#project-members-permissions)を持つ内部プロジェクトとプライベートプロジェクトのメンバーの場合、プロジェクトの概要ページには以下が表示されます。
- [`README`またはインデックスファイル](repository/files/_index.md#readme-and-index-files)
- プロジェクトのリポジトリ内のディレクトリのリスト
プロジェクトのコードを表示する権限を持たないユーザーの場合、概要ページには以下が表示されます。
- Wikiのホームページ
- プロジェクト内のイシューのリスト
### プロジェクトIDを使用してプロジェクトにアクセスする
{{< history >}}
- GitLab 16.7で、プロジェクトIDがアクションメニューに[移動](https://gitlab.com/gitlab-org/gitlab/-/issues/431539)しました。
{{< /history >}}
`https://gitlab.example.com/projects/<id>`で、名前の代わりにIDを使用してプロジェクトにアクセスできます。たとえば、パーソナルネームスペース`alex`にID `123456`のプロジェクト`my-project`がある場合、`https://gitlab.example.com/alex/my-project`または`https://gitlab.example.com/projects/123456`でプロジェクトにアクセスできます。
{{< alert type="note" >}}
GitLab 17.5以降では、このエンドポイントに`https://gitlab.example.com/-/p/<id>`を使用することもできます。
{{< /alert >}}
[GitLab API](../../api/_index.md)を使用してプロジェクトを操作する場合は、プロジェクトIDが必要になる場合もあります。
プロジェクトIDをコピーするには:
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトを検索します。
1. プロジェクトの概要ページの右上隅で、**アクション**（{{< icon name="ellipsis_v" >}}）を選択します。
1. **プロジェクトIDをコピー**を選択します。
## インスタンスのすべてのプロジェクトを表示する
GitLabインスタンスのすべてのプロジェクトを表示するには:
1. 左側のサイドバーで、**検索または移動**を選択します。
1. **探す**を選択します。
左側のサイドバーで、**プロジェクト**が選択されています。インスタンスのすべてのプロジェクトのリストが表示されます。
認証されていない場合、リストにはパブリックプロジェクトのみが表示されます。
## コントリビュート済みのプロジェクトを表示する
{{< history >}}
- GitLab 17.9で、`your_work_projects_vue`という名前の[フラグとともに](../../administration/feature_flags.md)[導入](https://gitlab.com/groups/gitlab-org/-/epics/13066)されました。デフォルトでは無効になっています。
- GitLab 17.10で、[一般提供](https://gitlab.com/gitlab-org/gitlab/-/issues/465889)になりました。機能フラグ`your_work_projects_vue`が削除されました。
{{< /history >}}
{{< alert type="flag" >}}
この機能の利用可否は、機能フラグによって制御されます。詳細については、履歴を参照してください。
{{< /alert >}}
**コントリビュート済み**タブには、次のプロジェクトが表示されます。
- イシュー、マージリクエスト、またはエピックを作成したプロジェクト
- イシュー、マージリクエスト、またはエピックにコメントしたプロジェクト
- イシュー、マージリクエスト、またはエピックをクローズしたプロジェクト
- コミットをプッシュしたプロジェクト
- マージリクエストを承認したプロジェクト
- マージリクエストをマージしたプロジェクト
コントリビュート済みのプロジェクトを表示するには:
1. 左側のサイドバーで、**検索または移動**を選択します。
1. **すべてのプロジェクトを表示**を選択します。
1. **コントリビュート済み**タブを選択します。
## メンバーになっているプロジェクトを表示する
{{< history >}}
- GitLab 17.9で、`your_work_projects_vue`という名前の[フラグとともに](../../administration/feature_flags.md)、タブのラベルが「あなたの」から「メンバー」に[変更](https://gitlab.com/groups/gitlab-org/-/epics/13066)されました。デフォルトでは無効になっています。
- GitLab 17.10で、タブのラベルの一般提供が[変更](https://gitlab.com/gitlab-org/gitlab/-/issues/465889)されました。機能フラグ`your_work_projects_vue`が削除されました。
{{< /history >}}
メンバーになっているプロジェクトを表示するには:
1. 左側のサイドバーで、**検索または移動**を選択します。
1. **すべてのプロジェクトを表示**を選択します。
1. **あなたの**タブを選択します。
{{< alert type="note" >}}
このタブは、`your_work_projects_vue`機能フラグが有効になっている場合は、**メンバー**として表示されます。
{{< /alert >}}
## パーソナルプロジェクトを表示する
パーソナルプロジェクトは、パーソナルネームスペースで作成されたプロジェクトです。
たとえば、ユーザー名`alex`でアカウントを作成し、自分のユーザー名で`my-project`というプロジェクトを作成すると、プロジェクトは`https://gitlab.example.com/alex/my-project`に作成されます。
パーソナルプロジェクトを表示するには:
1. 左側のサイドバーで、**検索または移動**を選択します。
1. **すべてのプロジェクトを表示**を選択します。
1. **個人**タブを選択します。
または
1. 左側のサイドバーで、自分のアバターを選択し、次にユーザー名を選択します。
1. 左側のサイドバーで、**パーソナルプロジェクト**を選択します。
## Star付きのプロジェクトを表示する
[Star付きの](#star-a-project)プロジェクトを表示するには:
1. 左側のサイドバーで、**検索または移動**を選択します。
1. **すべてのプロジェクトを表示**を選択します。
1. **お気に入り**タブを選択します。
または
1. 左側のサイドバーで、自分のアバターを選択し、次にユーザー名を選択します。
1. 左側のサイドバーで、**Star付きのプロジェクト**を選択します。
## プロジェクト名と説明を編集する
プロジェクトの一般設定を使用して、プロジェクトの詳細を編集します。
前提要件:
- プロジェクトのメンテナー以上のロールを持っている必要があります。
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトを検索します。
1. **設定>一般**を選択します。
1. **プロジェクト名**テキストボックスに、プロジェクト名を入力します。[プロジェクト名の制限](../reserved_names.md)を参照してください。
1. オプション: **プロジェクトの説明**テキストボックスに、プロジェクトの説明を入力します。説明は2,000文字に制限されています。CI/CDカタログに公開されているコンポーネントには、プロジェクトの説明が必要です。
1. **変更の保存**を選択します。
## プロジェクトアバターを追加する
プロジェクトを視覚的に識別できるように、プロジェクトアバターを追加します。アバターを追加しない場合、GitLabはプロジェクト名の最初の文字をデフォルトのプロジェクトアバターとして表示します。
プロジェクトアバターを追加するには、次のいずれかの方法を使用します。
- リポジトリに[ロゴを追加](#add-a-logo-to-your-repository)します。
- プロジェクトの設定で[アバターをアップロード](#upload-an-avatar-in-project-settings)します。
### リポジトリにロゴを追加する
プロジェクト設定にアバターをアップロードしていない場合、GitLabは`logo`という名前のファイルをリポジトリで検索し、デフォルトのプロジェクトアバターとして使用します。
前提要件:
- プロジェクトのメンテナー以上のロールを持っている必要があります。
- ファイルのサイズは200 KB以下である必要があります。理想的な画像サイズは192 x 192ピクセルです。
- ファイルの名前は`logo`で、拡張子は`.png`、`.jpg`、または`.gif`である必要があります。たとえば、`logo.gif`などです。
プロジェクトアバターとして使用するロゴファイルを追加するには:
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトを検索します。
1. プロジェクトリポジトリのルートで、ロゴファイルをアップロードします。
### プロジェクト設定でアバターをアップロードする
前提要件:
- プロジェクトのメンテナー以上のロールを持っている必要があります。
- ファイルのサイズは200 KB以下である必要があります。理想的な画像サイズは192 x 192ピクセルです。
- 画像は、次のいずれかのファイル形式である必要があります。
- `.bmp`
- `.gif`
- `.ico`
- `.jpeg`
- `.png`
- `.tiff`
プロジェクトの設定でアバターをアップロードするには:
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトを検索します。
1. **設定>一般**を選択します。
1. **プロジェクトアバター**セクションで、**ファイルを選択**を選択します。
1. アバターファイルを選択します。
1. **変更の保存**を選択します。
## プロジェクトにスターを付ける
頻繁に使用するプロジェクトにスターを付けて、見つけやすくすることができます。
プロジェクトにスターを付けるには:
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトを検索します。
1. ページの右上隅にある**スター**を選択します。
## プロジェクトを削除する
{{< history >}}
- GitLab 16.0で、PremiumプランとUltimateプランにおけるプロジェクトのデフォルトの削除動作が[プロジェクトの遅延削除](https://gitlab.com/gitlab-org/gitlab/-/issues/389557)に変更されました。
- GitLab 16.0の[GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/393622)および[GitLab Self-Managed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/119606)で、PremiumプランとUltimateプランにおけるデフォルトの削除動作が遅延削除に変更されました。
{{< /history >}}
プロジェクトを削除対象としてマークできます。プロジェクトを削除すると、次のようになります。
- パーソナルネームスペースのプロジェクトはすぐに削除されます。
- グループ内のプロジェクトは、保持期間後に削除されます。
前提要件:
- プロジェクトのオーナーロールを持っている必要があります。
- オーナーは[プロジェクトの削除を許可されている](../../administration/settings/visibility_and_access_controls.md#restrict-project-deletion-to-administrators)必要があります。
プロジェクトを削除するには:
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトを検索します。
1. **設定>一般**を選択します。
1. **高度な設定**を展開します。
1. **このプロジェクトを削除**セクションで、**プロジェクトを削除**を選択します。
1. 確認ダイアログで、プロジェクト名を入力し、**はい、プロジェクトを削除します**を選択します。
この操作により、プロジェクトと関連するすべてのリソース（イシューやマージリクエストなど）が削除されます。
[Railsコンソールを使用してプロジェクトを削除](troubleshooting.md#delete-a-project-using-console)することもできます。
### プロジェクトの遅延削除
{{< details >}}
- プラン: Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
{{< /details >}}
{{< history >}}
- GitLab 15.1で、[パーソナルネームスペースのプロジェクトに対して有効になりました](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/89466)。
- GitLab 15.3で、[パーソナルネームスペースのプロジェクトに対して無効になりました](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/95495)。
- GitLab 16.0の[GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/393622)と[GitLab Self-Managed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/119606)で、遅延削除がデフォルトで有効になり、即時削除のオプションが削除されました。
{{< /history >}}
前提要件:
- プロジェクトのオーナーロールを持っている必要があります。
グループ（パーソナルネームスペースではない）のプロジェクトは、遅延期間後に削除できます。
GitLab Self-Managedインスタンスでは、グループ管理者は1～90日間の削除遅延期間を定義できます。SaaSでは、調整できないデフォルトの保持期間は7日間です。
[削除保留中のプロジェクトを表示](#view-projects-pending-deletion)したり、Railsコンソールを使用して[削除保留中のプロジェクトを検索](troubleshooting.md#find-projects-that-are-pending-deletion)したりできます。
プロジェクトの削除をスケジュールしたユーザーが、削除が行われる前にプロジェクトへのアクセス権を失った場合（プロジェクを離脱したり、ロールがダウングレードされたり、プロジェクトからBANされたりした場合など）、削除ジョブは代わりにプロジェクトを復元してアーカイブ解除するため、プロジェクトは削除のスケジュールから外れます。
{{< alert type="warning" >}}
ジョブの実行前に、プロジェクトの削除をスケジュールしたユーザーがオーナーロールまたは管理者アクセス権を回復した場合、ジョブはプロジェクトを完全に削除します。
{{< /alert >}}
### プロジェクトを直ちに削除する
{{< details >}}
- プラン: Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
{{< /details >}}
{{< history >}}
- GitLab 16.0の[GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/393622)および[GitLab Self-Managed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/119606)で、**管理者**エリアからグループ設定としてプロジェクトを直ちに削除するオプションは削除されました。
{{< /history >}}
削除の遅延を待たない場合は、プロジェクトを直ちに削除できます。これを行うには、[プロジェクトの削除](#delete-a-project)手順をもう一度実行します。
プロジェクトを削除する最初のサイクルでは、プロジェクトは遅延削除キューに移され、保持期間が経過すると自動的に削除されます。この遅延削除期間中に2回目の削除サイクルを実行すると、プロジェクトは直ちに削除されます。
前提要件:
- プロジェクトのオーナーロールを持っている必要があります。
- プロジェクトは[削除対象としてマーク](#delete-a-project)されている必要があります。
削除対象としてマークされたプロジェクトを直ちに削除するには:
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトを検索します。
1. **設定>一般**を選択します。
1. **高度な設定**を展開します。
1. **このプロジェクトを削除**セクションで、**プロジェクトを削除**を選択します。
1. 確認ダイアログで、プロジェクト名を入力し、**はい、プロジェクトを削除します**を選択します。
### 削除保留中のプロジェクトを表示する
{{< details >}}
- プラン: Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
{{< /details >}}
{{< history >}}
- GitLab 17.9で、`your_work_projects_vue`という名前の[フラグとともに](../../administration/feature_flags.md)、タブのラベルが「削除の保留中」から「無効」に[変更](https://gitlab.com/groups/gitlab-org/-/epics/13066)されました。デフォルトでは無効になっています。
- GitLab 17.10で、タブのラベルの一般提供が[変更](https://gitlab.com/gitlab-org/gitlab/-/issues/465889)されました。機能フラグ`your_work_projects_vue`が削除されました。
{{< /history >}}
削除保留中のすべてのプロジェクトのリストを表示するには:
1. 左側のサイドバーで、**検索または移動**を選択します。
1. **すべてのプロジェクトを表示**を選択します。
1. **削除の保留中**タブを選択します。
{{< alert type="note" >}}
このタブは、`your_work_projects_vue`機能フラグが有効になっている場合は、**無効**として表示されます。
{{< /alert >}}
リスト内の各プロジェクトには、以下が表示されます。
- プロジェクトが削除対象としてマークされていることを示すバッジ
- プロジェクトが削除対象としてマークされた時刻
- プロジェクトが最終削除される予定の時刻
- 最終的なプロジェクトの削除を停止する**復元**アクション
## プロジェクトを復元する
{{< details >}}
- プラン: Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
{{< /details >}}
前提要件:
- プロジェクトのオーナーロールを持っている必要があります。
- プロジェクトは削除対象としてマークされている必要があります。
削除対象としてマークされたプロジェクトを復元するには:
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトを検索します。
1. **設定>一般**を選択します。
1. **高度な設定**を展開します。
1. プロジェクトの復元セクションで、**プロジェクトを復元**を選択します。
## プロジェクトをアーカイブする
{{< history >}}
- GitLab 17.5で、Pagesの削除が[導入](https://gitlab.com/gitlab-org/gitlab/-/issues/343109)されました。
{{< /history >}}
プロジェクトをアーカイブすると、一部の機能が読み取り専用になります。これらの機能は引き続きアクセスできますが、書き込みはできません。
- リポジトリ
- パッケージ
- イシュー
- マージリクエスト
- 機能フラグ
- プルミラーリング
- その他すべてのプロジェクト機能
アーカイブされたプロジェクトのアクティブなパイプラインスケジュールは、読み取り専用になりません。
プロジェクトにデプロイ済みのPagesがある場合、カスタムドメインとともに削除され、Pagesリンクにアクセスできなくなります。
アーカイブされたプロジェクトは次のようになります。
- プロジェクトページに`archived`バッジが表示されます。
- グループページ、**あなたの作業**ページ、**探す**ページの**無効**タブに表示されます。
- 読み取り専用になります。
前提要件:
- プロジェクトのアクティブなパイプラインスケジュールを[無効化](../../ci/pipelines/schedules.md#edit-a-pipeline-schedule)または削除していること。
<!-- LP: Remove this prerequisite after the issue is resolved (when a project is archived, active pipeline schedules continue to run). -->
プロジェクトをアーカイブするには:
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトを検索します。
1. **設定>一般**を選択します。
1. **高度な設定**を展開します。
1. **プロジェクトをアーカイブ**セクションで、**プロジェクトをアーカイブ**を選択します。
1. 確認するには、**OK**をクリックします。
## プロジェクトをアーカイブ解除する
プロジェクトをアーカイブ解除すると、読み取り専用の制限が解除され、プロジェクトリストでプロジェクトを使用できるようになります。
前提要件:
- 管理者であるか、プロジェクトのオーナーロールを持っている必要があります。
1. アーカイブされたプロジェクトを検索します。
1. 左側のサイドバーで、**検索または移動**を選択します。
1. **すべてのプロジェクトを表示**を選択します。
1. **プロジェクトを探す**を選択します。
1. **プロジェクトの並べ替え**ドロップダウンリストで、**アーカイブしたプロジェクトを表示**を選択します。
1. **名前で絞り込む**フィールドに、プロジェクト名を入力します。
1. プロジェクトリンクを選択します。
1. 左側のサイドバーで、**設定>一般**を選択します。
1. **高度な設定**で、**展開**を選択します。
1. **プロジェクトのアーカイブ解除**セクションで、**プロジェクトのアーカイブ解除**を選択します。
1. 確認するには、**OK**をクリックします。
デプロイ済みのPagesは復元されないため、パイプラインを再実行する必要があります。
プロジェクトをアーカイブ解除すると、プルミラーリングプロセスが自動的に再開されます。
## プロジェクトアクティビティーを表示する
プロジェクトのアクティビティーを表示するには:
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトを検索します。
1. **管理>アクティビティー**を選択します。
1. オプション: コントリビュートの種類でアクティビティーをフィルタリングするには、次のタブを選択します。
- **すべて**: プロジェクトメンバーによるすべてのコントリビュート
- **プッシュイベント**: プロジェクト内のプッシュイベント
- **マージイベント**: プロジェクトで承認されたマージリクエスト
- **イシューイベント**: プロジェクトでオープンおよびクローズされたイシュー
- **コメント**: プロジェクトメンバーが投稿したコメント
- **デザイン**: プロジェクトで追加、更新、削除されたデザイン
- **チーム**: プロジェクトに参加および離脱したメンバー
### イベント期間の制限
GitLabは、パフォーマンス上の理由から、3年以上前のプロジェクトアクティビティーイベントをイベントテーブルから削除します。
## プロジェクト内を検索する
プロジェクト内を検索するには、左側のサイドバーで**検索または移動**を選択します。入力すると、GitLabによって絞り込まれます。
[お気に入り](#star-a-project)に登録したプロジェクト（**Star付きのプロジェクト**）を探すこともできます。
GitLab.comで利用可能なすべてのパブリックプロジェクトと内部プロジェクトを**探す**ことが可能で、表示レベルで絞り込んだり、**トレンド**、**最もお気に入りに登録**で最高評価を得ているもの、または**すべて**で検索できます。
プロジェクトは以下で並べ替えることができます:
- 名前
- 作成日
- 更新日
- お気に入り
### 言語でプロジェクトをフィルタリングする
{{< history >}}
- GitLab 15.9で、`project_language_search`という名前の[フラグとともに](../../administration/feature_flags.md)[導入](https://gitlab.com/gitlab-org/gitlab/-/issues/385465)されました。デフォルトで有効になりました。
- GitLab 15.9で[一般提供](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/110956)になりました。機能フラグ`project_language_search`が削除されました。
{{< /history >}}
使用されているプログラミング言語でプロジェクトをフィルタリングできます。以下を実行します。
1. 左側のサイドバーで、**検索または移動**を選択します。
1. 次のいずれかを選択します。
- **すべてのプロジェクトを表示**: プロジェクトをフィルタリングします。
- **探す**: アクセスできるすべてのプロジェクトをフィルタリングします。
1. プロジェクトリストの上にある**検索または結果をフィルタリング**を選択します。
1. **言語**ドロップダウンリストで、プロジェクトのフィルタリングに使用する言語を選択します。
選択した言語を使用するプロジェクトのリストが表示されます。
### 自分が所有するプロジェクトのみを表示する
自分がオーナーであるプロジェクトのみを表示するには:
1. 左側のサイドバーで、**検索または移動**を選択します。
1. 次のいずれかを選択します。
- **すべてのプロジェクトを表示**: プロジェクトをフィルタリングします。
- **探す**: アクセスできるすべてのプロジェクトをフィルタリングします。
1. プロジェクトリストの上にある**検索または結果をフィルタリング**を選択します。
1. **ロール**ドロップダウンリストで、**オーナー**を選択します。
## リポジトリの名前を変更する
プロジェクトのリポジトリ名は、そのURLと、GitLabがインストールされているファイルディスク上の場所を定義します。
前提要件:
- 管理者であるか、プロジェクトのメンテナーまたはオーナーのロールを持っている必要があります。
{{< alert type="note" >}}
リポジトリパスを変更すると、ユーザーが古いURLにプッシュまたはプルした場合に問題が発生する可能性があります。リダイレクト期間とその副作用の詳細については、[リポジトリの名前変更時のリダイレクト](repository/_index.md#repository-path-changes)を参照してください。
{{< /alert >}}
リポジトリの名前を変更するには:
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトを検索します。
1. **設定>一般**を選択します。
1. **高度な設定**を展開します。
1. **パスを変更**テキストボックスで、パスを編集します。
1. **パスを変更**を選択します。
## プロジェクトを離脱する
{{< history >}}
- GitLab 16.7で、プロジェクトを離脱するためのボタンがアクションメニューに[移動](https://gitlab.com/gitlab-org/gitlab/-/issues/431539)しました。
{{< /history >}}
プロジェクトを離脱すると、次のようになります。
- プロジェクトメンバーではなくなり、コントリビュートできなくなります。
- 割り当てられていたすべてのイシューとマージリクエストの割り当てが解除されます。
前提要件:
- プロジェクトが[グループネームスペース](../namespace/_index.md)のグループの一部である場合にのみ、この方法でプロジェクトを離脱できます。
- プロジェクトの[直接メンバー](members/_index.md#membership-types)である必要があります。
プロジェクトを離脱するには:
1. 左側のサイドバーで、**検索または移動**を選択し、プロジェクトを検索します。
1. プロジェクトの概要ページの右上隅で、**アクション**（{{< icon name="ellipsis_v" >}}）を選択します。
1. **プロジェクトを離脱**を選択し、もう一度**プロジェクトを離脱**を選択します。
## プロジェクトにコンプライアンスフレームワークを追加する
{{< details >}}
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
{{< /details >}}
[コンプライアンスフレームワーク](../compliance/compliance_frameworks.md)があるグループのプロジェクトにコンプライアンスフレームワークを追加できます。
## LDAPグループを介してプロジェクトへのアクセスを管理する
[LDAPを使用してグループメンバーシップを管理](../group/access_and_permissions.md#manage-group-memberships-with-ldap)できます。
LDAPグループを使用してプロジェクトへのアクセスを管理することはできませんが、次の回避策を使用できます。
前提要件:
- [LDAPをGitLabと統合](../../administration/auth/ldap/_index.md)する必要があります。
- 管理者である必要があります。
1. プロジェクトのメンバーシップを追跡するための[グループを作成](../group/_index.md#create-a-group)します。
1. そのグループの[LDAP同期を設定](../../administration/auth/ldap/ldap_synchronization.md)します。
1. LDAPグループを使用してプロジェクトへのアクセスを管理するには、[LDAP同期されたグループをメンバーとして追加](../group/manage.md)します。
## プロジェクトエイリアス
{{< details >}}
- プラン: Premium、Ultimate
- 提供形態: GitLab Self-Managed、GitLab Dedicated
{{< /details >}}
通常、GitLabリポジトリには、ネームスペースとプロジェクト名を使用してアクセスします。ただし、頻繁にアクセスされるリポジトリをGitLabに移行する場合は、プロジェクトエイリアスを使用して、元の名前でそれらのリポジトリにアクセスできます。プロジェクトエイリアスを介してリポジトリにアクセスすると、そのようなリポジトリの移行に関連するリスクが軽減されます。
この機能は、SSH経由のGitでのみ使用できます。また、プロジェクトエイリアスを作成できるのはGitLab管理者のみであり、APIを介してのみ作成できます。詳細については、[プロジェクトエイリアスAPIドキュメント](../../api/project_aliases.md)を参照してください。
管理者がプロジェクトのエイリアスを作成すると、そのエイリアスを使用してリポジトリのクローンを作成できます。たとえば、管理者がプロジェクト`https://gitlab.com/gitlab-org/gitlab`のエイリアス`gitlab`を作成した場合、`git clone git@gitlab.com:gitlab-org/gitlab.git`の代わりに`git clone git@gitlab.com:gitlab.git`を使用してプロジェクトのクローンを作成できます。
## 関連トピック
- [プロジェクトをインポートする](import/_index.md)
- [外部リポジトリをGitLab CI/CDに接続する](../../ci/ci_cd_for_external_repos/_index.md)
- [プロジェクトをフォークする](repository/forking_workflow.md#create-a-fork)
- [プロジェクトの表示レベル](../public_access.md#change-project-visibility)と[権限](settings/_index.md#configure-project-features-and-permissions)を調整する
- [プロジェクト名とグループ名のルール](../reserved_names.md#rules-for-usernames-project-and-group-names-and-slugs)

540
doc-locale/ja-jp/user/ssh.md Normal file
View File

@ -0,0 +1,540 @@
---
stage: Software Supply Chain Security
group: Authentication
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: SSH鍵を使用してGitLabと通信する
---
{{< details >}}
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
{{< /details >}}
Gitは分散型バージョン管理システムです。ローカルで作業してから、変更をサーバーに共有または*プッシュ*できます。この場合、プッシュ先のサーバーはGitLabです。
GitLabはSSHプロトコルを使用して、Gitと安全に通信します。SSH鍵を使用してGitLabリモートサーバーに対して認証する場合、毎回ユーザー名とパスワードを入力する必要はありません。
## SSH鍵とは
SSHは、公開キーと秘密キーの2つのキーを使用します。
- 公開キーは配布できます。
- 秘密キーは保護する必要があります。
公開キーをアップロードしても、機密データが漏えいすることはありません。SSH公開鍵をコピーまたはアップロードする必要がある場合は、誤って秘密キーをコピーまたはアップロードしないように注意してください。
秘密キーを使用して[コミットに署名する](project/repository/signed_commits/ssh.md)と、GitLabの使用とデータの安全性がさらに向上します。この署名は、公開キーを使用して誰でも検証できます。
詳細については、[公開鍵暗号としても知られる非対称暗号](https://en.wikipedia.org/wiki/Public-key_cryptography)を参照してください。
## 前提要件
SSHを使用してGitLabと通信するには、以下が必要です。
- GNU/Linux、macOS、およびWindows 10にプリインストールされているOpenSSHクライアント。
- SSHバージョン6.5以降。以前のバージョンではMD5署名を使用していましたが、これは安全ではありません。
システムにインストールされているSSHのバージョンを表示するには、`ssh -V`を実行します。
## サポートされているSSH鍵の種類
GitLabとの通信には、次の種類のSSH鍵を使用できます。
- [ED25519](#ed25519-ssh-keys)
- [ED25519_SK](#ed25519_sk-ssh-keys)
- [ECDSA_SK](#ecdsa_sk-ssh-keys)
- [RSA](#rsa-ssh-keys)
- ECDSA（『[Practical Cryptography With Go](https://leanpub.com/gocrypto/read#leanpub-auto-ecdsa)』で述べられているように、DSAに関連するセキュリティ上の問題はECDSAにも適用されます）。
管理者は、[許可されるキーとその最小長を制限](../security/ssh_keys_restrictions.md)できます。
### ED25519 SSH鍵
『[Practical Cryptography With Go](https://leanpub.com/gocrypto/read#leanpub-auto-chapter-5-digital-signatures)』の書籍では、[ED25519](https://ed25519.cr.yp.to/)キーはRSAキーよりも安全で高性能であることが示唆されています。
OpenSSH 6.5は、2014年にED25519 SSH鍵を導入するなど、ほとんどのオペレーティングシステムで利用可能になっています。
{{< alert type="note" >}}
ED25519キーは、すべてのFIPSシステムで完全にサポートされていない可能性があります。詳細については、[イシュー367429](https://gitlab.com/gitlab-org/gitlab/-/issues/367429)を参照してください。
{{< /alert >}}
### ED25519_SK SSH鍵
GitLabでED25519_SK SSH鍵を使用するには、ローカルクライアントとGitLabサーバーに[OpenSSH 8.2](https://www.openssh.com/releasenotes.html#8.2)以降がインストールされている必要があります。
### ECDSA_SK SSH鍵
GitLabでECDSA_SK SSH鍵を使用するには、ローカルクライアントとGitLabサーバーに[OpenSSH 8.2](https://www.openssh.com/releasenotes.html#8.2)以降がインストールされている必要があります。
### RSA SSH鍵
{{< history >}}
- GitLab 16.3で、RSAキーの最大長が[変更](https://gitlab.com/groups/gitlab-org/-/epics/11186)されました。
{{< /history >}}
入手可能なドキュメントでは、ED25519がRSAよりも安全であることが示唆されています。
RSAキーを使用する場合、米国立標準技術研究所の「[Publication 800-57 Part 3（PDF）](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57Pt3r1.pdf)」では、少なくとも2048ビットのキーサイズが推奨されています。Goの制限により、RSAキーは[8192ビットを超えることはできません](ssh_troubleshooting.md#tls-server-sent-certificate-containing-rsa-key-larger-than-8192-bits)。
デフォルトのキーサイズは、`ssh-keygen`のバージョンによって異なります。詳細については、インストールされている`ssh-keygen`コマンドの`man`ページを参照してください。
## 既存のSSH鍵ペアの有無を確認する
キーペアを作成する前に、キーペアがすでに存在するかどうかを確認します。
1. ホームディレクトリに移動します。
1. `.ssh/`サブディレクトリに移動します。`.ssh/`サブディレクトリが存在しない場合は、ホームディレクトリにいないか、以前に`ssh`を使用したことがありません。後者の場合は、[SSH鍵ペアを生成](#generate-an-ssh-key-pair)する必要があります。
1. 次のいずれかの形式のファイルが存在するかどうかを確認します。
| アルゴリズム | 公開キー | 秘密キー |
|-----------------------|------------|-------------|
| ED25519（推奨） | `id_ed25519.pub` | `id_ed25519` |
| ED25519_SK | `id_ed25519_sk.pub` | `id_ed25519_sk` |
| ECDSA_SK | `id_ecdsa_sk.pub` | `id_ecdsa_sk` |
| RSA（少なくとも2048ビットのキーサイズ） | `id_rsa.pub` | `id_rsa` |
| DSA（非推奨） | `id_dsa.pub` | `id_dsa` |
| ECDSA | `id_ecdsa.pub` | `id_ecdsa` |
## SSH鍵ペアを生成する
既存のSSH鍵ペアがない場合は、新しいキーペアを生成します。
1. ターミナルを開きます。
1. `ssh-keygen -t`の後にキータイプとオプションのコメントを入力して実行します。このコメントは、作成される`.pub`ファイルに含まれます。コメントにメールアドレスを使用することもできます。
たとえば、ED25519の場合は次のようになります。
```shell
ssh-keygen -t ed25519 -C "<comment>"
```
2048ビットRSAの場合:
```shell
ssh-keygen -t rsa -b 2048 -C "<comment>"
```
1. <kbd>Enter</kbd>キーを押します。次のような出力が表示されます。
```plaintext
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/user/.ssh/id_ed25519):
```
1. [デプロイキー](project/deploy_keys/_index.md)を生成する場合、または他のキーを格納する特定のディレクトリに保存する場合を除き、推奨されるファイル名とディレクトリを受け入れます。
SSH鍵ペアを[特定のホスト専用](#configure-ssh-to-point-to-a-different-directory)にすることもできます。
1. [パスフレーズ](https://www.ssh.com/academy/ssh/passphrase)を指定します。
```plaintext
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
```
ファイルが保存されている場所に関する情報を含む確認メッセージが表示されます。
公開キーと秘密キーが生成されます。[GitLabアカウントに公開SSH鍵を追加](#add-an-ssh-key-to-your-gitlab-account)し、秘密キーを安全に保管してください。
### 別のディレクトリを指すようにSSHを設定する
デフォルトディレクトリにSSH鍵ペアを保存しなかった場合は、秘密キーが保存されているディレクトリを指すようにSSHクライアントを設定します。
1. ターミナルを開き、次のコマンドを実行します。
```shell
eval $(ssh-agent -s)
ssh-add <directory to private SSH key>
```
1. これらの設定を`~/.ssh/config`ファイルに保存します。次に例を示します。
```conf
# GitLab.com
Host gitlab.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/gitlab_com_rsa
# Private GitLab instance
Host gitlab.company.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/example_com_rsa
```
これらの設定の詳細については、SSH設定マニュアルの[`man ssh_config`](https://man.openbsd.org/ssh_config)ページを参照してください。
公開SSH鍵はアカウントにバインドされるため、GitLabで一意である必要があります。SSH鍵は、SSHでコードをプッシュするときに使用する唯一の識別子です。単一のユーザーに一意にマップする必要があります。
### SSH鍵のパスフレーズを更新する
次の手順で、SSH鍵のパスフレーズを更新できます。
1. ターミナルを開き、次のコマンドを実行します。
```shell
ssh-keygen -p -f /path/to/ssh_key
```
1. プロンプトが表示されたら、パスフレーズを入力して<kbd>Enter</kbd>を押します。
### RSAキーペアをより安全な形式にアップグレードする
OpenSSHのバージョンが6.5～7.8の場合は、ターミナルを開いて次のコマンドを実行することにより、秘密RSA SSH鍵をより安全なOpenSSH形式で保存できます。
```shell
ssh-keygen -o -f ~/.ssh/id_rsa
```
または、次のコマンドを実行して、より安全な暗号化形式で新しいRSAキーを生成することもできます。
```shell
ssh-keygen -o -t rsa -b 4096 -C "<comment>"
```
## FIDO2ハードウェアセキュリティキーのSSH鍵ペアを生成する
ED25519_SKまたはECDSA_SK SSH鍵を生成するには、OpenSSH 8.2以降を使用する必要があります。
1. ハードウェアセキュリティキーをコンピューターに挿入します。
1. ターミナルを開きます。
1. `ssh-keygen -t`の後にキータイプとオプションのコメントを入力して実行します。このコメントは、作成される`.pub`ファイルに含まれます。コメントにメールアドレスを使用することもできます。
たとえば、ED25519_SKの場合は次のようになります。
```shell
ssh-keygen -t ed25519-sk -C "<comment>"
```
ECDSA_SKの場合:
```shell
ssh-keygen -t ecdsa-sk -C "<comment>"
```
セキュリティキーがFIDO2レジデントキーをサポートしている場合は、SSH鍵の作成時に有効にできます。
```shell
ssh-keygen -t ed25519-sk -O resident -C "<comment>"
```
`-O resident`は、キーをFIDO認証器自体に保存する必要があることを示します。レジデントキーは、[`ssh-add -K`](https://man.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/ssh-add.1#K)または[`ssh-keygen -K`](https://man.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/ssh-keygen#K)によってセキュリティキーから直接読み込むことができるため、新しいコンピューターへのインポートが簡単です。
1. <kbd>Enter</kbd>キーを押します。次のような出力が表示されます。
```plaintext
Generating public/private ed25519-sk key pair.
You may need to touch your authenticator to authorize key generation.
```
1. ハードウェアセキュリティキーのボタンを押します。
1. 推奨されるファイル名とディレクトリを受け入れます。
```plaintext
Enter file in which to save the key (/home/user/.ssh/id_ed25519_sk):
```
1. [パスフレーズ](https://www.ssh.com/academy/ssh/passphrase)を指定します。
```plaintext
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
```
ファイルが保存されている場所に関する情報を含む確認メッセージが表示されます。
公開キーと秘密キーが生成されます。[GitLabアカウントにSSH公開鍵を追加](#add-an-ssh-key-to-your-gitlab-account)します。
## パスワードマネージャーでSSH鍵ペアを生成する
### 1PasswordでSSH鍵ペアを生成する
[1Password](https://1password.com/)と[1Passwordブラウザ拡張機能](https://support.1password.com/getting-started-browser/)を使用して、次のいずれかを行うことができます。
- 新しいSSH鍵を自動的に生成する。
- 1Password Vaultにある既存のSSH鍵を使用してGitLabで認証する。
1. GitLabにサインインします。
1. 左側のサイドバーで、アバターを選択します。
1. **プロファイルを編集**を選択します。
1. 左側のサイドバーで**SSH鍵**を選択します。
1. **新しいキーを追加**を選択します。
1. **キー**を選択すると、1Passwordヘルパーが表示されます。
1. 1Passwordアイコンをクリックし、1Passwordのロックを解除します。
1. **SSHキーを作成**を選択するか、既存のSSH鍵を選択して公開キーを入力できます。
1. **タイトル**ボックスに、`Work Laptop`や`Home Workstation`などの説明を入力します。
1. オプション: キーの**使用タイプ**を選択します。`Authentication`または`Signing`のいずれか、またはその両方に使用できます。`Authentication & Signing`がデフォルト値です。
1. オプション: **有効期限**を更新して、デフォルトの有効期限を変更します。
1. **キーを追加**を選択します。
1PasswordでSSH鍵を使用する詳細については、[1Passwordのドキュメント](https://developer.1password.com/docs/ssh/get-started/)を参照してください。
## GitLabアカウントにSSH鍵を追加する
{{< history >}}
- GitLab 15.4で、キーに推奨されるデフォルトの有効期限が[導入](https://gitlab.com/gitlab-org/gitlab/-/issues/271239)されました。
- GitLab 15.7で、SSH鍵の使用タイプが[追加](https://gitlab.com/gitlab-org/gitlab/-/issues/383046)されました。
{{< /history >}}
SSHをGitLabで使用するには、公開キーをGitLabアカウントにコピーします。
1. 公開キーファイルの内容をコピーします。これは手動で行うことも、スクリプトを使用することもできます。たとえば、次のようにED25519キーをクリップボードにコピーします。
**macOS**
```shell
tr -d '\n' < ~/.ssh/id_ed25519.pub | pbcopy
```
**Linux**（`xclip`パッケージが必要です）
```shell
xclip -sel clip < ~/.ssh/id_ed25519.pub
```
**Windows上のGit Bash**
```shell
cat ~/.ssh/id_ed25519.pub | clip
```
`id_ed25519.pub`をファイル名に置き換えます。たとえば、RSAには`id_rsa.pub`を使用します。
1. GitLabにサインインします。
1. 左側のサイドバーで、アバターを選択します。
1. **プロファイルを編集**を選択します。
1. 左側のサイドバーで**SSH鍵**を選択します。
1. **新しいキーを追加**を選択します。
1. **キー**ボックスに、公開キーの内容を貼り付けます。キーを手動でコピーする場合は、必ずキー全体をコピーしてください。`ssh-rsa`、`ssh-dss`、`ecdsa-sha2-nistp256`、`ecdsa-sha2-nistp384`、`ecdsa-sha2-nistp521`、`ssh-ed25519`、`sk-ecdsa-sha2-nistp256@openssh.com`、または`sk-ssh-ed25519@openssh.com`で始まり、コメントで終わる可能性があります。
1. **タイトル**ボックスに、`Work Laptop`や`Home Workstation`などの説明を入力します。
1. オプション: キーの**使用タイプ**を選択します。`Authentication`または`Signing`のいずれか、またはその両方に使用できます。`Authentication & Signing`がデフォルト値です。
1. オプション: **有効期限**を更新して、デフォルトの有効期限を変更します。
- 管理者は有効期限を表示し、[キーを削除](../administration/credentials_inventory.md#delete-ssh-keys)する際のガイダンスとして使用できます。
- GitLabは毎日午前01:00（UTC）にすべてのSSH鍵をチェックします。7日後に期限切れになるすべてのSSH鍵について、有効期限をメールで通知します。
- GitLabは毎日午前02:00（UTC）にすべてのSSH鍵をチェックします。今日の日付で期限切れになるすべてのSSH鍵について、有効期限をメールで通知します。
1. **キーを追加**を選択します。
## 接続できることを確認する
SSH鍵が正しく追加されたことを確認します。
次のコマンドでは、ホスト名の例として`gitlab.example.com`を使用しています。このホスト名の例を、GitLabインスタンスのホスト名（例: `git@gitlab.com`）に置き換えます。デフォルトでは、GitLabは認証に`git`ユーザー名を使用します。[管理者によって変更された](https://docs.gitlab.com/omnibus/settings/configuration.html#change-the-name-of-the-git-user-or-group)場合は、異なる場合があります。
1. 正しいサーバーに接続していることを確認するには、サーバーのSSHホストキーのフィンガープリントを確認してください。次のようにします。
- GitLab.comについては、[SSHホストキーのフィンガープリント](gitlab_com/_index.md#ssh-host-keys-fingerprints)に関するドキュメントを参照してください。
- GitLab.comまたは別のGitLabインスタンスの場合は、`gitlab.example.com/help/instance_configuration#ssh-host-keys-fingerprints`を参照してください。`gitlab.example.com`は`gitlab.com`（GitLab.comの場合）またはGitLabインスタンスのアドレスです。
1. ターミナルを開き、次のコマンドを実行します。`gitlab.example.com`はGitLabインスタンスのURLに置き換えてください。
```shell
ssh -T git@gitlab.example.com
```
1. 今回が初めての接続の場合は、GitLabホストの信頼性を確認する必要があります。次のようなメッセージが表示された場合:
```plaintext
The authenticity of host 'gitlab.example.com (35.231.145.151)' can't be established.
ECDSA key fingerprint is SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'gitlab.example.com' (ECDSA) to the list of known hosts.
```
`yes`と入力して<kbd>Enter</kbd>キーを押します。
1. `ssh -T git@gitlab.example.com`コマンドを再度実行します。「_GitLabへようこそ、`@username`さん！_」というメッセージが表示されます。
ウェルカムメッセージが表示されない場合は、verboseモードで`ssh`を実行して問題を解決することができます。
```shell
ssh -Tvvv git@gitlab.example.com
```
## リポジトリごとに異なるキーを使用する
リポジトリごとに異なるキーを使用できます。
ターミナルを開き、次のコマンドを実行します。
```shell
git config core.sshCommand "ssh -o IdentitiesOnly=yes -i ~/.ssh/private-key-filename-for-this-repository -F /dev/null"
```
このコマンドはSSHエージェントを使用せず、Git 2.10以降が必要です。`ssh`コマンドオプションの詳細については、`ssh`と`ssh_config`の両方の`man`ページを参照してください。
## SSH鍵を表示する
アカウントのSSH鍵を表示するには:
1. 左側のサイドバーで、アバターを選択します。
1. **プロファイルを編集**を選択します。
1. 左側のサイドバーで**SSH鍵**を選択します。
既存のSSH鍵がページの下部に一覧表示されます。情報には以下が含まれます。
- キーのタイトル
- 公開フィンガープリント
- 許可されている使用タイプ
- 作成日
- 最終使用日
- 有効期限
## SSH鍵を削除する
SSH鍵を取り消すか削除して、アカウントから完全に削除できます。
キーでコミットに署名している場合、SSH鍵を削除すると他にも影響があります。詳細については、「[削除されたSSH鍵で署名されたコミット](project/repository/signed_commits/ssh.md#signed-commits-with-removed-ssh-keys)」を参照してください。
### SSH鍵を取り消す
{{< history >}}
- GitLab 15.9で[導入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/108344)されました。
{{< /history >}}
SSH鍵が侵害された場合は、キーを取り消します。
前提要件:
- SSH鍵には、`Signing`または`Authentication & Signing`の使用タイプが必要です。
SSH鍵を取り消すには:
1. 左側のサイドバーで、アバターを選択します。
1. **プロファイルを編集**を選択します。
1. 左側のサイドバーで**SSH鍵**を選択します。
1. 取り消すSSH鍵の横にある**取り消し**を選択します。
1. **取り消し**を選択します。
### SSH鍵を削除する
SSH鍵を削除するには:
1. 左側のサイドバーで、アバターを選択します。
1. **プロファイルを編集**を選択します。
1. 左側のサイドバーで**SSH鍵**を選択します。
1. 削除するキーの横にある**削除**（{{< icon name="remove" >}}）を選択します。
1. **削除**を選択します。
## 単一のGitLabインスタンスで異なるアカウントを使用する
複数のアカウントを使用して、GitLabの単一インスタンスに接続できます。これを行うには、[前のトピック](#use-different-keys-for-different-repositories)のコマンドを使用します。ただし、`IdentitiesOnly`を`yes`に設定しても、`IdentityFile`が`Host`ブロックの外に存在する場合はサインインできません。
代わりに、`~/.ssh/config`ファイルでホストにエイリアスを割り当てることができます。
- `Host`には、`user_1.gitlab.com`や`user_2.gitlab.com`のようなエイリアスを使用します。高度な設定は保持するのが難しいため、`git remote`のようなツールを使用すると、これらの文字列が理解しやすくなります。
- `IdentityFile`には、プライベートキーのパスを使用します。
```conf
# User1 Account Identity
Host <user_1.gitlab.com>
Hostname gitlab.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/<example_ssh_key1>
# User2 Account Identity
Host <user_2.gitlab.com>
Hostname gitlab.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/<example_ssh_key2>
```
ここで、`user_1`のリポジトリのクローンを作成するには、`git clone`コマンドで`user_1.gitlab.com`を使用します。
```shell
git clone git@<user_1.gitlab.com>:gitlab-org/gitlab.git
```
`origin`としてエイリアスされていて、前にクローンが作成されたリポジトリを更新するには、次のコマンドを実行します。
```shell
git remote set-url origin git@<user_1.gitlab.com>:gitlab-org/gitlab.git
```
{{< alert type="note" >}}
プライベートキーと公開キーには機密データが含まれています。ファイルに対する権限を調節し、自分だけが読み取り可能で他のユーザーはアクセスできないようにしてください。
{{< /alert >}}
## 2要素認証（2FA）を設定する
[Git over SSH](../security/two_factor_authentication.md#2fa-for-git-over-ssh-operations)に2要素認証（2FA）を設定できます。[ED25519_SK](#ed25519_sk-ssh-keys)または[ECDSA_SK](#ecdsa_sk-ssh-keys) SSH鍵を使用する必要があります。
## EclipseでEGitを使用する
[EGit](https://projects.eclipse.org/projects/technology.egit)を使用している場合は、[EclipseにSSH鍵を追加](https://wiki.eclipse.org/EGit/User_Guide/#Eclipse_SSH_Configuration)できます。
## Microsoft WindowsでSSHを使用する
Windows 10を実行している場合は、`git`と`ssh`の両方がプリインストールされている[WSL 2](https://learn.microsoft.com/en-us/windows/wsl/install#update-to-wsl-2)で[Linux用Windowsサブシステム（WSL）](https://learn.microsoft.com/en-us/windows/wsl/install)を使用するか、[Git for Windows](https://gitforwindows.org)をインストールしてPowerShell経由でSSHを使用できます。
WSLで生成されたSSH鍵は、Git for Windowsでは直接利用できません。どちらもホームディレクトリが異なるためです。
- WSL: `/home/<user>`
- Git for Windows: `C:\Users\<user>`
同じキーを使用するには、`.ssh/`ディレクトリをコピーするか、各環境でキーを生成します。
Windows 11を実行していて、[OpenSSH for Windows](https://learn.microsoft.com/en-us/windows-server/administration/OpenSSH/openssh-overview)を使用している場合は、`HOME`環境変数が正しく設定されていることを確認してください。正しく設定されていない場合は、プライベートSSH鍵が見つからない可能性があります。
代替ツールは次のとおりです。
- [Cygwin](https://www.cygwin.com)
- [PuTTYgen](https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html) 0.81以降（以前のバージョンは[開示攻撃に対して脆弱](https://www.openwall.com/lists/oss-security/2024/04/15/6)です）
## GitLabサーバー上のSSH設定をオーバーライドする
GitLabはシステムにインストールされたSSHデーモンと統合し、すべてのアクセス要求を処理するユーザー（通常は`git`という名前）を指定します。SSH経由でGitLabサーバーに接続するユーザーは、ユーザー名ではなくSSH鍵によって識別されます。
GitLabサーバーで実行されるSSH*クライアント*操作は、このユーザーとして実行されます。このSSH 設定は変更できます。たとえば、認証リクエストに使用するプライベートSSH鍵をこのユーザーに指定できます。ただし、この方法は**サポートされていません**。重大なセキュリティリスクがあるため、使用しないことを強くおすすめします。
GitLabはこの状態をチェックし、サーバーがこの方法で設定されている場合は、このセクションに誘導します。次に例を示します。
```shell
$ gitlab-rake gitlab:check
Git user has default SSH configuration? ... no
Try fixing it:
mkdir ~/gitlab-check-backup-1504540051
sudo mv /var/lib/git/.ssh/id_rsa ~/gitlab-check-backup-1504540051
sudo mv /var/lib/git/.ssh/id_rsa.pub ~/gitlab-check-backup-1504540051
For more information see:
doc/user/ssh.md#overriding-ssh-settings-on-the-gitlab-server
Please fix the error above and rerun the checks.
```
できるだけ早くカスタム設定を削除してください。これらのカスタマイズは**明示的にサポートされていません**。予告なく動作しなくなる可能性があります。
## GitLab SSHの所有権と権限を確認する
GitLab SSHフォルダーとファイルには、次の権限が必要です。
- `/var/opt/gitlab/.ssh/`フォルダーは、`git`グループと`git`ユーザーが所有し、権限は`700`に設定する必要があります。
- `authorized_keys`ファイルの権限は`600`に設定する必要があります。
- `authorized_keys.lock`ファイルの権限は`644`に設定する必要があります。
これらの権限が正しいことを検証するには、次のコマンドを実行します。
```shell
stat -c "%a %n" /var/opt/gitlab/.ssh/.
```
### 権限を設定する
権限が間違っている場合は、アプリケーションサーバーにサインインして、次のコマンドを実行します。
```shell
cd /var/opt/gitlab/
chown git:git /var/opt/gitlab/.ssh/
chmod 700 /var/opt/gitlab/.ssh/
chmod 600 /var/opt/gitlab/.ssh/authorized_keys
chmod 644 /var/opt/gitlab/.ssh/authorized_keys.lock
```

16
doc/administration/auth/ldap/ldap-troubleshooting.md
View File

@ -127,7 +127,7 @@ following is most likely true:
- The users don't fall under the [configured `base`](_index.md#configure-ldap).
- The [configured `user_filter`](_index.md#set-up-ldap-user-filter) blocks access to the users.
In this case, you con confirm which of the above is true using
In this case, you can confirm which of the previous is true using
[ldapsearch](#ldapsearch) with the existing LDAP configuration in your
`/etc/gitlab/gitlab.rb`.
@ -143,7 +143,7 @@ here are some questions to ask yourself:
user must also pass through this filter to be allowed to sign in.
- Refer to our documentation on [debugging the `user_filter`](#debug-ldap-user-filter).
If the above are both okay, the next place to look for the problem is
If the previous questions are both okay, the next place to look for the problem is
the logs themselves while reproducing the issue.
- Ask the user to sign in and let it fail.
@ -424,18 +424,18 @@ things to debug the situation.
and press **Sync now** (sync one group) or [run the group sync Rake task](../../raketasks/ldap.md#run-a-group-sync)
(sync all groups).
If all of the above looks good, jump in to a little more advanced debugging in
If all of the checks looks good, jump in to a little more advanced debugging in
the rails console.
1. Enter the [rails console](#rails-console).
1. Choose a GitLab group to test with. This group should have an LDAP group link
already configured.
1. [Enable debug logging, find the above GitLab group, and sync it with LDAP](#sync-one-group).
1. Enable debug logging, find the chosen GitLab group, and [sync it with LDAP](#sync-one-group).
1. Look through the output of the sync. See [example log output](#example-console-output-after-a-group-sync)
for how to read the output.
1. If you still aren't able to see why the user isn't being added, [query the LDAP group directly](#query-a-group-in-ldap)
to see what members are listed.
1. Is the user's DN or UID in one of the lists from the above output? One of the DNs or
1. Is the user's DN or UID in one of the lists from the queried group? One of the DNs or
UIDs here should match the 'Identifier' from the LDAP identity checked earlier. If it doesn't,
the user does not appear to be in the LDAP group.
@ -449,7 +449,7 @@ To resolve this issue in GitLab 16.8 and later, you can invite service accounts
When [Administrator sync](ldap_synchronization.md#administrator-sync) has been configured
but the configured users aren't granted the correct administrator privileges, confirm
the following are true:
that the following conditions are true:
- A [`group_base` is also configured](ldap_synchronization.md#group-sync).
- The configured `admin_group` in the `gitlab.rb` is a CN, rather than a DN or an array.
@ -458,7 +458,7 @@ the following are true:
credentials. GitLab only grants administrator access to the users whose
accounts are already connected to LDAP.
If all the above are true and the users are still not getting access,
If all the previous conditions are true and the users are still not getting access,
[run a manual group sync](#sync-all-groups) in the rails console and
[look through the output](#example-console-output-after-a-group-sync) to see what happens when
GitLab syncs the `admin_group`.
@ -569,7 +569,7 @@ Members in 'ldap_group_1' LDAP group: ["uid=john0,ou=people,dc=example,dc=com",
"uid=mary4,ou=people,dc=example,dc=com"]
```
Shortly after each of the above entries, you see a hash of resolved member
Shortly after each of the entries, you see a hash of resolved member
access levels. This hash represents all user DNs GitLab thinks should have
access to this group, and at which access level (role). This hash is additive,
and more DNs may be added, or existing entries modified, based on additional

2
doc/administration/auth/oidc.md
View File

@ -490,7 +490,7 @@ Add the [provider's configuration](https://docs.gitlab.com/charts/charts/globals
{{< /tabs >}}
As you migrate from `azure_oauth2` to `omniauth_openid_connect` as part of upgrading to GitLab 17.0 or above, the `sub` claim value set for your organization can vary. `azure_oauth2` uses Microsoft V1 endpoint while `azure_activedirectory_v2` and `omniauth_openid_connect` both use Microsoft V2 endpoint with a common `sub` value.
As you migrate from `azure_oauth2` to `omniauth_openid_connect` as part of upgrading to GitLab 17.0 or later, the `sub` claim value set for your organization can vary. `azure_oauth2` uses Microsoft V1 endpoint while `azure_activedirectory_v2` and `omniauth_openid_connect` both use Microsoft V2 endpoint with a common `sub` value.
- **For users with an email address in Entra ID**, to allow falling back to email address and updating the user's identity,
configure the following:

10
doc/administration/backup_restore/backup_large_reference_architectures.md
View File

@ -133,11 +133,11 @@ Set up cronjobs to perform Gitaly server-side backups:
1. Configure Gitaly server-side backup destination on all Gitaly nodes by following [Configure server-side backups](../gitaly/configure_gitaly.md#configure-server-side-backups).
This bucket is used exclusively by Gitaly to store repository data.
1. While Gitaly backs up all Git repository data in its designated object storage bucket configured above,
1. While Gitaly backs up all Git repository data in its designated object storage bucket configured previously,
the backup utility tool (`gitlab-backup`) uploads additional backup data to a separate bucket. This data includes a `tar` file containing essential metadata for restores.
Ensure this backup data is properly uploaded to remote (cloud) storage by following
[Upload backups to a remote (cloud) storage](backup_gitlab.md#upload-backups-to-a-remote-cloud-storage) to set up the upload bucket.
1. (Optional) To solidify the durability of this backup data, back up both buckets configured above with their respective object store provider by adding them to
1. (Optional) To solidify the durability of this backup data, back up both buckets configured previously with their respective object store provider by adding them to
[backups of object storage data](#configure-backup-of-object-storage-data).
1. SSH into a GitLab Rails node, which is a node that runs Puma or Sidekiq.
1. Take a full backup of your Git data. Use the `REPOSITORIES_SERVER_SIDE` variable, and skip PostgreSQL data:
@ -180,13 +180,13 @@ Set up cronjobs to perform Gitaly server-side backups:
1. Configure Gitaly server-side backup destination on all Gitaly nodes by following
[Configure server-side backups](../gitaly/configure_gitaly.md#configure-server-side-backups). This bucket is used exclusively by Gitaly to store repository data.
1. While Gitaly backs up all Git repository data in its designated object storage bucket configured above,
1. While Gitaly backs up all Git repository data in its designated object storage bucket configured previously,
the backup utility tool (`gitlab-backup`) uploads additional backup data to a separate bucket. This data includes a `tar` file containing essential metadata for restores.
Ensure this backup data is properly uploaded to remote (cloud) storage by following
[Upload backups to a remote (cloud) storage](backup_gitlab.md#upload-backups-to-a-remote-cloud-storage) to set up the upload bucket.
1. (Optional) To solidify the durability of this backup data, both buckets configured above can be backed up by their respective object store provider by adding them
1. (Optional) To solidify the durability of this backup data, both buckets configured previously can be backed up by their respective object store provider by adding them
to [backups of object storage data](#configure-backup-of-object-storage-data).
1. Ensure backup of both buckets by following [Configure backup of object storage data](#configure-backup-of-object-storage-data). Both storage buckets configured above
1. Ensure backup of both buckets by following [Configure backup of object storage data](#configure-backup-of-object-storage-data). Both storage buckets configured previously
should also be backed up by their respective object storage provider.
1. SSH into a GitLab Rails node, which is a node that runs Puma or Sidekiq.
1. Take a full backup of your Git data. Use the `REPOSITORIES_SERVER_SIDE` variable and skip all other data:

2
doc/administration/backup_restore/troubleshooting_backup_gitlab.md
View File

@ -39,7 +39,7 @@ and the jobs begin running again.
{{< alert type="warning" >}}
The steps in this section can potentially lead to data loss on the above listed items.
The steps in this section can potentially lead to data loss on the previously listed items.
Consider opening a [Support Request](https://support.gitlab.com/hc/en-us/requests/new) if you're a Premium or Ultimate customer.
{{< /alert >}}

2
doc/administration/integration/kroki.md
View File

@ -118,7 +118,7 @@ your AsciiDoc or Markdown documentation using delimited blocks:
Alice -> Bob : hi
```
The above blocks are converted to an HTML image tag with source pointing to the
The delimited blocks are converted to an HTML image tag with source pointing to the
Kroki instance. If the Kroki server is correctly configured, this should
render a nice diagram instead of the block:

2
doc/administration/integration/plantuml.md
View File

@ -166,7 +166,7 @@ Prerequisites:
#### Installation
PlantUML recommends to install Tomcat 10.1 or above. The scope of this page only
PlantUML recommends to install Tomcat 10.1 or later. The scope of this page only
includes setting up a basic Tomcat server. For more production-ready configurations,
see the [Tomcat Documentation](https://tomcat.apache.org/tomcat-10.1-doc/index.html).

2
doc/administration/integration/terminal.md
View File

@ -122,7 +122,7 @@ Linux package installations. In this case, you need to:
`Connection` and `Upgrade` lines.
For your own load balancer, just reverse the configuration changes recommended
by the above guides.
by the previously listed guides.
When these headers are not passed through, Workhorse returns a
`400 Bad Request` response to users attempting to use a web terminal. In turn,

14
doc/administration/reference_architectures/10k_users.md
View File

@ -58,7 +58,7 @@ specifically the [Before you start](_index.md#before-you-start) and [Deciding wh
The sizing depends on selected Load Balancer and additional factors such as Network Bandwidth. Refer to [Load Balancers](_index.md#load-balancers) for more information.
5. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information.
6. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management.
Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/_index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`.
Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/_index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed in the previous table for `Gitaly`.
7. Gitaly specifications are based on high percentiles of both usage patterns and repository sizes in good health.
However, if you have [large monorepos](_index.md#large-monorepos) (larger than several gigabytes) or [additional workloads](_index.md#additional-workloads) these can significantly impact Git and Gitaly performance and further adjustments will likely be required.
8. Can be placed in Auto Scaling Groups (ASGs) as the component doesn't store any [stateful data](_index.md#autoscaling-of-stateful-nodes).
@ -319,7 +319,7 @@ GitLab Pages requires a separate virtual IP address. Configure DNS to point the
Some organizations have policies against opening SSH port 22. In this case,
it may be helpful to configure an alternate SSH hostname that allows users
to use SSH on port 443. An alternate SSH hostname will require a new virtual IP address
compared to the other GitLab HTTP configuration above.
compared to the other GitLab HTTP configuration documented previously.
Configure DNS for an alternate SSH hostname such as `altssh.gitlab.example.com`.
@ -1342,8 +1342,6 @@ and [Amazon RDS](https://aws.amazon.com/rds/) are known to work. However, Amazon
See [Recommended cloud providers and services](_index.md#recommended-cloud-providers-and-services) for more information.
Examples of the above could include [Google's Cloud SQL](https://cloud.google.com/sql/docs/postgres/high-availability#normal) or [Amazon RDS](https://aws.amazon.com/rds/).
Once the database is set up, follow the [post configuration](#praefect-postgresql-post-configuration).
#### Praefect PostgreSQL post-configuration
@ -2329,7 +2327,7 @@ Refer to [epic 6127](https://gitlab.com/groups/gitlab-org/-/epics/6127) for more
### Cluster topology
The following tables and diagram detail the hybrid environment using the same formats
as the typical environment above.
as the typical environment documented previously.
First are the components that run in Kubernetes. These run across several node groups, although you can change
the overall makeup as desired as long as the minimum CPU and Memory requirements are observed.
@ -2375,7 +2373,7 @@ services where applicable):
Also, the sizing depends on selected Load Balancer and additional factors such as Network Bandwidth. Refer to [Load Balancers](_index.md#load-balancers) for more information.
5. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information.
6. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management.
Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/_index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`.
Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/_index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed in the previous table for `Gitaly`.
7. Gitaly specifications are based on high percentiles of both usage patterns and repository sizes in good health.
However, if you have [large monorepos](_index.md#large-monorepos) (larger than several gigabytes) or [additional workloads](_index.md#additional-workloads) these can significantly impact Git and Gitaly performance and further adjustments will likely be required.
<!-- markdownlint-enable MD029 -->
@ -2489,7 +2487,7 @@ Each Sidekiq pod is recommended to be run with the following configuration:
- 2 GB memory (request)
- 4 GB memory (limit)
Similar to the standard deployment above, an initial target of 14 Sidekiq workers has been used here.
Similar to the standard deployment documented previously, an initial target of 14 Sidekiq workers has been used here.
Additional workers may be required depending on your specific workflow.
For further information on Sidekiq resource usage, see the Charts documentation on [Sidekiq resources](https://docs.gitlab.com/charts/charts/gitlab/sidekiq/#resources).
@ -2507,7 +2505,7 @@ pool as given, you can increase the node pool accordingly. Conversely, if the po
### Example config file
An example for the GitLab Helm Charts targeting the above 200 RPS or 10,000 reference architecture configuration [can be found in the Charts project](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/examples/ref/10k.yaml).
An example for the GitLab Helm Charts targeting the 200 RPS or 10,000 users reference architecture configuration [can be found in the Charts project](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/examples/ref/10k.yaml).
<div align="right">
<a type="button" class="btn btn-default" href="#set-up-components">

8
doc/administration/reference_architectures/2k_users.md
View File

@ -217,7 +217,7 @@ GitLab Pages requires a separate virtual IP address. Configure DNS to point the
Some organizations have policies against opening SSH port 22. In this case,
it may be helpful to configure an alternate SSH hostname that allows users
to use SSH on port 443. An alternate SSH hostname will require a new virtual IP address
compared to the other GitLab HTTP configuration above.
compared to the other GitLab HTTP configuration documented previously.
Configure DNS for an alternate SSH hostname such as `altssh.gitlab.example.com`.
@ -1169,7 +1169,7 @@ Refer to [epic 6127](https://gitlab.com/groups/gitlab-org/-/epics/6127) for more
### Cluster topology
The following tables and diagram detail the hybrid environment using the same formats
as the typical environment above.
as the typical environment documented previously.
First are the components that run in Kubernetes. These run across several node groups, although you can change
the overall makeup as desired as long as the minimum CPU and Memory requirements are observed.
@ -1284,7 +1284,7 @@ Each Sidekiq pod is recommended to be run with the following configuration:
- 2 GB memory (request)
- 4 GB memory (limit)
Similar to the standard deployment above, an initial target of 4 Sidekiq workers has been used here.
Similar to the standard deployment documented previously, an initial target of 4 Sidekiq workers has been used here.
Additional workers may be required depending on your specific workflow.
For further information on Sidekiq resource usage, see the Charts documentation on [Sidekiq resources](https://docs.gitlab.com/charts/charts/gitlab/sidekiq/#resources).
@ -1302,7 +1302,7 @@ pool as given, you can increase the node pool accordingly. Conversely, if the po
### Example config file
An example for the GitLab Helm Charts for the above 40 RPS or 2,000 reference architecture configuration [can be found in the Charts project](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/examples/ref/2k.yaml).
An example for the GitLab Helm Charts for the 40 RPS or 2,000 users reference architecture configuration [can be found in the Charts project](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/examples/ref/2k.yaml).
<div align="right">
<a type="button" class="btn btn-default" href="#set-up-components">

4
doc/administration/reference_architectures/_index.md
View File

@ -375,8 +375,8 @@ If this applies to you, we strongly recommend you follow the linked documentatio
Large monorepos come with notable cost. If you have such a repository,
follow these guidance to ensure good performance and to keep costs in check:
- [Optimize the large monorepo](../../user/project/repository/monorepos/_index.md#optimize-gitlab-settings). Using features such as
[LFS](../../user/project/repository/monorepos/_index.md#use-lfs-for-large-blobs) to not store binaries, and other approaches for reducing repository size, can
- [Optimize the large monorepo](../../user/project/repository/monorepos/_index.md). Using features such as
[LFS](../../user/project/repository/monorepos/_index.md#use-git-lfs-for-large-binary-files) to not store binaries, and other approaches for reducing repository size, can
dramatically improve performance and reduce costs.
- Depending on the monorepo, increased environment specifications may be required to compensate. Gitaly might require additional resources along with Praefect, GitLab Rails, and Load Balancers. This depends on the monorepo itself and its usage.
- When the monorepo is significantly large (20 gigabytes or more), further additional strategies may be required such as even further increased specifications or in some cases, a separate Gitaly backend for the monorepo alone.

4
doc/ci/pipelines/settings.md
View File

@ -208,7 +208,7 @@ You can choose how your repository is fetched from GitLab when a job runs.
for every job. However, the local working copy is always pristine.
- `git fetch` is faster because it re-uses the local working copy (and falls
back to clone if it doesn't exist). This is recommended, especially for
[large repositories](../../user/project/repository/monorepos/_index.md#git-strategy).
[large repositories](../../user/project/repository/monorepos/_index.md#use-git-fetch-in-cicd-operations).
The configured Git strategy can be overridden by the [`GIT_STRATEGY` variable](../runners/configure_runners.md#git-strategy)
in the `.gitlab-ci.yml` file.
@ -227,7 +227,7 @@ a repository.
Newly created projects have a default `git depth` value of `20`.
This value can be overridden by the [`GIT_DEPTH` variable](../../user/project/repository/monorepos/_index.md#shallow-cloning)
This value can be overridden by the [`GIT_DEPTH` variable](../../user/project/repository/monorepos/_index.md#use-shallow-clones-in-cicd-processes)
in the `.gitlab-ci.yml` file.
## Set a limit for how long jobs can run

230
doc/development/database/group_hierarchy_optimization.md Normal file
View File

@ -0,0 +1,230 @@
---
stage: Data Access
group: Database Frameworks
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/development/development_processes/#development-guidelines-review.
title: Group hierarchy query optimization
---
This document describes the hierarchy cache optimization strategy that helps with loading all descendants (subgroups or projects) from large group hierarchies with minimal overhead. The optimization was implemented within this GitLab [epic](https://gitlab.com/groups/gitlab-org/-/epics/11469).
The optimization is enabled automatically via the [`Namespaces::EnableDescendantsCacheCronWorker`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/workers/namespaces/enable_descendants_cache_cron_worker.rb?ref_type=heads) worker for group hierarchies with descendant counts above 700 (projects and groups). Enabling the optimization manually for smaller groups will likely not have noticeable effects.
## Performance comparison
Loading all group IDs for the `gitlab-org` group, including itself and its descendants.
{{< tabs >}}
{{< tab title="Optimized cached query" >}}
**42 buffers** (~336.00 KiB) from the buffer pool
```sql
SELECT "namespaces"."id" FROM UNNEST(
COALESCE(
(
SELECT ids FROM (
SELECT "namespace_descendants"."self_and_descendant_group_ids" AS ids
FROM "namespace_descendants"
WHERE "namespace_descendants"."outdated_at" IS NULL AND
"namespace_descendants"."namespace_id" = 22
) cached_query
),
(
SELECT ids
FROM (
SELECT ARRAY_AGG("namespaces"."id") AS ids
FROM (
SELECT namespaces.traversal_ids[array_length(namespaces.traversal_ids, 1)] AS id
FROM "namespaces"
WHERE "namespaces"."type" = 'Group' AND
(traversal_ids @> ('{22}'))
) namespaces
) consistent_query
)
)
) AS namespaces(id)
```
```plaintext
Function Scan on unnest namespaces (cost=1296.82..1296.92 rows=10 width=8) (actual time=0.193..0.236 rows=GROUP_COUNT loops=1)
Buffers: shared hit=42
I/O Timings: read=0.000 write=0.000
InitPlan 1 (returns $0)
-> Index Scan using namespace_descendants_12_pkey on gitlab_partitions_static.namespace_descendants_12 namespace_descendants (cost=0.14..3.16 rows=1 width=769) (actual time=0.022..0.023 rows=1 loops=1)
Index Cond: (namespace_descendants.namespace_id = 9970)
Filter: (namespace_descendants.outdated_at IS NULL)
Rows Removed by Filter: 0
Buffers: shared hit=5
I/O Timings: read=0.000 write=0.000
InitPlan 2 (returns $1)
-> Aggregate (cost=1293.62..1293.63 rows=1 width=32) (actual time=0.000..0.000 rows=0 loops=0)
I/O Timings: read=0.000 write=0.000
-> Bitmap Heap Scan on public.namespaces namespaces_1 (cost=62.00..1289.72 rows=781 width=28) (actual time=0.000..0.000 rows=0 loops=0)
I/O Timings: read=0.000 write=0.000
-> Bitmap Index Scan using index_namespaces_on_traversal_ids_for_groups (cost=0.00..61.81 rows=781 width=0) (actual time=0.000..0.000 rows=0 loops=0)
Index Cond: (namespaces_1.traversal_ids @> '{9970}'::integer[])
I/O Timings: read=0.000 write=0.000
Settings: seq_page_cost = '4', effective_cache_size = '472585MB', jit = 'off', work_mem = '100MB', random_page_cost = '1.5'
```
{{< /tab >}}
{{< tab title="Traversal ids based lookup query" >}}
**1037 buffers** (~8.10 MiB) from the buffer pool
```sql
SELECT namespaces.traversal_ids[array_length(namespaces.traversal_ids, 1)] AS id
FROM "namespaces"
WHERE "namespaces"."type" = 'Group' AND
(traversal_ids @> ('{22}'))
```
```plaintext
Bitmap Heap Scan on public.namespaces (cost=62.00..1291.67 rows=781 width=4) (actual time=0.670..2.273 rows=GROUP_COUNT loops=1)
Buffers: shared hit=1037
I/O Timings: read=0.000 write=0.000
-> Bitmap Index Scan using index_namespaces_on_traversal_ids_for_groups (cost=0.00..61.81 rows=781 width=0) (actual time=0.561..0.561 rows=1154 loops=1)
Index Cond: (namespaces.traversal_ids @> '{9970}'::integer[])
Buffers: shared hit=34
I/O Timings: read=0.000 write=0.000
Settings: work_mem = '100MB', random_page_cost = '1.5', seq_page_cost = '4', effective_cache_size = '472585MB', jit = 'off'
```
{{< /tab >}}
{{< /tabs >}}
## How to use the optimization
The optimization will be automatically used if you use one of these ActiveRecord scopes:
```ruby
# Loading all groups:
group.self_and_descendants
# Using the IDs in subqueries:
group.self_and_descendant_ids
NamespaceSetting.where(namespace_id: group.self_and_descendant_ids)
# Loading all projects:
group.all_projects
# Using the IDs in subqueries
MergeRequest.where(target_project_id: group.all_project_ids)
```
## Cache invalidation
When the group hierarchy changes, for example when a new project or subgroup is added, the cache is invalidated within the same transaction. A periodic worker called [`Namespaces::ProcessOutdatedNamespaceDescendantsCronWorker`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/workers/namespaces/process_outdated_namespace_descendants_cron_worker.rb?ref_type=heads) will update the cache with a slight delay. The invalidation is implemented using ActiveRecord callbacks.
While the cache is invalidated, the hierarchical database queries will continue returning consistent values using the uncached (unoptimized) `traversal_ids` based query query.
## Consistent queries
The lookup queries implement an `||` (or) functionality in SQL which allows us to check for the cached values first. If those are not present, we fall back to a full lookup of all groups or projects in the hierarchy.
For simplification, this is how we would implement the lookup in Ruby:
```ruby
if cached? && cache_up_to_date?
return cached_project_ids
else
return Project.where(...).pluck(:id)
end
```
In `SQL`, we leverage the `COALESCE` function, which returns the first non-NULL expression from a list of expressions. If the first expression is not NULL, the subsequent expressions are not evaluated.
```sql
SELECT COALESCE(
(SELECT 1), -- cached query
(SELECT 2 FROM pg_sleep(5)) -- non-cached query
)
```
The query above returns immediately however, if the first subquery returns null, the DB will execute the second query:
```sql
SELECT COALESCE(
(SELECT NULL), -- cached query
(SELECT 2 FROM pg_sleep(5)) -- non-cached query
)
```
## The `namespace_descendants` database table
The cached subgroup and project ids are stored in the `namespace_descendants` database table as arrays, the most important columns:
- `namespace_id`: primary key, this can be a top-level group ID or a subgroup ID.
- `self_and_descendant_group_ids`: all group IDs as an array
- `all_project_ids`: all project IDs as an array
- `outdated_at`: signals that the cache is outdated
## Cached database query
The query consists of three parts:
- cached query
- fallback, non-cached query
- outer query where additional filtering and data loading (`JOIN`) can be done
Cached query:
```sql
SELECT ids -- One row, array of ids
FROM (
SELECT "namespace_descendants"."self_and_descendant_group_ids" AS ids
FROM "namespace_descendants"
WHERE "namespace_descendants"."outdated_at" IS NULL AND
"namespace_descendants"."namespace_id" = 22
) cached_query
```
The query returns `NULL` when the cache is outdated or the cache record does not exist.
Fallback query, based on the `traversal_ids` lookup:
```sql
SELECT ids -- One row, array of ids
FROM (
SELECT ARRAY_AGG("namespaces"."id") AS ids
FROM (
SELECT namespaces.traversal_ids[array_length(namespaces.traversal_ids, 1)] AS id
FROM "namespaces"
WHERE "namespaces"."type" = 'Group' AND
(traversal_ids @> ('{22}'))
) namespaces
)
```
Final query, combining the queries into one:
```sql
SELECT "namespaces"."id" FROM UNNEST(
COALESCE(
(
SELECT ids FROM (
SELECT "namespace_descendants"."self_and_descendant_group_ids" AS ids
FROM "namespace_descendants"
WHERE "namespace_descendants"."outdated_at" IS NULL AND
"namespace_descendants"."namespace_id" = 22
) cached_query
),
(
SELECT ids
FROM (
SELECT ARRAY_AGG("namespaces"."id") AS ids
FROM (
SELECT namespaces.traversal_ids[array_length(namespaces.traversal_ids, 1)] AS id
FROM "namespaces"
WHERE "namespaces"."type" = 'Group' AND
(traversal_ids @> ('{22}'))
) namespaces
) consistent_query
)
)
) AS namespaces(id)
```

2
doc/development/documentation/site_architecture/automation.md
View File

@ -51,7 +51,7 @@ that are coded across multiple repositories.
| [Available custom role permissions](../../../user/custom_roles/abilities.md) | [Generated by Rake task](https://gitlab.com/gitlab-org/gitlab/-/blob/master/tooling/custom_roles/docs/templates/custom_abilities.md.erb) | [Authorization](https://handbook.gitlab.com/handbook/product/categories/#authorization-group)|
| [CI/CD Job token fine-grained permissions](../../../ci/jobs/fine_grained_permissions.md) | [Generated by Rake task](https://gitlab.com/gitlab-org/gitlab/-/blob/master/tooling/ci/job_tokens/docs/templates/fine_grained_permissions.md.erb) | [Authorization](https://handbook.gitlab.com/handbook/product/categories/#authorization-group)|
| [Application settings analysis](../../cells/application_settings_analysis.md) | [Generated by Ruby script](https://gitlab.com/gitlab-org/gitlab/-/blob/2bb2910c84fad965bde473aa2881d88358b6e96e/scripts/cells/application-settings-analysis.rb#L353) | |
| DAST vulnerability check documentation ([Example](../../../user/application_security/dast/browser/checks/798.19.md)) | [How to generate the Markdown](https://gitlab.com/gitlab-org/security-products/dast-cwe-checks/-/blob/main/doc/how-to-generate-the-markdown-documentation.md) | [Dynamic Analysis](https://handbook.gitlab.com/handbook/product/categories/#dynamic-analysis-group) |
| DAST vulnerability check documentation ([Example](../../../user/application_security/dast/browser/checks/798.140.md)) | [How to generate the Markdown](https://gitlab.com/gitlab-org/security-products/dast-cwe-checks/-/blob/main/doc/how-to-generate-the-markdown-documentation.md) | [Dynamic Analysis](https://handbook.gitlab.com/handbook/product/categories/#dynamic-analysis-group) |
| [The docs homepage](../../../_index.md) | | [Technical Writing](https://handbook.gitlab.com/handbook/product/ux/technical-writing/) |
## Make an automation request

2
doc/topics/git/troubleshooting_git.md
View File

@ -300,7 +300,7 @@ This problem is common in Git itself, due to its inability to handle large files
- The existence of large files in the repository.
If this error occurs when cloning a large repository, you can
[decrease the cloning depth](../../user/project/repository/monorepos/_index.md#shallow-cloning) to a value of `1`. For example:
[decrease the cloning depth](../../user/project/repository/monorepos/_index.md#use-shallow-clones-in-cicd-processes) to a value of `1`. For example:
This approach doesn't resolve the underlying cause, but you can successfully clone the repository.
To decrease the cloning depth to `1`, run:

6
doc/user/application_security/dast/browser/checks/798.10.md
View File

@ -2,17 +2,17 @@
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token Asana Client Secret
title: 'Exposure of confidential secret or token Asana client secret'
---
## Description
The response body contains content that matches the pattern of a Asana Client Secret.
The response body contains content that matches the pattern of an Asana Client Secret was detected. Client Secrets are used for authentication and authorization using OAuth. A malicious actor who got access to this secret could gain access to user accounts and execute functionality on their behalf.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
Review the response body content and remove any exposed values.
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet). To revoke the detected client secret: - Sign in to your developer account and access <https://app.asana.com/0/my-apps> - Under the "My apps" page find the application that uses the secret - Select your app in the developer console - Go to the "OAuth" tab in the sidebar - Select "Reset" next to your client secret For more information please [see their documentation on configuring OAuth](https://developers.asana.com/docs/oauth)
## Details

4
doc/user/application_security/dast/browser/checks/798.101.md
View File

@ -2,7 +2,7 @@
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token SendGrid API token
title: 'Exposure of confidential secret or token SendGrid API token'
---
## Description
@ -12,7 +12,7 @@ Exposing this value could allow attackers to gain access to all resources grante
## Remediation
Review the response body content and remove any exposed values.
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
## Details

6
doc/user/application_security/dast/browser/checks/798.102.md
View File

@ -2,17 +2,17 @@
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token Sendinblue API token
title: 'Exposure of confidential secret or token Brevo API token'
---
## Description
The response body contains content that matches the pattern of a Sendinblue API token.
The response body contains content that matches the pattern of a Brevo API token.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
Review the response body content and remove any exposed values.
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
## Details

17
doc/user/application_security/dast/browser/checks/798.104.md
View File

@ -2,17 +2,28 @@
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token Shippo API token
title: 'Exposure of confidential secret or token Shippo API token'
---
## Description
The response body contains content that matches the pattern of a Shippo API token.
The response body contains content that matches the pattern of a live Shippo API token was identified. API tokens can be used to access the Shippo API which is used for shipping services. A malicious actor with access to this token can access billing and order information and modify shipping data.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
Review the response body content and remove any exposed values.
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
To revoke an API token:
- Sign in to your Shippo account and access <https://apps.goshippo.com/>
- In the top right-hand side, select the "gear" icon to go to the "Settings" page
- Scroll down in the left hand menu to "Advanced" and select "API"
- Under the "Token" section, select "Manage your token"
- Find the identified token and select the trash icon
- When prompted, select "Yes, remove token" in the "Manage Your Tokens" dialog
For more information, please see [Shippo's documentation on API keys](https://portal.goshippo.com/api-config/api).
## Details

6
doc/user/application_security/dast/browser/checks/798.105.md
View File

@ -2,17 +2,17 @@
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token Shopify access token
title: 'Exposure of confidential secret or token Shopify personal access token'
---
## Description
The response body contains content that matches the pattern of a Shopify access token.
The response body contains content that matches the pattern of a Shopify personal access token was identified. Access tokens can be given restricted scopes or be given full access to all store data. A malicious actor who gained access to this token could be able to read or modify store data.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
Review the response body content and remove any exposed values.
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet). Access tokens cannot be revoked, you must uninstall and reinstall the application. Please see [Shopify's documentation for more details](https://shopify.dev/docs/apps/build/authentication-authorization/access-tokens/generate-app-access-tokens-admin#rotating-api-credentials-for-admin-created-apps).
## Details

6
doc/user/application_security/dast/browser/checks/798.106.md
View File

@ -2,17 +2,17 @@
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token Shopify custom access token
title: 'Exposure of confidential secret or token Shopify custom app access token'
---
## Description
The response body contains content that matches the pattern of a Shopify custom access token.
The response body contains content that matches the pattern of a Shopify custom app access token.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
Review the response body content and remove any exposed values.
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
## Details

4
doc/user/application_security/dast/browser/checks/798.107.md
View File

@ -2,7 +2,7 @@
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token Shopify private app access token
title: 'Exposure of confidential secret or token Shopify private app access token'
---
## Description
@ -12,7 +12,7 @@ Exposing this value could allow attackers to gain access to all resources grante
## Remediation
Review the response body content and remove any exposed values.
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
## Details

4
doc/user/application_security/dast/browser/checks/798.108.md
View File

@ -2,7 +2,7 @@
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token Shopify shared secret
title: 'Exposure of confidential secret or token Shopify shared secret'
---
## Description
@ -12,7 +12,7 @@ Exposing this value could allow attackers to gain access to all resources grante
## Remediation
Review the response body content and remove any exposed values.
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
## Details

17
doc/user/application_security/dast/browser/checks/798.109.md
View File

@ -2,17 +2,28 @@
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token Slack token
title: 'Exposure of confidential secret or token Slack bot user OAuth token'
---
## Description
The response body contains content that matches the pattern of a Slack token.
The response body contains content that matches the pattern of a Slack bot user OAuth token was identified. A Slack app's capabilities and permissions are governed by the scopes it requests. A full list of permissions can be found [in Slack's scopes documentation](https://api.slack.com/scopes). A malicious actor with access to this token can execute functionality that was assigned to it.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
Review the response body content and remove any exposed values.
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
To revoke a Slack bot user OAuth token (Note: This requires all users to re-authorize your application):
- Sign in to Slack and access <https://api.slack.com/apps>
- Find the application with the identified token and select the name
- In the left-hand menu, select "OAuth & Permissions"
- Scroll down to "Revoke All OAuth Tokens" and select "Revoke tokens"
- When prompted, select "Yes, I'm sure" in the "Are you sure?" dialog
- After some time, scroll back up to the "OAuth Tokens" section and select "Reinstall to XXX", where XXX is your workspace name
For more information, please see [Slack's documentation on OAuth](https://api.slack.com/authentication/oauth-v2)
## Details

4
doc/user/application_security/dast/browser/checks/798.11.md
View File

@ -2,7 +2,7 @@
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token Atlassian API token
title: 'Exposure of confidential secret or token Atlassian API token'
---
## Description
@ -12,7 +12,7 @@ Exposing this value could allow attackers to gain access to all resources grante
## Remediation
Review the response body content and remove any exposed values.
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
## Details

20
doc/user/application_security/dast/browser/checks/798.110.md
View File

@ -2,22 +2,32 @@
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token Slack Webhook
title: 'Exposure of confidential secret or token Slack webhook'
---
## Description
The response body contains content that matches the pattern of a Slack Webhook.
The response body contains content that matches the pattern of a Slack webhook URL was detected. Slack webhook URLs are used to post messages from external sources into Slack. They make use of HTTP requests with a JSON payload, which includes the message and a few other optional details. You can include message attachments to display richly-formatted messages. A malicious actor with access to this URL can post messages to the Slack channel it is bound to.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
Review the response body content and remove any exposed values.
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
To rotate the Slack webhook URL:
- Sign in to Slack and access <https://api.slack.com/apps>
- Find the application with the identified webhook URL and select the name
- In the left-hand menu, select "Incoming Webhooks"
- In the "Webhook URL" table, select the trash icon next to the webhook URL that was identified.
- When prompted, select "Remove" in the confirmation dialog
For more information, please see [Slack's documentation on webhooks](https://api.slack.com/messaging/webhooks).
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| ID | Aggregated | CWE | Type | Risk |
|:--------|:-----------|:----|:-----|:-----|
| 798.110 | false | 798 | Passive | High |
## Links

16
doc/user/application_security/dast/browser/checks/798.111.md
View File

@ -2,17 +2,27 @@
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token Stripe
title: 'Exposure of confidential secret or token Stripe live secret key'
---
## Description
The response body contains content that matches the pattern of a Stripe.
The response body contains content that matches the pattern of a Stripe live secret key was identified. Live secret keys authenticate requests on your server when in live mode. By default, you can use this key to perform any API request without restriction. A malicious actor who gained access to this key could gain read/write access to all data in Stripe for this account.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
Review the response body content and remove any exposed values.
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
To rotate your Stripe live secret key:
- Sign in to your Stripe account and access <https://dashboard.stripe.com/apikeys>
- Ensure "Test mode" is disabled
- In the "Standard keys" section, find the key that was identified and select the ellipsis in the right-hand side
- Select "Roll key..." - In the "Roll API key" dialog, select an expiration date, for example "now"
- Select "Roll API Key"
For more information, please see [Stripe's documentation on rotating API keys](https://docs.stripe.com/keys#rolling-keys).
## Details

25
doc/user/application_security/dast/browser/checks/798.113.md
View File

@ -1,25 +0,0 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token Squarespace Access Token
---
## Description
The response body contains content that matches the pattern of a Squarespace Access Token.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
Review the response body content and remove any exposed values.
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.113 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

25
doc/user/application_security/dast/browser/checks/798.114.md
View File

@ -1,25 +0,0 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token SumoLogic Access ID
---
## Description
The response body contains content that matches the pattern of a SumoLogic Access ID.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
Review the response body content and remove any exposed values.
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.114 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

25
doc/user/application_security/dast/browser/checks/798.115.md
View File

@ -1,25 +0,0 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token SumoLogic Access Token
---
## Description
The response body contains content that matches the pattern of a SumoLogic Access Token.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
Review the response body content and remove any exposed values.
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.115 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

25
doc/user/application_security/dast/browser/checks/798.116.md
View File

@ -1,25 +0,0 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token Travis CI Access Token
---
## Description
The response body contains content that matches the pattern of a Travis CI Access Token.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
Review the response body content and remove any exposed values.
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.116 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

4
doc/user/application_security/dast/browser/checks/798.117.md
View File

@ -2,7 +2,7 @@
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token Twilio API Key
title: 'Exposure of confidential secret or token Twilio API key'
---
## Description
@ -12,7 +12,7 @@ Exposing this value could allow attackers to gain access to all resources grante
## Remediation
Review the response body content and remove any exposed values.
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
## Details

17
doc/user/application_security/dast/browser/checks/798.118.md
View File

@ -2,17 +2,28 @@
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token Twitch API token
title: 'Exposure of confidential secret or token Twitch OAuth client secret'
---
## Description
The response body contains content that matches the pattern of a Twitch API token.
The response body contains content that matches the pattern of a Twitch OAuth client secret was identified. OAuth client secrets are used to allow the service to execute functionality on behalf of Twitch users. A malicious actor with access to this client secret can impersonate the service and execute functionality on behalf its users.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
Review the response body content and remove any exposed values.
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
To rotate the OAuth client secret:
- Sign in to your Twitch account and access <https://dev.twitch.tv/console>
- Find the extension that uses the identified key
- Select "Manage" next to extension name in the "Extensions" section
- In the top right corner, select "Extension Settings"
- In the "Twitch API Client Configuration" section, select "Generate Secret" under "Twitch API Client Secret"
- When prompted, select "OK" from the dialog
For more information, please see [Twitch's developer documentation on OAuth](https://dev.twitch.tv/docs/authentication/getting-tokens-oauth/#authorization-code-grant-flow).
## Details

25
doc/user/application_security/dast/browser/checks/798.119.md
View File

@ -1,25 +0,0 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token Twitter API Key
---
## Description
The response body contains content that matches the pattern of a Twitter API Key.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
Review the response body content and remove any exposed values.
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.119 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

6
doc/user/application_security/dast/browser/checks/798.12.md
View File

@ -2,17 +2,17 @@
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token AWS
title: 'Exposure of confidential secret or token AWS access token'
---
## Description
The response body contains content that matches the pattern of a AWS.
The response body contains content that matches the pattern of an AWS Access Token was detected. AWS Access Tokens are usually paired along with their secret key values. A malicious actor with access to this token can access AWS services with the same permissions as the user which generated the key, provided they have access to both values.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
Review the response body content and remove any exposed values.
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet). To delete an access key: - In the "Access keys" section, find the key that was identified - Select "Actions" - Select "Delete" - Follow the instructions in the dialog to first deactivate and then confirm the deletion For information on how to manage and revoke access keys for AWS please see their [documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey).
## Details

25
doc/user/application_security/dast/browser/checks/798.120.md
View File

@ -1,25 +0,0 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token Twitter API Secret
---
## Description
The response body contains content that matches the pattern of a Twitter API Secret.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
Review the response body content and remove any exposed values.
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.120 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

6
doc/user/application_security/dast/browser/checks/798.121.md
View File

@ -2,17 +2,17 @@
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token Twitter Access Token
title: 'Exposure of confidential secret or token X token'
---
## Description
The response body contains content that matches the pattern of a Twitter Access Token.
The response body contains content that matches the pattern of an X secret access token was identified. An access secret are user-specific credentials used to authenticate OAuth 1.0a API requests. They specify the X account the request is made on behalf of. A malicious actor with access to this token can impersonate requests on behalf of a user.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
Review the response body content and remove any exposed values.
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
## Details

25
doc/user/application_security/dast/browser/checks/798.122.md
View File

@ -1,25 +0,0 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token Twitter Access Secret
---
## Description
The response body contains content that matches the pattern of a Twitter Access Secret.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
Review the response body content and remove any exposed values.
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.122 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

25
doc/user/application_security/dast/browser/checks/798.123.md
View File

@ -1,25 +0,0 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token Twitter Bearer Token
---
## Description
The response body contains content that matches the pattern of a Twitter Bearer Token.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
Review the response body content and remove any exposed values.
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.123 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

6
doc/user/application_security/dast/browser/checks/798.124.md
View File

@ -2,17 +2,17 @@
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token Typeform API token
title: 'Exposure of confidential secret or token Typeform personal access token'
---
## Description
The response body contains content that matches the pattern of a Typeform API token.
The response body contains content that matches the pattern of a Typeform personal access token was identified. Personal access tokens are for accessing the Typeform API. depending on the assigned scope and permissions, a malicious actor with access to this token can read, update, or delete form data.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
Review the response body content and remove any exposed values.
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet). To regenerate the Typeform API token: - Sign in to your Typeform account and go to <https://admin.typeform.com/> - In the top right corner, select your profile picture and select "Your settings" under "Account" - In the left-hand menu, select "Personal tokens" - In the "token name" table, find the identified token, select the ellipsis, and select "Regenerate token" For more information, please see [Typeform's documentation on personal access tokens](https://www.typeform.com/developers/get-started/personal-access-token/).
## Details

25
doc/user/application_security/dast/browser/checks/798.125.md
View File

@ -1,25 +0,0 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token Yandex API Key
---
## Description
The response body contains content that matches the pattern of a Yandex API Key.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
Review the response body content and remove any exposed values.
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.125 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

25
doc/user/application_security/dast/browser/checks/798.126.md
View File

@ -1,25 +0,0 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token Yandex AWS Access Token
---
## Description
The response body contains content that matches the pattern of a Yandex AWS Access Token.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
Review the response body content and remove any exposed values.
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.126 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

25
doc/user/application_security/dast/browser/checks/798.127.md
View File

@ -1,25 +0,0 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token Yandex Access Token
---
## Description
The response body contains content that matches the pattern of a Yandex Access Token.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
Review the response body content and remove any exposed values.
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.127 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

25
doc/user/application_security/dast/browser/checks/798.128.md
View File

@ -1,25 +0,0 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token Zendesk Secret Key
---
## Description
The response body contains content that matches the pattern of a Zendesk Secret Key.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
Review the response body content and remove any exposed values.
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.128 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

6
doc/user/application_security/dast/browser/checks/798.13.md
View File

@ -2,17 +2,17 @@
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token Bitbucket Client ID
title: 'Exposure of confidential secret or token Bitbucket client ID'
---
## Description
The response body contains content that matches the pattern of a Bitbucket Client ID.
The response body contains content that matches the pattern of a Bitbucket client ID.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
Review the response body content and remove any exposed values.
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
## Details

36
doc/user/application_security/dast/browser/checks/798.130.md Normal file
View File

@ -0,0 +1,36 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: 'Exposure of confidential secret or token Anthropic API key'
---
## Description
The response body contains content that matches the pattern of an Anthropic API key was detected. Anthropic keys are used to access generative AI services. Malicious actors could use these keys to build up excessive charges to your account.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
To remediate a leaked Anthropic key, you should delete it from the list of API keys for your organization.
- Sign in to your [Anthropic account](https://console.anthropic.com/)
- Go to "API settings" by selecting your profile icon and then selecting "API Keys" or through the Settings tab
- Identify the leaked API key and select the meatball menu (three horizontal dots) next to the key you want to delete
- Select "Delete API Key"
- Note: Deleting an API key is a permanent action and cannot be undone
- Generate a new key by selecting "Create Key" and give it a descriptive name
For more information, please see Anthropic's website: <https://support.anthropic.com/en/articles/8384961-what-should-i-do-if-i-suspect-my-api-key-has-been-compromised>.
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.130 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

38
doc/user/application_security/dast/browser/checks/798.131.md Normal file
View File

@ -0,0 +1,38 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: 'Exposure of confidential secret or token CircleCI access token'
---
## Description
The response body contains content that matches the pattern of a CircleCI project token was identified. CircleCI project tokens can be given one of three scopes: - Status - Read Only - Admin Depending on the access level of this detected token, a malicious actor with access to this token may be able to gain full access to the project and CI/CD pipelines.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
To rotate a project token:
- In the CircleCI application select Projects in the sidebar, then the ellipsis (...) next to your project, and select "Project Settings".
- Select API Permissions.
- Select the "X" in the Remove column for the token you wish to replace. When the confirmation window appears, enter the text DELETE in the form and then select "Delete API Token".
- Select "Create API Token".
- Choose the same scope used for the old token from the dropdown list.
- In the Label field, type a label for the token.
It can be the same name given to the old token.
- Select "Add API Token".
For more information please see their [documentation on rotating project tokens](https://circleci.com/docs/managing-api-tokens/#rotating-a-project-api-token).
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.131 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

36
doc/user/application_security/dast/browser/checks/798.132.md Normal file
View File

@ -0,0 +1,36 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: 'Exposure of confidential secret or token CircleCI Personal Access Token'
---
## Description
The response body contains content that matches the pattern of a CircleCI personal access token was identified. Personal access tokens grant the same level of permissions as the user that created the token. A malicious actor with access to this token can impersonate the user and gain access to all features and services in CircleCI.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
For rotating a Personal Access token:
- In the CircleCI application, go to your User settings.
- Select "Personal API Tokens".
- Select "X" in the Remove column for the token you wish to replace and confirm your deletion. - Select "Create New Token".
- In the Token name field, type a new name for the old token you are rotating. It can be the same name given to the old token.
- Select "Add API Token".
- After the token appears, copy and paste it to another location. It is not possible to view the token again.
For more information please see their [documentation on rotating personal access tokens](https://circleci.com/docs/managing-api-tokens/#rotating-a-personal-api-token).
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.132 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

37
doc/user/application_security/dast/browser/checks/798.133.md Normal file
View File

@ -0,0 +1,37 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: 'Exposure of confidential secret or token Contentful preview API token'
---
## Description
The response body contains content that matches the pattern of a Contentful preview API token was identified. A preview API token maintains the same behavior and parameters as the Content Delivery API (CDA), but delivers the latest drafts for entries and assets. The Content Preview API is used to display the latest version of an entry. A malicious actor with access to this token can view published and unpublished entries. For more information, please see [the Preview API documentation](https://www.contentful.com/developers/docs/references/content-preview-api/).
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
To revoke the preview API token:
- Sign in and visit <https://app.contentful.com/>
- Select the gear icon in the top right corner, and then select "API Keys"
- Find the API key that was detected, and select the name in the table of API keys
- Select "Delete" in the top right corner
- When prompted, select "Delete" Note this also deletes the delivery API token.
Generating a new set of API keys is required.
For more information, please see the developer [documentation on authentication](https://www.contentful.com/developers/docs/references/authentication/#the-content-delivery-and-preview-api).
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.133 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

35
doc/user/application_security/dast/browser/checks/798.134.md Normal file
View File

@ -0,0 +1,35 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: 'Exposure of confidential secret or token Contentful personal access token'
---
## Description
The response body contains content that matches the pattern of a Contentful personal access token was identified. Personal access tokens are tied to the user who requests them and carry the same permissions, including access to organizations, spaces, and content.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
To revoke a personal access token:
- Sign in and visit your account profile: <https://app.contentful.com/account/profile/user>
- Select the "CMA tokens" tab in the top menu
- Identify the token that was detected
- Select "Revoke" in the right hand column
- Select "Revoke" when prompted
For more information, please see the developer [documentation on personal access tokens](https://www.contentful.com/help/token-management/personal-access-tokens).
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.134 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

8
doc/user/application_security/dast/browser/checks/798.112.md → doc/user/application_security/dast/browser/checks/798.135.md
View File

@ -2,23 +2,23 @@
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token Square Access Token
title: 'Exposure of confidential secret or token DigitalOcean OAuth access token'
---
## Description
The response body contains content that matches the pattern of a Square Access Token.
The response body contains content that matches the pattern of a DigitalOcean OAuth Access Token.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
Review the response body content and remove any exposed values.
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.112 | false | 798 | Passive | High |
| 798.135 | false | 798 | Passive | High |
## Links

25
doc/user/application_security/dast/browser/checks/798.136.md Normal file
View File

@ -0,0 +1,25 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: 'Exposure of confidential secret or token DigitalOcean personal access token'
---
## Description
The response body contains content that matches the pattern of a DigitalOcean Personal Access Token.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.136 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

8
doc/user/application_security/dast/browser/checks/798.103.md → doc/user/application_security/dast/browser/checks/798.137.md
View File

@ -2,23 +2,23 @@
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token Sentry Access Token
title: 'Exposure of confidential secret or token DigitalOcean refresh token'
---
## Description
The response body contains content that matches the pattern of a Sentry Access Token.
The response body contains content that matches the pattern of a DigitalOcean OAuth Refresh Token.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
Review the response body content and remove any exposed values.
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.103 | false | 798 | Passive | High |
| 798.137 | false | 798 | Passive | High |
## Links

36
doc/user/application_security/dast/browser/checks/798.138.md Normal file
View File

@ -0,0 +1,36 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: 'Exposure of confidential secret or token GCP OAuth client secret'
---
## Description
The response body contains content that matches the pattern of a GCP OAuth client secret was identified. Client secret are used when allowing users to Sign in to your application. Depending on the scopes requested, a malicious actor with access to the secret can impersonate the service to access users information.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
To revoke the OAuth client secret:
- Sign in to your GCP account and go to <https://console.cloud.google.com/apis/credentials>
- Under the "Name" column of "OAuth 2.0 Client IDs" table, select the name of the client of the identified key
- Under the "Client secrets" section, you must first add a new secret, select "Add Secret"
- For the identified key, select "Disable"
- When prompted, select "Disable" in the "Disable this secret?" dialog
- You may now select the trash icon to delete the disabled key
For more information, please see [Googles authentication documentation on setting up OAuth 2.0](https://support.google.com/cloud/answer/6158849?hl=en)
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.138 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

35
doc/user/application_security/dast/browser/checks/798.139.md Normal file
View File

@ -0,0 +1,35 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: 'Exposure of confidential secret or token Google (GCP) service account'
---
## Description
The response body contains content that matches the pattern of a GCP service account was identified. Service accounts can be assigned a wide range of permissions or access. A malicious actor with access to the service account can potentially compromise the entire GCP account or have limited access to resources, depending on the access granted.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
To revoke the GCP Service account:
- Sign in to your GCP account and go to <https://console.cloud.google.com/iam-admin/serviceaccounts>
- Select the correct project from the list (if given a choice)
- Find the key ID and the associated service account in the "Service accounts" table
- Select the kebab menu (vertical ellipsis) for the identified key and select "Manage keys"
- Select the trash icon next to the identified key
For more information, please see [Googles documentation on creating service account keys](https://cloud.google.com/iam/docs/keys-create-delete).
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.139 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

6
doc/user/application_security/dast/browser/checks/798.14.md
View File

@ -2,17 +2,17 @@
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token Bitbucket Client Secret
title: 'Exposure of confidential secret or token Bitbucket client secret'
---
## Description
The response body contains content that matches the pattern of a Bitbucket Client Secret.
The response body contains content that matches the pattern of a Bitbucket client secret.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
Review the response body content and remove any exposed values.
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
## Details

25
doc/user/application_security/dast/browser/checks/798.140.md Normal file
View File

@ -0,0 +1,25 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: 'Exposure of confidential secret or token GitLab Personal Access Token (routable)'
---
## Description
The response body contains content that matches the pattern of a GitLab Personal Access Token (routable).
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.140 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

25
doc/user/application_security/dast/browser/checks/798.141.md Normal file
View File

@ -0,0 +1,25 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: 'Exposure of confidential secret or token GitLab Personal Access Token (routable)'
---
## Description
The response body contains content that matches the pattern of a GitLab Personal Access Token (routable).
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.141 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

36
doc/user/application_security/dast/browser/checks/798.142.md Normal file
View File

@ -0,0 +1,36 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: 'Exposure of confidential secret or token GitLab pipeline trigger token'
---
## Description
The response body contains content that matches the pattern of a GitLab pipeline trigger token was identified. Pipeline trigger tokens can be used to execute pipelines for a branch or tag of a project. The token impersonates a user's project access and permissions. A malicious actor with access to this token can execute pipelines with custom variables, potentially being able to compromise the repository.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
To revoke a pipeline trigger token:
- Sign in to your GitLab account and visit the project that created the pipeline trigger token
- In the left-hand menu, select "Settings"
- Under the "Settings" options, select "CI/CD"
- Under the "Pipeline trigger tokens" section find the identified token
- Select the trash icon in the "Actions" column of the "Active pipeline trigger tokens" table
- When prompted, select "Revoke trigger"
For more information, please see [GitLabs documentation on pipeline trigger tokens](../../../../../ci/triggers/_index.md#create-a-pipeline-trigger-token).
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.142 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

36
doc/user/application_security/dast/browser/checks/798.143.md Normal file
View File

@ -0,0 +1,36 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: 'Exposure of confidential secret or token GitLab runner registration token'
---
## Description
The response body contains content that matches the pattern of a deprecated GitLab Runner registration token was identified. These tokens allow users to register a runner with the selected project. A malicious actor with access to this token can add a custom runner to the pipeline and possibly compromise the repository if the runner was used.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
To rotate a runner registration token:
- Sign in to your GitLab account and visit the project that created the runner registration token
- In the left-hand menu, select "Settings"
- Under the "Settings" options, select "CI/CD"
- Under the "Runners" section, select the kebab menu (vertical ellipsis) next to the "New project runner"
- Select "Reset registration token" from the dropdown list
- When prompted select "Reset token" in the "Reset registration token" dialog
For more information, please see [GitLabs documentation on using runner authentication tokens instead](https://docs.gitlab.com/runner/register/#register-with-a-runner-authentication-token).
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.143 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

36
doc/user/application_security/dast/browser/checks/798.144.md Normal file
View File

@ -0,0 +1,36 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: 'Exposure of confidential secret or token GitLab runner authentication token'
---
## Description
The response body contains content that matches the pattern of a GitLab Runner authentication token was identified. These tokens allow users to register or authenticate as a runner with the selected project. A malicious actor with access to this token can add a custom runner to the pipeline and possibly compromise the repository if the runner was used.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
To revoke a runner authentication token, the runner needs to be removed and re-created:
- Sign in to your GitLab account and visit the project that created the runner registration token
- In the left-hand menu, select "Settings"
- Under the "Settings" options, select "CI/CD"
- Under the "Runners" section, find the runner with the identified token, (you can check the runner `config.toml` if you are unsure)
- Select "Remove runner"
- When prompted, select "Remove"
For more information, please see [GitLabs documentation on registering runners](https://docs.gitlab.com/runner/register/).
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.144 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

31
doc/user/application_security/dast/browser/checks/798.145.md Normal file
View File

@ -0,0 +1,31 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: 'Exposure of confidential secret or token GitLab feed token'
---
## Description
The response body contains content that matches the pattern of a GitLab Feed Token.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
To regenerate a feed token:
- Sign in to your GitLab account and access the [User settings](../../../../../user/profile/_index.md#access-your-user-settings) left-hand side menu, select "Access tokens"
- Under the "Feed token" section, select the "reset this token" link
- When prompted select "OK" For more information, please see [GitLabs documentation on feed tokens](../../../../../security/tokens/_index.md#feed-token).
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.145 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

33
doc/user/application_security/dast/browser/checks/798.146.md Normal file
View File

@ -0,0 +1,33 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: 'Exposure of confidential secret or token GitLab OAuth application secret'
---
## Description
The response body contains content that matches the pattern of a GitLab OAuth application secret was identified. OAuth secrets are used when allowing users to sign in to your application. Depending on the scopes assigned, a malicious actor could impersonate the service to access their repositories or data.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
To regenerate an OAuth secret:
- Sign in to your GitLab account and access the [User settings](../../../../../user/profile/_index.md#access-your-user-settings) left-hand side menu, select "Applications"
- Find the application that uses the identified token and select the name link in the "Name" column - Select "Renew secret" in the application details page
- When prompted, select "Renew secret"
For more information, please see [GitLabs documentation on configuring an OAuth 2.0 provider](../../../../../integration/oauth_provider.md)
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.146 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

33
doc/user/application_security/dast/browser/checks/798.147.md Normal file
View File

@ -0,0 +1,33 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: 'Exposure of confidential secret or token GitLab feed token v2'
---
## Description
The response body contains content that matches the pattern of a GitLab feed token was identified. Your feed token authenticates you when your RSS reader loads a personalized RSS feed or when your calendar application loads a personalized calendar. It is visible in those feed URLs. It cannot be used to access any other data. A malicious actor with access to this token can read your personalized RSS feed and issue RSS feeds to your calendar feed as if they were you.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
To regenerate a feed token:
- Sign in to your GitLab account and access the [User settings](../../../../../user/profile/_index.md#access-your-user-settings) left-hand side menu, select "Access tokens"
- Under the "Feed token" section, select the "reset this token" link
- When prompted select "OK"
For more information, please see [GitLabs documentation on feed tokens](../../../../../security/tokens/_index.md#feed-token).
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.147 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

25
doc/user/application_security/dast/browser/checks/798.148.md Normal file
View File

@ -0,0 +1,25 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: 'Exposure of confidential secret or token GitLab Kubernetes agent token'
---
## Description
The response body contains content that matches the pattern of a GitLab Agent for Kubernetes token was identified. The Kubernetes access token is used to authenticate the GitLab agent with a Kubernetes cluster. A malicious actor with access to this token can access source code in the agent's configuration project, access source code in any public project on the GitLab instance, or even, under very specific conditions, obtain a Kubernetes manifest.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet). For more information please see [GitLabs documentation on rotating the Kubernetes agent token](../../../../../user/clusters/agent/work_with_agent.md#reset-the-agent-token).
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.148 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

33
doc/user/application_security/dast/browser/checks/798.149.md Normal file
View File

@ -0,0 +1,33 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: 'Exposure of confidential secret or token GitLab incoming email token'
---
## Description
The response body contains content that matches the pattern of a GitLab incoming email token was identified. Your incoming email token authenticates you when you create a new issue by email, and is included in your personal project-specific email addresses. It cannot be used to access any other data. A malicious actor with access to this token can create issues as if they were you.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
To regenerate a feed token:
- Sign in to your GitLab account and access the [User settings](../../../../../user/profile/_index.md#access-your-user-settings) left-hand side menu, select "Access tokens"
- Under the "Incoming email token" section, select the "reset this token" link
- When prompted select "OK"
For more information, please see [GitLabs documentation on feed tokens](../../../../../security/tokens/_index.md#feed-token).
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.149 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

25
doc/user/application_security/dast/browser/checks/798.15.md
View File

@ -1,25 +0,0 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Exposure of confidential secret or token Bittrex Access Key
---
## Description
The response body contains content that matches the pattern of a Bittrex Access Key.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
Review the response body content and remove any exposed values.
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.15 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

27
doc/user/application_security/dast/browser/checks/798.150.md Normal file
View File

@ -0,0 +1,27 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: 'Exposure of confidential secret or token GitLab deploy token'
---
## Description
The response body contains content that matches the pattern of a GitLab deploy token was identified. A deploy token enables authentication of deployment tasks, independent of a user account. With a deploy token, automated tasks can: - Clone Git repositories - Pull from and push to a GitLab container registry - Pull from and push to a GitLab package registry A malicious actor with access to this token can access Git repositories or compromise released packages or containers.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
For more information, please see [GitLabs documentation on revoking deploy tokens](../../../../../user/project/deploy_tokens/_index.md).
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.150 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

35
doc/user/application_security/dast/browser/checks/798.151.md Normal file
View File

@ -0,0 +1,35 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: 'Exposure of confidential secret or token GitLab SCIM OAuth token'
---
## Description
The response body contains content that matches the pattern of a GitLab SCIM token was identified. The SCIM token is used to configure third party Identity providers (IdP). A malicious actor with access to this token can configure an IdP and add users to gain access to the GitLab system..
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
To rotate the SCIM token:
- Sign in to your GitLab account as an administrator
- On the left sidebar, at the bottom, select Admin
- Select "Settings" and then "General"
- Expand the SCIM Token section and select "Generate a SCIM token"
- Under "Your SCIM token" select "reset it" to generate a new token
For more information, please see [GitLabs documentation on SCIM configuration](../../../../../administration/settings/scim_setup.md#configure-gitlab).
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.151 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

26
doc/user/application_security/dast/browser/checks/798.152.md Normal file
View File

@ -0,0 +1,26 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: 'Exposure of confidential secret or token GitLab CI build token'
---
## Description
The response body contains content that matches the pattern of a GitLab CI build (job) token was identified. Job tokens are used to execute functionality in the context of a pipeline job. In most cases job tokens have limited privileges and can only be used to read from the repository where the pipeline executes from. External projects can grant access to job tokens from other projects. A malicious actor has a limited time frame to use this token to attempt to access the repository.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet). Because job tokens are short lived, there is no revocation process, it is no longer available after the job that created it completes.
For more details on exactly what a job token is allowed to access, please see [GitLabs documentation on job tokens](../../../../../ci/jobs/ci_job_token.md).
## Details
| ID | Aggregated | CWE | Type | Risk |
|:---|:-----------|:----|:-----|:-----|
| 798.152 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

25
doc/user/application_security/dast/browser/checks/798.153.md Normal file
View File

@ -0,0 +1,25 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: 'Exposure of confidential secret or token Grafana API token'
---
## Description
The response body contains content that matches the pattern of a Grafana API token.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
## Details
| ID | Aggregated | CWE | Type | Risk |
|:--------|:-----------|:----|:-----|:-----|
| 798.153 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

25
doc/user/application_security/dast/browser/checks/798.154.md Normal file
View File

@ -0,0 +1,25 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: 'Exposure of confidential secret or token HashiCorp Vault batch token'
---
## Description
The response body contains content that matches the pattern of a HashiCorp Vault batch token was identified. Batch tokens are used when hundreds to thousands of systems need to access Vault but generating unique tokens would not scale. These tokens are usually short lived and bound to a specific vault policy. A malicious actor with access to this token can impersonate a service and would have the same permission levels as the policy that the batch token is created for.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet). Batch tokens cannot be revoked so you should use very short "time to live" values when creating batch tokens. For more information, please see [Vault's documentation on batch tokens](https://developer.hashicorp.com/vault/tutorials/tokens/batch-tokens).
## Details
| ID | Aggregated | CWE | Type | Risk |
|:--------|:-----------|:----|:-----|:-----|
| 798.154 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

25
doc/user/application_security/dast/browser/checks/798.155.md Normal file
View File

@ -0,0 +1,25 @@
---
stage: Application Security Testing
group: Dynamic Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: 'Exposure of confidential secret or token Instagram access token'
---
## Description
The response body contains content that matches the pattern of an Instagram access token.
Exposing this value could allow attackers to gain access to all resources granted by this token.
## Remediation
For general guidance on handling security incidents with regards to leaked keys, please see the GitLab documentation on [Credential exposure to the internet](../../../../../security/responding_to_security_incidents.md#credential-exposure-to-public-internet).
## Details
| ID | Aggregated | CWE | Type | Risk |
|:--------|:-----------|:----|:-----|:-----|
| 798.155 | false | 798 | Passive | High |
## Links
- [CWE](https://cwe.mitre.org/data/definitions/798.html)

Some files were not shown because too many files have changed in this diff Show More