Active Directory 統合管理の夢(EC2編)

経緯

EC2のデフォルトでは、秘密鍵(xxx.pem)を利用してSSHアクセスをする。
この秘密鍵をチーム全員で共有することは論外であるが、意外とやっているところが多そう。

この構成は色々と危険性がある。
1. 誰がアクセスしているか分からないので、ユーザーごとにアクセス制御ができない。
2. 退職者が秘密鍵持っている場合、引き続きアクセスできるので、キーペアを変更する必要がある。
3. キーペアを変更すると、全員に秘密鍵を再配布する必要がある。

ユーザーごとにアクセス許可/拒否ができる機能をActive Directoryで実装できれば、楽なのに...

ユーザー1: 本番環境⇒OK 開発環境⇒OK
ユーザー2: 本番環境⇒NG 開発環境⇒OK

ということで、Active DirectoryにLinuxを参加させてアクセス制御をしてみます。

AmazonLinux2 on EC2の設定

AWS Managed ADを作成してあるので、AmazonLinux2のコマンドを入力していきます。
VPCのDHCPオプションセットを編集したり等あるのですが、とりあえず忘れないうちにコマンドだけを残しておきます。

REALMDのインストール

Linuxにアクセスする

ssh -i <xxx.pem> ec2-user@<x.x.x.x>

Redhatが推奨してるREALMD(SSSD)を使おうと思います。
REALMD を使用した ACTIVE DIRECTORY ドメインへの接続

yum -y install realmd

早速、Active Directory(以下AD)に接続する。

realm join <example.com> -U <admin>
realm: Couldn't join realm: Necessary packages are not installed: oddjob, oddjob-mkhomedir, sssd, samba-common-tools

REALMDを動かすための必要パッケージがないと言われるので、インストールする。
REALMDを使い簡単にSSSD(System Security Services Daemon)を設定する仕組みなのでSSSDが前提条件。
oddjob-mkhomedirは名前の通りADユーザのホームディレクトリを自動で作ってくれるものらしい。
他はあまり詳しくない(;^_^A

yum install -y oddjob oddjob-mkhomedir sssd samba-common-tools

もう一度、ADに接続する。--verboseを付けると動作結果がわかる。

realm join <example.com> -U <admin>　--verbose
 * Successfully enrolled machine in realm

成功したらしい。

sshd_configの編集

デフォルトのままだとパスワードログインが許可されていない(秘密鍵でのログインのみ)
なので、sshd_configを編集して許可します。

vi /etc/ssh/sshd_config

以下のように、
PasswordAuthentication yesをコメントインして
PasswordAuthentication noをコメントアウトする。

PasswordAuthentication yes
#PermitEmptyPasswords no
#PasswordAuthentication no

上記設定を反映させるため、sshdを再起動する。

systemctl restart sshd

ADのユーザーで、ログインできるようになる。

ssh <x.x.x.x> -l <username>@<example.com>

sssd.confの編集

デフォルトの状態だと
ssh 192.168.1.1 -l [email protected]
のようにユーザー名の後にディレクトリのDNS名を付けなければいけない。

ssh <username>@<x.x.x.x>
ユーザー名とIPだけで簡潔にログインしたいので、sssdも編集する。
ついでにホームディレクトリ名もユーザー名のみにする。

vi /etc/sssd/sssd.conf

use_fully_qualified_names = True をコメントアウトする。
fallback_homedir = /home/%u@%d @%dを削除する。

#use_fully_qualified_names = True
fallback_homedir = /home/%u

上記設定を反映させるため、sssdを再起動する。

systemctl restart sssd

以上でユーザー名のみのログインができるようになります。
ホームディレクディレクトリもユーザー名になっているはず。

ssh <username>@<xxx.xxx.xxx.xxx>
pwd
/home/testuser

sudo権限の編集

ADユーザーでsudoをすると
testuser is not in the sudoers file. This incident will be reported.
となり拒否される。

AWSのガイドに従いvisudoで編集する。
ディレクトリへのインスタンスの結合

visudo

ファイルの最後に以下を挿入する。example.comは自身のADに書き換える。

## Add the "AWS Delegated Administrators" group from the example.com domain.
%AWS\ Delegated\ [email protected] ALL=(ALL:ALL) ALL

これで、AWS Delegated Administratorsに所属しているユーザーはsudo権限が与えられた。

ログインアクセス制御

このままだと、ADユーザーは全員EC2にログインできるので、危険。
例えば、開発サーバーは、開発者のみにアクセス制限することが望ましい。

AWSドキュメントの通りsssd.confを編集してad_access_filterでフィルターできますが、
AWSドキュメント(アカウントのログインアクセスの制限)
せっかく扱いやすいrealmdをインストールしてるので、今回そちらを使用します。

一度全ユーザーを拒否します。

realm deny --all

現状のアクセス制御を表示します。

realm list

最後の行にlogin-policy: deny-any-loginとあり、全拒否が設定されていることが分かります。
この状態でSSHログインすると、Connection closed by x.x.x.x port 22となり拒否されます。

example.com
  type: kerberos
  realm-name: EXAMLE.COM
  domain-name: example.com
  configured: kerberos-member
  server-software: active-directory
  client-software: sssd
  required-package: oddjob
  required-package: oddjob-mkhomedir
  required-package: sssd
  required-package: adcli
  required-package: samba-common-tools
  login-formats: %U
  login-policy: deny-any-login

それではアクセス制御を設定していきます。
AWS Delegated Administratorsに所属しているユーザーと
testuserにアクセス許可をします。
(\<space> で空白のエスケープをしています)

realm permit --groups AWS\ Delegated\ Administrators
realm permit testuser
realm list
(略)
  permitted-logins: testuser
  permitted-groups: AWS Delegated Administrators

以上！