#amazon-web-services #amazon-ec2 #ssh #terraform #user-management
Вопрос:
У меня есть стек инфраструктуры AWS, управляемый с помощью Terraform. Существует экземпляр EC2 SSH Bastion, используемый несколькими пользователями для доступа к частным эфемерным экземплярам EC2, которые используются для различных задач пакетной обработки.
Terraform предоставляет механизм для включения одного SSH-ключа в экземпляр EC2 при создании, однако я пытаюсь найти решение, предпочтительно, но не обязательно основанное на Terraform, которое позволило бы управлять несколькими пользователями для бастиона SSH.
Существует ли решение, позволяющее бастиону SSH использовать ключи SSH, связанные с пользователями IAM, таким образом, чтобы при (например) bob попытке подключиться по SSH к Бастиону Бастион мог использовать открытый ключ, связанный с bob которым должен bob принадлежать правильной группе, иметь правильное разрешение, иметь правильный тег или какую-либо другую идентифицирующую функцию?
И если приведенный выше вопрос подразумевает неправильный подход к проблеме, есть ли лучший способ рассмотреть и решить проблему?
Заранее спасибо.
Комментарии:
1. Вам нужно будет создать пользователей и добавить соответствующие ключи, чтобы
~/.ssh/authorized_keysвы могли записать это в AMI (например, с помощью упаковщика ), или вы могли бы сделать это с помощью пользовательских данных или даже с помощью поставщика терраформирования. Однако у вас нет способа запустить экземпляр и напрямую сказать, чтобы добавить пользователей и ключи для них, как это можно сделать с помощью GCP2. Я не могу вставить ключи SSH в AMI, так как пользователи будут добавлены и удалены из учетной записи AWS или им будет предоставлен и отозван доступ к этой системе. Перестраивать Бастион AMI каждый раз, когда это происходит, и перестраивать инфру для этого не имеет смысла. Должен быть какой-то разумный способ связать пользователей IAM с определенными разрешениями, чтобы разрешить доступ по SSH к Бастиону.
3. Есть, но Terraform не может управлять им за вас, потому что AWS не предоставляет его в качестве API. Ответом было бы запускать Ansible/Шеф-повара/марионетку против бастиона каждый раз, когда вы хотите изменить пользователей или ключи на коробке. Или чтобы окно автоматически выводило список пользователей и ключей и настраивало его само. Если вы поместите его в данные AMI или пользователя, то Terraform нужно будет заменять каждый раз, когда он меняется.
4. В целом, хотя вы, возможно, захотите рассмотреть альтернативный вариант, такой как подключение экземпляра EC2 или диспетчер сеансов SSM .
5. Похоже, что независимо от того, каким путем я пойду, мне придется выйти за рамки чистого решения для терраформирования. Подключение экземпляра EC2 имеет некоторые перспективы, но я подозреваю, что разумный подход заключается в том, чтобы полностью отказаться от Бастиона и позволить пользователям напрямую обращаться к своим экземплярам EC2, выполняющим пакетную обработку (к которой Бастион разрешает доступ). И это другая банка червей, в том числе из-за нехватки эластичных IP-адресов.
Ответ №1:
Если я правильно понимаю, вы задаете здесь 2 вопроса:
Q1. Есть ли способ автоматически добавлять пользователей в бастион и устанавливать их учетные данные ssh?
Да, вы можете сделать это с помощью скрипта userdata, который будет выполняться во время создания ec2.
Скрипт должен добавлять пользователей. Предполагая, что вы используете linux на своем сервере bastion, фрагмент для добавления пользователей будет выглядеть примерно так
useradd -m -s /bin/bash <username>
mkdir /home/<username>/.ssh
chmod 700 /home/<username>/.ssh/
Copy the ssh key from a pre-determined location. In my case i have ssh
public keys for users in an S3 bucket (hey they are public keys)
aws s3 cp s3://path/pub-keys/user-id_rsa.pub /home/<username>/.ssh/authorized_keys
chmod 640 /home/<username>/.ssh/authorized_keys
chown -R <username>:<group> /home/<username>/.ssh/
Add the user to some group
usermod -a -G <somegroup> <username>
Q2. Можно ли использовать учетные данные AWS IAM для ssh при каком-либо едином входе в систему?
Для этого я бы рекомендовал прочитать документацию ниже, так как здесь задействовано несколько вещей, включая используемый вами дистрибутив. Но я не уверен, что это хорошее решение для описанного вами сценария.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-connect-methods.html
Комментарии:
1. Ваша оценка примерно верна, однако конечная цель-это какой-то способ, при котором Бастион берет общедоступные SSH-ключи, связанные с пользователями IAM, и использует их в качестве авторизованных пользователей, и когда эти пользователи или ключи IAM меняются, это отражается в реальном времени на Бастионе. Я хочу избежать перестройки AMI каждый раз, когда происходит смена пользователя, или управления открытыми ключами с помощью сценариев и S3 (именно это вы предложили, и я думал об этом). Однако кажется, что подключение экземпляра EC2 или подобное может быть единственным разумным способом достижения большинства целей.
2. Сначала я неправильно понял ваш вопрос и подумал, что бастионы эфемерны, поэтому я предложил использовать скрипт «userdata». К сожалению, я не вижу способа сделать это с помощью terraform, я думаю, вам придется подключиться к экземпляру EC2 или использовать инструмент управления конфигурацией, такой как ansible. Вы также можете попробовать интерфейс командной строки aws и запустить какой-нибудь скрипт на бастионе, который получает ключи от IAM, но опять же это будет скрипт. Еще одна идея, которая приходит мне в голову, заключается в том, что вы распространяете ключи при их создании, если бы вы использовали некоторую автоматизацию для создания ключей, это было бы легко.
3. Если бы Бастионы были эфемерными, это облегчило бы задачу, да. Приношу извинения за отсутствие ясности. Похоже, что то, как я хочу решить проблему, нереалистично, поэтому мне придется найти другой способ. Потенциально не имея бастиона вообще, и используя что-то похожее на EC2 Direct Connect, чтобы пользователи могли напрямую подключаться к своим эфемерным экземплярам пакетов, это решение.
4. Нет, я приношу извинения за то, что неправильно истолковал ваш вопрос. Я читал ваши другие комментарии, и если вы просто используете бастион в качестве хоста перехода, почему бы вам не создать VPN в AWS и не разрешить прямой доступ к экземплярам EC2. С помощью VPN вы можете сохранить IP-адреса в секрете, и вам действительно не нужен бастион. Но, честно говоря, ваша первоначальная проблема гораздо интереснее 🙂
5. Ха-ха, согласен, первоначальная проблема более интересна, но я возьму простое за интересное в любой день недели. 🙂 Возможно, решение VPN (или что-то подобное, такая общедоступная подсеть, которая разрешает трафик только на и с набора IP-адресов, находящихся под нашим контролем) — это правильный путь.