20 октября 2026 г.
Вы можете создать секрет в Shared Vault Postman, привязать его к переменной окружения и использовать при запуске коллекций или в автономных API-запросах, не сохраняя значение открытым текстом в вашей коллекции или окружении. Весь этот рабочий процесс доступен из CLI Postman.
Это устраняет важный пробел в разработке API из командной строки. CLI Postman уже умел разрешать секреты Shared Vault во время выполнения, но для создания секрета и его привязки к переменной требовалась настройка в приложении Postman или прямые вызовы API. Теперь этот рабочий процесс можно завершить прямо из терминала.
Обзор рабочего процесса с секретами в CLI Postman
Рабочий процесс состоит из четырех шагов:
- Создайте секрет с помощью postman secret create.
- Привяжите полученный идентификатор секрета к переменной окружения с помощью postman environment var set.
- Ссылайтесь на переменную с помощью обычного синтаксиса Postman, например {{PAYMENT_API_TOKEN}}.
- Запустите коллекцию или автономный запрос, и CLI разрешит секрет во время выполнения.
Окружение хранит ссылку на секрет Shared Vault, а не его значение в открытом виде. Эта же ссылка работает как с облачными окружениями, идентифицируемыми по ID, так и с локальными файлами окружения, хранящимися с вашим проектом.
Краткое описание демо: в сопутствующем видео создается одноразовый секрет Shared Vault, он привязывается к облачному окружению, используется в автономном запросе postman, запускается коллекция с тем же окружением, а привязанная переменная проверяется в приложении Postman.
Что такое секрет Shared Vault в Postman
Секрет Shared Vault в Postman — это конфиденциальные данные, такие как токен API, пароль или секрет клиента, которые хранятся в защищенном хранилище (Shared Vault) рабочей области. Запросы и скрипты используют секрет с помощью защищенной переменной, а Postman подставляет значение при выполнении запроса.
Хранение значения в хранилище отделяет учетные данные от коллекций, окружений и других артефактов API. Это упрощает повторное использование учетных данных без необходимости копировать значение в открытом виде в несколько файлов или инструментов. Узнайте больше в документации по Postman Vault.
Предварительные требования для создания секрета
Перед началом убедитесь, что у вас есть:
- Версия CLI Postman 1.69.0 или выше.
- Аутентифицированный сеанс CLI Postman, созданный с помощью postman login.
- Рабочая область Postman, в которой у вас есть разрешения на создание секретов Shared Vault.
- Идентификатор облачного окружения или путь к локальному файлу окружения Postman.
Если ваш текущий каталог был инициализирован с помощью postman init, CLI может прочитать идентификатор рабочей области из .postman/resources.yaml. В противном случае передайте идентификатор рабочей области с помощью флага --workspace.
Создание секрета в Shared Vault Postman
Начните с задания имени секрету:
CLI открывает одноразовую форму в браузере, куда вы вводите учетные данные. Ее вывод содержит имена и идентификаторы, а не само значение секрета. Это также позволяет агенту кодирования инициировать рабочий процесс, пока вы сами вводите значение.
Чтобы вместо этого ввести один секрет через замаскированную подсказку в терминале, добавьте --terminal:
Сохраните полученный идентификатор секрета для следующего шага.
Создание секрета из стандартного ввода
Для контролируемого рабочего процесса подготовки или ротации учетных данных передайте значение через стандартный ввод:
Используйте printf вместо echo, когда значение не должно содержать символ перевода строки в конце. Избегайте размещения открытого значения непосредственно в команде.
Создание секретов обычно должно быть этапом подготовки или ротации, а не тем, что повторяется при каждом запуске CI. Рутинные тесты и задачи развертывания могут повторно использовать привязанную переменную окружения.
Привязка секрета к переменной окружения
Привяжите новый секрет к переменной с помощью postman environment var set:
Если параметр --vault-id опущен, CLI использует рабочую область для поиска правильного хранилища. Если проект уже привязан к рабочей области, вы также можете опустить --workspace.
Успешное выполнение команды подтверждает привязку:
Чтобы привязать секрет в локальном файле окружения, передайте его путь вместо идентификатора облачного окружения:
В обоих случаях переменная содержит идентификаторы хранилища и секрета, необходимые для их разрешения во время выполнения. Она не содержит сохраненного значения в открытом виде.
Дополнительные сведения о чтении и обновлении окружений см. в справочнике по командам окружения CLI Postman.
Использование секрета в автономном запросе Postman
Ссылайтесь на привязанную переменную с помощью обычного синтаксиса {{variableName}}. Например, используйте ее в качестве токена носителя (bearer token):
Перед отправкой запроса CLI определяет переменную, поддерживаемую хранилищем, и разрешает ее:
Это делает postman request полезным для аутентифицированной отработки, дымовых тестов и автоматизации без включения самого токена в команду.
Целевой API по-прежнему получает разрешенные учетные данные, так как ему требуется это значение для аутентификации запроса. Отдавайте предпочтение полям авторизации или заголовкам, а не параметрам запроса, поскольку URL-адреса часто сохраняются в журналах серверов, прокси-серверов, браузеров и систем наблюдаемости. Также избегайте скриптов или подробной диагностики, выводящих конфиденциальные данные запросов.
Использование того же секрета в коллекции Postman
Коллекция может ссылаться на ту же переменную в URL, заголовке, теле, поле авторизации или скрипте:
Запустите коллекцию с привязанным окружением:
CLI Postman разрешает секрет Shared Vault перед выполнением запросов. После этого коллекция может выполнять свои тесты и скрипты, не сохраняя токен в определении коллекции.
Вы можете использовать тот же подход при разработке, в конвейерах CI и других автоматизированных рабочих процессах с коллекциями. Ознакомьтесь с разделом «Работа с CLI Postman» для получения информации об установке, аутентификации, выполнении коллекций и примерах для CI.
Проверка привязки хранилища в приложении Postman
Откройте окружение в приложении Postman после привязки переменной. Защищенная переменная отображает ссылку на Shared Vault вместо значения окружения в открытом виде.
Это дает терминалу и приложению Postman единую модель:
- Shared Vault Postman владеет конфиденциальным значением.
- Окружение владеет многоразовым именем переменной и ссылкой на хранилище.
- Коллекции и запросы используют имя переменной.
- Среда выполнения Postman разрешает значение при запуске рабочего процесса.
Таким образом, привязку можно создать через CLI и проверить через приложение Postman без копирования секрета между интерфейсами.
Рекомендации по безопасности для секретов CLI Postman
Следуйте этим рекомендациям при внедрении этого рабочего процесса в разработку или CI:
- Вводите значения через замаскированную подсказку или стандартный ввод. Не передавайте секреты в открытом виде в качестве аргументов командной строки.
- Храните в коллекциях и окружениях только ссылки на секреты.
- Используйте выделенное задание подготовки или ротации для создания секретов вместо их воссоздания при каждой сборке.
- Ограничьте доступ к рабочей области и хранилищу для людей и средств автоматизации, которым это необходимо.
- Отправляйте учетные данные только на предназначенные для этого домены API и отдавайте предпочтение заголовкам или полям авторизации вместо URL-адресов.
- Проверяйте скрипты, логирование запросов, отладочный вывод и поведение целевого API на предмет мест, где разрешенное значение может быть выведено на экран.
- Относитесь к локальным файлам окружения, содержащим идентификаторы хранилищ и секретов, как к конфигурационным метаданным, даже если они не содержат значений в открытом виде.
Хранилище Vault сокращает количество мест, где учетные данные в открытом виде сохраняются постоянно. Оно не мешает авторизованному запросу, скрипту или целевому API получать или регистрировать значение после его разрешения во время выполнения.
Преимущества для команд разработки API
Рабочий процесс с командной строкой Shared Vault помогает командам:
- Предоставлять секреты без переключения из терминала в приложение Postman.
- Хранить учетные данные в открытом виде за пределами определений коллекций и окружений.
- Использовать одну связанную переменную повторно в автономных запросах и при полных запусках коллекций.
- Применять одинаковую конфигурацию секретов к локальным и облачным окружениям.
- Инициализировать окружения разработки и CI с помощью повторяемых команд.
- Проверять полученную взаимосвязь переменных в приложении Postman.
Результатом является более четкое разделение между поведением API, конфигурацией окружения и хранением учетных данных.
Часто задаваемые вопросы
Могу ли я создать секрет Postman Vault из командной строки
Да. Используйте postman secret create <key> для создания секрета в Shared Vault рабочего пространства Postman. Значение запрашивается через замаскированное интерактивное приглашение или стандартный ввод.
Хранит ли Postman CLI секрет в открытом виде в окружении
Нет. Когда вы связываете секрет Shared Vault с помощью postman environment var set --secret-id, окружение сохраняет ссылку на хранилище, содержащую идентификаторы секрета и хранилища. Среда выполнения извлекает значение при запуске запроса или коллекции.
Могу ли я использовать секрет Shared Vault с postman request
Да. Свяжите секрет с переменной окружения, сошлитесь на эту переменную в запросе с помощью синтаксиса вроде {{PAYMENT_API_TOKEN}} и передайте окружение с помощью флага --environment.
Могу ли я использовать тот же секрет при запуске коллекции
Да. Сошлитесь на связанную переменную в коллекции и запустите ее с помощью postman collection run <collection> --environment <environment>. CLI разрешает переменную, привязанную к хранилищу, перед запуском коллекции.
Работают ли переменные, связанные с хранилищем, с локальными файлами окружения
Да. Команда привязки принимает либо идентификатор облачного окружения, либо путь к локальному файлу окружения. Разрешение секретов во время выполнения работает для обоих целевых окружений, если у CLI есть необходимая аутентификация и доступ к хранилищу.
Как CI должен предоставлять новое значение секрета
Передайте значение через стандартный ввод из защищенного хранилища секретов платформы CI. Используйте это как целенаправленную операцию подготовки или ротации. Рутинные задачи CI должны использовать существующее связанное окружение вместо создания нового секрета хранилища при каждом запуске.
Может ли разрешенный секрет по-прежнему появляться в логах
Да, если запрос отправляет его в URL, скрипт выводит его на печать, подробная диагностика включает конфиденциальные поля или целевой API дублирует его. Связывание с Vault предотвращает хранение открытого текста в артефактах Postman; оно не отменяет поведение запросов, скриптов, средств ведения логов или целевых систем.
Создавайте один раз и используйте во всех рабочих процессах Postman
Секреты Postman CLI предоставляют сквозной рабочий процесс в терминале для учетных данных Shared Vault. Создайте секрет, свяжите его с переменной окружения и используйте переменную как в отдельных запросах, так и при полных запусках коллекций.
Это позволяет хранить учетные данные в Postman Shared Vault, предоставляя разработчикам и системам автоматизации привычный интерфейс {{variableName}} в Postman CLI и приложении.
Чтобы начать работу, пройдите аутентификацию с помощью postman login, выберите рабочее пространство и окружение и создайте свой первый секрет:
Ресурсы
- Документация по Postman Vault
- Справочник по командам окружения Postman CLI
- Обзор Postman CLI
- Работа с Postman CLI
- Управление переменными и их использование в Postman






