# Использование секретов в GitHub Actions
Узнайте, как создавать секреты на уровне репозитория, среды и организации для GitHub Actions рабочих процессов.
## Создание секретов для репозитория
Чтобы создать секреты или переменные на GitHub для репозитория организации, необходимо иметь `write` доступ. Для репозитория личной учетной записи вы должны быть соавтором репозитория.
1. На GitHubперейдите на главную страницу репозитория.
2. Под именем репозитория щелкните ** Settings**. Если вкладка "Параметры" не отображается, выберите **раскрывающееся меню ** и нажмите кнопку **"Параметры**".
3. В разделе "Безопасность" боковой панели выберите ** Секреты и переменные**, а затем нажмите кнопку **"Действия**".
4. Перейдите на вкладку **"Секреты** ".
```
```
5. Выберите **Новый секрет репозитория**.
6. ```
**В поле "Имя"** введите имя секрета.
```
7. ```
**В поле "Секрет"** введите значение секрета.
```
8. Щелкните **Добавить секрет**.
Если в репозитории есть секреты среды или доступ к секретам из родительской организации, эти секреты также отображаются на этой странице.
Чтобы добавить секрет репозитория, используйте подкоманду `gh secret set`. Замените `secret-name` именем своего секрета.
```shell
gh secret set SECRET_NAME
```
CLI предложит ввести значение секрета. Кроме того, можно считать значение секрета из файла.
```shell
gh secret set SECRET_NAME < secret.txt
```
Чтобы получить список всех секретов для репозитория, используйте подкоманду `gh secret list`.
## Создание секретов для среды
Чтобы создать секреты или переменные для среды в репозитории личная учетная запись, необходимо быть владельцем репозитория. Чтобы создать секреты или переменные для среды в репозитории организации, необходимо иметь `admin` доступ. Дополнительные сведения о средах см. в разделе [Управление средами для развертывания](/ru/actions/deployment/targeting-different-environments/managing-environments-for-deployment).
1. На GitHubперейдите на главную страницу репозитория.
2. Под именем репозитория щелкните ** Settings**. Если вкладка "Параметры" не отображается, выберите **раскрывающееся меню ** и нажмите кнопку **"Параметры**".
3. На левой боковой панели щелкните **Среды**.
4. Щелкните среду, в которую нужно добавить секрет.
5. В разделе **Секреты среды** нажмите кнопку **Добавить секрет**.
6. Введите имя для секрета в поле ввода **Имя**.
7. Введите значение для секрета.
8. Щелкните **Добавить секрет**.
Чтобы добавить секрет для среды, используйте `gh secret set` подкоманду с флагом `--env` или `-e`, за которым следует имя среды.
```shell
gh secret set --env ENV_NAME SECRET_NAME
```
Чтобы создать список всех секретов для среды, используйте `gh secret list` подкоманду с флагом `--env` или `-e`, за которым следует имя среды.
```shell
gh secret list --env ENV_NAME
```
## Создание секретов для организации
> \[!NOTE]
> Секреты и переменные уровня организации недоступны частными репозиториями для GitHub Free. Дополнительные сведения об обновлении подписки GitHub см. в разделе [Обновление плана учетной записи](/ru/billing/managing-billing-for-your-github-account/upgrading-your-github-subscription).
При создании секрета или переменной в организации можно использовать политику для ограничения доступа к репозиторию. Например, можно предоставить доступ ко всем репозиториям либо ограничить доступ только частными репозиториями или указанным списком репозиториев.
Владельцы организации могут создавать секреты или переменные на уровне организации.
1. На GitHubперейдите на главную страницу организации.
2. Под именем организации щелкните ** Settings**. Если вкладка "Параметры" не отображается, выберите **раскрывающееся меню ** и нажмите кнопку **"Параметры**".
3. В разделе "Безопасность" боковой панели выберите ** Секреты и переменные**, а затем нажмите кнопку **"Действия**".
4. Перейдите на вкладку **"Секреты** ".
5. Щелкните **Создать секрет организации**.
6. Введите имя для секрета в поле ввода **Имя**.
7. Введите **значение** для секрета.
8. В раскрывающемся списке **Доступ к репозиторию** выберите политику доступа.
9. Щелкните **Добавить секрет**.
> \[!NOTE]
> По умолчанию GitHub CLI аутентифицируется с `repo` помощью и `read:org` scope. Для управления секретами организации необходимо дополнительно авторизовать область `admin:org`.
>
> ```shell
> gh auth login --scopes "admin:org"
> ```
Чтобы добавить секрет для организации, используйте подкоманду `gh secret set` с флагом `--org` или `-o`, за которым следует имя организации.
```shell
gh secret set --org ORG_NAME SECRET_NAME
```
По умолчанию секрет доступен только частным репозиториям. Чтобы указать, что секрет должен быть доступен для всех репозиториев в организации, используйте флаг `--visibility` или `-v`.
```shell
gh secret set --org ORG_NAME SECRET_NAME --visibility all
```
Чтобы указать, что секрет должен быть доступен для выбранных репозиториев в организации, используйте флаг `--repos` или `-r`.
```shell
gh secret set --org ORG_NAME SECRET_NAME --repos REPO-NAME-1, REPO-NAME-2
```
Чтобы создать список всех секретов для организации, используйте подкоманду `gh secret list` с флагом `--org` или `-o`, за которым следует имя организации.
```shell
gh secret list --org ORG_NAME
```
## Проверка доступа к секретам на уровне организации
Вы можете проверить, какие политики доступа применяются к секрету в вашей организации.
1. На GitHubперейдите на главную страницу организации.
2. Под именем организации щелкните ** Settings**. Если вкладка "Параметры" не отображается, выберите **раскрывающееся меню ** и нажмите кнопку **"Параметры**".
3. В разделе "Безопасность" боковой панели выберите ** Секреты и переменные**, а затем нажмите кнопку **"Действия**".
4. Список секретов включает все настроенные разрешения и политики. Дополнительные сведения о настроенных разрешениях для каждого секрета нажмите кнопку **"Обновить**".
## Использование секретов в рабочем процессе
> \[!NOTE]
>
> * За исключением `GITHUB_TOKEN`, секреты не передаются в средство выполнения при активации рабочего процесса из вилки репозитория.
> * Секреты не передаются в повторно используемые рабочие процессы. Дополнительные сведения см. в разделе [Повторное использование рабочих процессов](/ru/actions/using-workflows/reusing-workflows#passing-inputs-and-secrets-to-a-reusable-workflow).
> * Секреты недоступны для рабочих процессов, запускаемых Dependabot событиями. Дополнительные сведения см. в разделе [Устранение неполадок зависимостей от действий GitHub](/ru/code-security/dependabot/troubleshooting-dependabot/troubleshooting-dependabot-on-github-actions#accessing-secrets).
> * Если рабочим процессам GitHub Actions требуется доступ к ресурсам от поставщика облачных служб, поддерживающего OpenID Connect (OIDC), можно настроить рабочие процессы для проверки подлинности непосредственно в поставщике облачных служб. Это позволит прекратить хранение таких учетных данных в виде долгоживущих секретов и обеспечить другие преимущества безопасности. Дополнительные сведения см. в разделе [OpenID Connect](/ru/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect).
> \[!WARNING] Маскируйте всю конфиденциальную информацию, которая не GitHub является секретом, используя `::add-mask::VALUE`. Это приводит к тому, что значение будет рассматриваться как секрет и отредактировано из журналов.
Чтобы указать действие с секретом в качестве входных данных или переменной среды, можно использовать контекст `secrets` для доступа к секретам, созданным в репозитории. Дополнительные сведения см. в разделе \[AUTOTITLE и [Справочник по контекстам](/ru/actions/learn-github-actions/contexts)]\(/actions/using-workflows/workflow-syntax-for-github-actions).
```yaml
steps:
- name: Hello world action
with: # Set the secret as an input
super_secret: ${{ secrets.SuperSecret }}
env: # Or as an environment variable
super_secret: ${{ secrets.SuperSecret }}
```
На секреты нельзя напрямую ссылаться в условных выражениях `if:`. Вместо этого рекомендуется задать секреты в качестве переменных среды на уровне задания, а затем создать ссылки на переменные среды для условного выполнения шагов в задании. Дополнительные сведения см. в разделе [Справочник по контекстам](/ru/actions/learn-github-actions/contexts#context-availability) и`jobs..steps[*].if`[](/ru/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsif) .
Если секрет не установлен, возвращаемое значение выражения, ссылающегося на секрет (например `${{ secrets.SuperSecret }}` , в примере), будет пустой строкой.
По возможности избегайте передачи секретов между процессами из командной строки. Процессы командной строки могут быть видимы для других пользователей (с помощью команды `ps`) или сканируются [событиями аудита безопасности](https://docs.microsoft.com/windows-server/identity/ad-ds/manage/component-updates/command-line-process-auditing). Чтобы обеспечить защиту секретов, рассмотрите возможность использования переменных среды, `STDIN`или других механизмов, поддерживаемых целевым процессом.
Если необходимо передать секреты в командной строке, добавьте их в соответствующие правила . Секреты зачастую содержат специальные символы, которые могут непреднамеренно повлиять на оболочку. Чтобы экранировать эти специальные символы, заключайте переменные среды в кавычки. Например:
### Пример с использованием Bash
```yaml
steps:
- shell: bash
env:
SUPER_SECRET: ${{ secrets.SuperSecret }}
run: |
example-command "$SUPER_SECRET"
```
### Пример с использованием PowerShell
```yaml
steps:
- shell: pwsh
env:
SUPER_SECRET: ${{ secrets.SuperSecret }}
run: |
example-command "$env:SUPER_SECRET"
```
### Пример с использованием Cmd.exe
```yaml
steps:
- shell: cmd
env:
SUPER_SECRET: ${{ secrets.SuperSecret }}
run: |
example-command "%SUPER_SECRET%"
```
## Хранение больших секретов
Чтобы использовать секреты больше 48 КБ, можно использовать обходной путь, чтобы хранить секреты в своём репозитории и сохранять пароль для расшифровки как секрет на GitHub. Например, вы можете `gpg` использовать для локального шифрования файла, содержащего ваш секрет, прежде чем отправить зашифрованный файл в репозиторий на GitHub. Дополнительные сведения см. в [gpg manpage](https://www.gnupg.org/gph/de/manual/r1023.html).
> \[!WARNING]
> Будьте осторожны, чтобы секреты не печатались при запуске рабочего процесса. При использовании этого обходного пути GitHub не удаляется секреты, напечатанные в журналах.
1. Выполните следующую команду на терминале, чтобы зашифровать файл, содержащий секрет, с помощью `gpg` и алгоритма шифра AES256. В этом примере секрет содержит файл `my_secret.json`.
```shell
gpg --symmetric --cipher-algo AES256 my_secret.json
```
2. Вам будет предложено ввести парольную фразу. Запомните пароль, потому что вам нужно создать новый секрет GitHub , который использует пароль как значение.
3. Создайте новый секрет, который содержит парольную фразу. Например, создайте новый секрет с именем `LARGE_SECRET_PASSPHRASE` и задайте для секрета парольную фразу, использованную на предыдущем шаге.
4. Скопируйте зашифрованный файл в путь в репозитории и выполните его фиксацию. В этом примере зашифрованный файл имеет значение `my_secret.json.gpg`.
> \[!WARNING]
> Обязательно скопируйте зашифрованный `my_secret.json.gpg` файл, `.gpg` заканчивающийся расширением файла, а **не** незашифрованный `my_secret.json` файл.
```shell
git add my_secret.json.gpg
git commit -m "Add new secret JSON file"
```
5. Создайте скрипт оболочки в репозитории для расшифровки файла секрета. В этом примере секрет называется `decrypt_secret.sh`.
```shell copy
#!/bin/sh
# Decrypt the file
mkdir $HOME/secrets
# --batch to prevent interactive command
# --yes to assume "yes" for questions
gpg --quiet --batch --yes --decrypt --passphrase="$LARGE_SECRET_PASSPHRASE" \
--output $HOME/secrets/my_secret.json my_secret.json.gpg
```
6. Перед возвратом в репозиторий убедитесь, что скрипт оболочки является исполняемым.
```shell
chmod +x decrypt_secret.sh
git add decrypt_secret.sh
git commit -m "Add new decryption script"
git push
```
7. В вашем GitHub Actions рабочем процессе используйте a `step` , чтобы вызвать shell-скрипт и расшифровать секрет. Чтобы создать копию репозитория в среде, в которой выполняется рабочий процесс, необходимо использовать действие [`actions/checkout`](https://github.com/actions/checkout). Создайте ссылку на сценарий оболочки с помощью команды `run` относительно корня репозитория.
```yaml
name: Workflows with large secrets
on: push
jobs:
my-job:
name: My Job
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
- name: Decrypt large secret
run: ./decrypt_secret.sh
env:
LARGE_SECRET_PASSPHRASE: ${{ secrets.LARGE_SECRET_PASSPHRASE }}
# This command is just an example to show your secret being printed
# Ensure you remove any print statements of your secrets. GitHub does
# not hide secrets that use this workaround.
- name: Test printing your secret (Remove this step in production)
run: cat $HOME/secrets/my_secret.json
```
## Хранение двоичных BLOB-объектов Base64 в виде секретов
Кодировку Base64 можно использовать для хранения небольших BLOB-объектов в виде секретов. Затем можно создать ссылку на секрет в рабочем процессе и декодировать его для использования в средстве выполнения тестов. Ограничения размера см. в разделе [Использование секретов в GitHub Actions](/ru/actions/security-guides/using-secrets-in-github-actions#limits-for-secrets).
> \[!NOTE]
>
> * Обратите внимание, что Base64 преобразует только двоичный файл в текст и не является заменой фактического шифрования.
> * Использование другой оболочки может потребовать различных команд для декодирования секрета в файл. В запусках Windows рекомендуется [использовать оболочку](/ru/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsshell) bash с `shell: bash` помощью команд, описанных на приведенном выше шаге `run` .
1. Используйте `base64` для кодирования файла в строку Base64. Например:
В macOS можно выполнить следующее:
```shell
base64 -i cert.der -o cert.base64
```
В Linux можно выполнить следующее:
```shell
base64 -w 0 cert.der > cert.base64
```
2. Создайте секрет, который содержит строку Base64. Например:
```shell
$ gh secret set CERTIFICATE_BASE64 < cert.base64
✓ Set secret CERTIFICATE_BASE64 for octocat/octorepo
```
3. Чтобы получить доступ к строке Base64 из средства выполнения тестов, передайте секрет в `base64 --decode`. Например:
```yaml
name: Retrieve Base64 secret
on:
push:
branches: [ octo-branch ]
jobs:
decode-secret:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
- name: Retrieve the secret and decode it to a file
env:
CERTIFICATE_BASE64: ${{ secrets.CERTIFICATE_BASE64 }}
run: |
echo $CERTIFICATE_BASE64 | base64 --decode > cert.der
- name: Show certificate information
run: |
openssl x509 -in cert.der -inform DER -text -noout
```
## Следующие шаги
Справочные сведения см. в разделе [Справочник по секретам](/ru/actions/reference/secrets-reference).