Добавить файлы credentials и config на целевую машину
Обновлено: 07.07.2024
Делегирование учетных данных удаленной системе
Делегирование учетных данных
Для доступа к любой системе требуются учетные данные. Но, подключаясь к компьютерам изнутри удаленной сессии, вы эти данные не предоставляете. Для того, чтобы подключение сработало вам нужно делегировать ваши учетные данные удаленной системе, чтобы она, в свою очередь, могла их использовать для подключения к другим компьютерам.
Для этого нужно сделать следующее.
Во-первых, вам нужно включить возможность делегирования учетных данных с вашей локальной машины. Это делается командой
Кроме того, вы можете предоставить возможность делегирования ваших учетных данных любому компьютеру в пределах домена, хотя это и не рекомендуется.
Выполнение этой команды задает следующую настройку локальной групповой политики:
Computer Configuration -> Administrative Templates -> System -> Credential Delegation -> Allow delegating fresh credentials
Однако, если вы собираетесь включать делегирование на клиенте, используя только групповую политику, не забудьте включить следующую настройку:
Computer Configuration -> Administrative Templates -> Windows Components -> Windows Remote Management (WinRM) -> WinRM Client -> Allow CredSSP authentication
Во-вторых, нам нужно, чтобы удаленный компьютер мог участовать в делегировании наших учетных данных.
Для этого на удаленном компьютере нужно выполнить следующую команду:
Если вы проводите всю конфигурацию с локального компьютера, команда может выглядеть так:
Этого же результата можно добиться используя следующую настройку групповой политики
Computer Configuration -> Administrative Templates -> Windows Components -> Windows Remote Management (WinRM) -> WinRM Service -> Allow CredSSP authentication
Посмотреть текущие настройки можно при помощи командлета
Задание учетных данных в конфигурации удаленных подключений
Другим способом является указание требуемых учетных данных в конфигурции подключения на удаленном компьютере, например в microsoft.powershell или microsoft.powershell.workflow.
Промотреть текущую настройку можно следующей командой:
Нас интересует свойство RunAsUser. Если учетные данные не заданы, его значение будет пустым.
Для того, чтобы задать требуемые учетные данные можно воспользоваться следующей командой:
Теперь, если мы снова запросим настройки конфигурации microsoft.powershell.workflow, то в поле RunAsUser будет указано имя пользователя, от имени которого будут происходить все действия при подключении к этой конфигурации.
Для того, чтобы вернуть конфигурацию к настройкам по-умолчанию, можно удалить требуемую конфигурацию командой
а затем восстановить ее в изначальном виде при помощи команды
Стоит сказать, что хотя командлет Unregister-PSSessionConfiguration может быть запущен в удаленной сессии, командлет Enable-PSRemoting должен быть выполнен локально на том компьютере, конфигурацию которого мы восстанавливаем.
Начиная с версии 5.2 в Rails перешли с секретов ( secrets.yml ) на полномочия ( credentials.yml ).
Это менеджер ключей и паролей (да и вообще любых строк), хранящий всё в зашифрованном виде. Разберём как перевести имеющиеся секреты под новые требования на примере secret_key_base .
1. Нужно создать
Можно и на локальном сервере, затем скопировать на релизный. Консольная команда, вызывающая редактирование credentials:
EDITOR=vim rails credentials:edit
Если через бандлы, то:
EDITOR=vim bundle exec rails credentials:edit
Редактор можно выбрать любой, даже с GUI. В него ввести практически то же самое, что было в secrets.yml , формат соответственно YAML.
development:
secret_key_base: 461989807a53d2de8dacd1c73585713c37fddfe.
staging:
secret_key_base: fd9065a781d4e3e96f17790c7d25ca45dcb1d8d.
production:
secret_key_base: 914edbe043002157751b338ef7d571b949654cc.
Если в secrets.yml использовался <%= ENV["SECRET_KEY_BASE"] %> , то нужно его заменить на сам ключ.
После первого сохранения будут созданы master.key (в нём хранится ключ шифрования, при повторных сохранениях будет использоваться уже он) и credentials.yml.enc (это зашифрованные credentials).
Adding config/master.key to store the encryption key: 5ca595fdd3a6a774f0ae6b52c3fa29fc
Save this in a password manager your team can access.
If you lose the key, no one, including you, can access anything encrypted with it.
create config/master.key
File encrypted and saved.
2. Нужно задействовать.
1. В config/environments, как минимум в production.rb :
config.secret_key_base = Rails.application.credentials[Rails.env.to_sym][:secret_key_base]
Также включить требование ключа:
2. В иных местах, где использовался этот ключ, заменить на такую же конструкцию:
YourApp::Application.config.db_token = Rails.application.credentials[Rails.env.to_sym][:secret_key_base]
Но в этом примере правильнее всё-таки задействовать config:
YourApp::Application.config.db_token = Rails.application.config.secret_key_base
3. Использовать на релизе.
Ключ можно хранить в двух местах: config/master.key и переменная окружения RAILS_MASTER_KEY . Отсюда вариативность использования:
3.1 RAILS_MASTER_KEY
Вариант простой, но не безопасный - любой процесс на сервере имеет к ним доступ. Также, если на одном сервере больше одного проекта, им придётся использовать одну переменную. Так что рекомендую второй способ.
3.2 master.key
На примере, когда на проекте используются репозиторий и деплои.
Файл master.key не рекомендуется хранить в открытых репозиториях. Если Ваш репозиторий закрыт от ненужных глаз, то данной частью можно пренебречь, иначе не забыть добавить его в .gitignore . Файл credentials.yml.enc зашифрован и его лучше хранить в репозитории.
Одним из вариантов использования master.key на сервере является хранение его во внешней папке с ограниченным доступом и при деплое делать ссылку на него в папке config. Допустим, есть папка shared, находящаяся вне проекта, доступная только необходимым пользователям, и на которую есть ссылка shared в папке проекта. Туда и можно скинуть данный файл.
Создание ссылки на файл на примере Capistrano. Сам таск:
Выполнение его нужно добавить после обновления кода, но перед выполнением любых подключений к БД, например миграций:
after "deploy:finalize_update", "custom:create_symlinks", "deploy:migrate"
С credentials.yml.enc всё проще - он добавится вместе с остальным кодом. После такого деплоя релизный проект сможет читать зашифрованные в файле ключи. Если что-то пошло не так, получите ошибку:
ArgumentError: Missing `secret_key_base` for 'production' environment, set this string with `rails credentials:edit`
Если это первое использование на релизе, то рельсы нужно пнуть с помощью rails credentials:edit :
EDITOR=vim rails credentials:edit
или через bundle :
EDITOR=vim bundle exec rails credentials:edit
"/tmp/47452.credentials.yml" 14L, 652C written
File encrypted and saved.
Немного о хранении других ключей
Хранить можно любые значения, например:
development:
stripe:
secret_key: sk_test_asdfgh123
token: rk_test_Hkkjbh43
production:
stripe:
secret_key: sk_live_qwerty456
token: rk_live_dsIIjhh5
Сredentials в версии Ruby on Rails 5.2.0 — новый золотой стандарт. Старые добрые, но небезопасные файлы .env уступают дорогу. В этой статье вы узнаете:
- зачем и как перейти от secrets к credentials,
- как использовать API-ключи в Ruby, YML и js.erb,
- как раз и навсегда предоставить ключ каждому из команды.
Почему стоит использовать сredentials вместо secrets?
В цикле разработки, по мере развития в проект интегрируется всё больше различных сервисов. Для каждого внешнего сервиса существует собственный API-ключ. Обычно проходит совсем немного времени до момента, когда коллеги начнут охоту за за последним API-ключом. Это очень раздражает!
Или, просто представьте, API-ключ обновляется. Каждый разработчик в команде отдельно должен обновить ключ в локальных файлах dotenv. Кажется, всё это не соответствует концепции автоматизации и идеям программирования, верно?
Забудьте об обмене API-ключами в чатах в Slack или по электронной почте. Больше не придется нарушать политику безопасности.
Credentials в Rails решают эту проблему просто и эффективно: загрузка ключей на Github.
Загрузка на Github? Да, загрузка на Github! Небольшое примечание: API-ключи полностью зашифрованы.
Большое преимущество такого подхода в том, что существует один единственный ключ, которым можно поделиться с командой. И он никогда не меняется!
Новые API-ключи, добавленные вашими коллегами как credentials, подтягиваются из Github каждый раз, когда вы вытаскиваете последнюю версию ветки main (ранее носила название «ветка master»).
Ключ можно найти в папке config/master.key.
Как это работает?
Запуск bin/rails credentials:edit в rails создает два файла, которые требуются в папке config:
- credentials.yml.enc хранит все ваши API-ключи. Если вам вдруг любопытно, расширение .enc означает шифрование.
- master.key — это ключ, который используется для расшифровки encrypted.file (1.) Убедитесь, что вы добавили master.key в файл .gitignore.yml .
Переход на credentials
Откройте файл credentials, выполнив в терминале следующее:
EDITOR='code --wait' bin/rails credentials:edit
В зависимости от используемого вами редактора, замените code (VS Code). Например:
vim or vi = Vim
atom = Atom
subl or stt = Sublime
Файл credentials автоматически открывается в редакторе и ждет, когда вы его обновите и снова закроете. Перенесите ключи ENV, которые вы используете в файле .env, в файл credentials.yml.
Замените старый файл .ENV :
Примечание: Ключ Cloudinary API разделен на несколько частей, согласно документации.
Все готово! Для вывода на экран, credentials можно запустить в терминале.
Запустите bin/rails credentials:show .
Пришло время прощаться с нашим старым другом — файлом .ENV. Удалим его.
Как использовать Credentials в различных форматах, таких как Ruby, YML и JavaScript
для Cloudinary необходим дополнительный файл config/cloudinary.yml
Как поделиться ключами с командой
Поделитесь ключом в master.key с другими разработчиками, чтобы разрешить дешифрование.
Каждый член команды создает файл master.key локально в папке config и передает его в общий ключ.
Вывод
Программирование становится всё более увлекательным занятием без суеты и необходимости искать правильные API-ключи. Благодаря credentials, мы можем обновить приложение с учетом рекомендаций по информационной безопасности. Поделитесь master key один раз и избавьтесь от утомительного копирования.
Я что-то пропустил? Я перезапустил сервер и получил ту же проблему, но в режиме разработки проблем нет.
Сохранить по умолчанию файл secrets.yml
Я столкнулся с такой же проблемой при работе над приложением Rails 5.2 в рабочей среде.
Проблема не в том, что secret_key_base не был установлен правильно, а скорее потому, что передача имени среды в качестве обычного аргумента, как показано ниже, не рекомендуется
Если вы посмотрите на свой журнал ошибок, сгенерированный близко от его вершины, вы увидите это:
ПРЕДУПРЕЖДЕНИЕ ОБ УСТРАНЕНИИ: Передача имени среды в качестве обычного аргумента устарела и будет удалена в следующей версии Rails. Пожалуйста, используйте опцию -e. (вызывается из корзины / рельсов: 9)
Чтобы запустить консоль rails в другой среде, используйте параметр -e, например так:
Примечание . Установка secret_key_base в файле secrets.yml небезопасна, так как это небезопасный способ хранения ключа, используйте зашифрованный файл credential.yml и master key для расшифровки.
Надеюсь, это поможет
Сгенерируйте ключи с помощью:
Запишите ключ. Сохранить в config/master.key .
Это решение, к которому я пришел. Мне действительно не нравится, как я был вынужден поместить это через переменную окружения. Если у кого-то есть больше информации, чтобы привлечь мое внимание к тому, как master.key и такая работа, пожалуйста, прокомментируйте.
Избегайте помещения secret_key_base под тегом среды. Поместите это выше этого.
Это не правильно:
Попробуйте это вместо этого:
Также убедитесь, что вы соблюдаете все правила отступа YAML (то есть только 2 пробела), так как это не удается сделать, поэтому моя загрузка этого файла завершается неудачно.
Так что пиши прямо
Пожалуйста, не путайте мастер-ключ с базой секретных ключей. Главный ключ используется для открытия зашифрованного файла учетных данных.
Переключение на прежнюю систему секретов не должно быть ни решением, ни принятым ответом.
Rails 5.2.0 требует дополнительного этапа для производственной среды:
Без этого Rails все еще возвращается к устаревшему механизму secret.yml (пока).
Кристофер Ригор из Engine Yard написал краткую публикацию об этом, Соответствующий кусок:
Чтение Полномочий
Если вы хотите использовать учетные данные в производственной среде, добавьте следующее в config/environments/production.rb
Хорошее чтение, чтобы также увидеть вверх и вниз по сторонам.
Примечание: как выяснил @TomDogg, Rails 5.2.1 снова кажется другим, поэтому этот ответ может относиться только к 5.2.0.
Главное меню » Операционная система Linux » 15 примеров конфигураций команд AWS для управления несколькими профилями для CLI
(1 оценок, среднее: 5,00 из 5)
Когда у вас есть AWS access_key_id и secret_access_key, вы можете либо вручную добавить их в файл учетных данных, либо использовать команду aws configure, чтобы настроить его на своем локальном компьютере.
В этом руководстве описаны все параметры, доступные в команде aws configure, а также способы управления несколькими профилями:
Когда вы выполните команду aws configure без каких-либо аргументов, вы настроите учетные данные aws в качестве своего профиля по умолчанию.
В приведенном выше:
2. Каталог
Когда вы в первый раз выполните конфигурацию aws, он создаст каталог
/.aws, если он еще не вышел из вашего домашнего каталога со следующими двумя файлами:
В приведенном выше:
Если вы хотите подключиться к другой учетной записи AWS из CLI, вы можете изменить существующие учетные данные профиля по умолчанию, снова выполнив команду «aws configure».
- Когда он запрашивает access_key_id и secret_access_key, он покажет вам последние 4 символа из существующих значений в []
- Если вы нажмете ввод без указания какого-либо нового значения, оно просто сохранит существующие значения и ничего не изменит.
Когда вы подключаетесь к нескольким учетным записям AWS, используя только профиль по умолчанию, вы должны продолжать изменять значения access_key_id и secret_access_key, что нецелесообразно.
В этом случае вы можете создать несколько профилей.
Допустим, вам нужно использовать команды CLI AWS для доступа к вашей учетной записи AWS-dev и учетной записи AWS-prod. В этом случае создайте профиль разработчика и профиль продукта, как описано ниже.
Сначала создайте профиль разработчика, как показано ниже. Используйте значения access_key_id и secret_access_key вашей учетной записи AWS-dev:
Затем создайте профиль продукта, как показано ниже. Используйте значения access_key_id и secret_access_key вашей учетной записи AWS-prod:
5. Каталог
После добавления новых дополнительных профилей (dev и prod) теперь у нас всего 3 профиля, включая профиль по умолчанию, как показано ниже в файлах конфигурации.
В приведенном выше:
6. Переключение между разными профилями AWS с помощью опции –profile
По умолчанию интерфейс командной строки AWS будет использовать учетные данные из профиля по умолчанию. Например, следующая команда выведет список всех томов EBS с использованием учетных данных профиля по умолчанию.
Если вы хотите подключиться к другой учетной записи AWS. Например, чтобы подключиться к учетной записи AWS-dev, используйте профиль dev, как показано ниже:
Следующие будут подключаться к профилю продукта:
Обратите внимание, что следующие команды точно такие же. Оба будут использовать профиль по умолчанию:
Параметр –profile можно использовать со всеми командами CLI AWS.В соответствующей заметке, чтобы запустить экземпляр EC2 из CLI, обратитесь к следующему: Как запустить экземпляр Amazon AWS EC2 с UserData из CLI.
7. Переключение между разными профилями AWS с помощью AWS_PROFILE Env Variable
Указание параметра профиля во всех ваших CLI может быть немного громоздким. Чтобы избежать этого, вы можете установить свой профиль, используя переменную среды AWS_PROFILE.
Сначала настройте AWS_PROFILE для подключения к учетной записи AWS-dev.
С этого момента все выполняемые вами команды CLI AWS будут подключаться к учетной записи AWS-dev. Вам больше не нужно указывать опцию –profile.
Следующие команды будут использовать учетные данные профиля dev (не учетные данные по умолчанию), так как мы установили AWS_PROFILE равным dev.
Если вы хотите подключиться к учетной записи AWS-prod, просто установите AWS_PROFILE на prod, как показано ниже.
После вышеизложенного следующие команды будут использовать учетные данные профиля prod для подключения к вашей учетной записи AWS-prod.
Если вы выбрали dev или prod и хотите подключиться к учетной записи AWS, которая указывает на профиль по умолчанию, у вас есть два варианта.
Вы можете установить AWS_PROFILE по умолчанию, как показано ниже.
Или вы можете просто удалить переменную среды AWS_PROFILE, которая затем автоматически начнет использовать профиль по умолчанию.
После вышеизложенного следующие команды будут использовать учетные данные профиля по умолчанию для подключения к вашей учетной записи AWS-prod.
8. Просмотр информации профиля, используя опцию списка
Опция list в команде aws configure отобразит информацию о текущем профиле, как показано ниже.
Если вы измените профиль на «prod», вы увидите, что в столбце «Value» 1-й строки будет указано «prod», как показано ниже.
Вы также можете передать имя профиля, чтобы просмотреть информацию о профиле без изменения текущего профиля, как показано ниже.
9. Изменить настройки по умолчанию и учетные данные FileName и расположение
/.aws/credentials вы также можете использовать другое местоположение и имя файла, используя следующие переменные среды:
После установки указанных выше значений все команды интерфейса командной строки AWS начнут использовать профили и соответствующие учетные данные из файлов в указанном выше местоположении:
В следующем выводе столбец «Location» последней строки (region) указывает, какой файл конфигурации он использует.
10. Просмотр значения параметра конкретного профиля с помощью опции get
Если вы хотите просто просмотреть одно значение из файла конфигурации или файла учетных данных, используйте параметр get в командах настройки aws с использованием следующего синтаксиса.
Команда get полезна, если вы что-то пишете в сценарии и хотите получить информацию о профиле внутри вашего сценария оболочки.
Следующее будет отображать только access_key_id текущего профиля.
Вы также можете использовать любой из следующих:
Вы также можете указать имя профиля, как показано ниже:
11. Установите значение параметра конкретного профиля, используя set Option
Настройка команд get и set может быть полезна, если вы пишете сценарий оболочки для управления значениями ваших файлов config/credentials.
Вы можете просто установить значение одного конкретного параметра, как показано ниже.
Вы можете установить значения любого из следующих параметров:
Вы также можете указать имя профиля, как показано ниже:
12. Добавить новую модель, используя опцию добавления модели
Вы можете добавлять модели на основе информации из файла JSON.
Например, если у вас есть версия CLI AWS, в которой нет Amazon Polly, вы можете переустановить CLI AWS, чтобы получить опрос.
Или вы можете скачать файл модели polly’s и использовать опцию add-model в aws configure, как показано ниже.
Приведенная выше команда создаст каталог
/.aws/models и создаст следующий подкаталог на основе информации из данного файла json.
Ниже приведены первые несколько строк файла json, который использовался в приведенном выше примере.
Приведенный выше файл такой же, как тот, который мы использовали во время нашей add-model.
Вы также можете указать другое имя службы, передав параметр –service-name, как показано ниже.
Выше создаст подкаталог в
/.aws/models с именем службы, которое вы указали, как показано ниже.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Читайте также: