ヒアストリング

bashのヒアストリング <<< を知らなかったのでメモをしておきます。

説明

<<< の後にくる文字列や変数の内容を標準入力に流し込む

• 例

$ test_string="foobar"

# リダイレクト
$ cat < "${test_string}"
bash: foobar: No such file or directory

# ヒアストリング
$ cat <<< "${test_string}"
foobar

セキュリティグループに自分のパブリックIPアドレスを設定する

AWSでリソースを作ってる時、自分以外はアクセスさせたくない状況がありますね。そういう時はSecurity Groupに自分のパブリックIPを指定するわけだけど、terraformでやってるといちいち自分で調べたりして設定するのはやってられません。で、調べたところクラスメソッドさんのblogがわかりやすくて良い感じ。自分用にメモを残しておきます。

アイデア

• TerraformのHTTP Providerを利用して、自分のPublic IPをData SourceとしてTerraformのリソース化
  • HTTP ProviderのData SourceはHTTP ResponseをData Source化してくれる
• あとはこのData SourceをSecurity groupのIngressルールのCIDRとして追加

サンプル

• こんな感じ。パラメタで指定できるようにもしてる。
• chompの説明はこちら

terraform {
  required_providers {
    http = {
      source  = "hashicorp/http"
      version = "~>2.0"
  }
}

data "http" "ipv4_icanhazip" {
  url = "http://ipv4.icanhazip.com/"
}

variable "allowed_cidr" {
  default = null
}

locals {
  current_ip   = chomp(data.http.ipv4_icanhazip.body)
  allowed_cidr = (var.allowed_cidr == null) ? "${local.current_ip}/32" : var.allowed_cidr
}

resource "aws_security_group_rule" "allow_ssh" {
  type              = "ingress"
  from_port         = 22
  to_port           = 22
  protocol          = "tcp"
  cidr_blocks       = [local.allowed_cidr]
  security_group_id = <security_group_id>
}

VPCのデフォルトセキュリティグループの無効化

デフォルトセキュリティグループとは

• AWSではVPCを作成すると、デフォルトセキュリティグループが作成される
• EC2インスタンス作成時などに、明示的にセキュリティグループを指定しなかった場合、該当リソースに自動的に割り当てられる
• 一方で、このセキュリティグループのinboundルールは、デフォルトセキュリティグループ内の通信は全てのプロトコルで許可しており、意図せず通信できてしまったりする
• なので、デフォルトセキュリティグループの利用は非推奨なわけだけど、削除ができないので、別途対応が必要

対応方法

• 全部のルールを削除する (or 最低限inboundルールは全削除)

Terraformでの実装方法

結論: aws_default_security_groupリソースを利用する

• リンク先に説明があるとおり、このリソースはちょっと特殊
  • このリソースがapplyされると、Terraformはこのセキュリティグループのingress/egressルールを全削除
  • その後、リソース内で指定されているルールを追加

When Terraform first adopts the default security group, it immediately removes all ingress and egress rules in the Security Group. It then creates any rules specified in the configuration. This way only the rules specified in the configuration are created.

• ということは、全部のルールを削除するには、リソースだけterraformのマニフェストで定義してあげて、ルールを空にしておけばよい
• こんな感じ

resource "aws_default_security_group" "default_sg_vpc0" {
  vpc_id = <vpc_id>
}

hashicorp/terraform docker イメージを使う

hashicorp公式のdockerイメージの使い方について調べてもあまり出てこなかったのでメモを残しておく。例えば terraform plan を実行するときはこんな感じ。

$ docker run -it --name tf --rm -w /workspace -v ${PWD}:/workspace --env-file tf.env hashicorp/terraform:0.12.24 plan

• tf.env ファイルに必要な環境変数書いておく*1
• -w でワーキングディレクトリを指定
• ワーキングディレクトリにホストのカレントディレクトリをマウント
  • カレントディレクトリにmain.tf等々がある想定

*1:AWSのアクセスキーとか

スクリーンショットの取り方

Macだと Command + 4 でサクっと画面の好きな部分を選択してScreenShot取れるけど、Fedoraで同様のことをやる方法を調べたところfedora MAGAZINEですぐ見つかった。Fedora*1の場合、gnome-screenshotで簡単にできる模様。

以下、引用

• Printscreen key – grab a screenshot of the whole desktop and save it to your Pictures folder
• Alt + Printscreen – Take a screenshot of the currently focused window and save it to your Pictures folder
• Shift + Printscreen – Select an area to grab and save it to your Pictures folder.
• Ctrl + Printscreen – grab a screenshot of the whole desktop and copy it to the clipboard
• Ctrl + Alt + Printscreen – grab a screenshot of the currently focused window and copy it to the clipboard
• Ctrl + Shift + Printscreen – Select an area to grab and copy it to the clipboard

*1:というかGnome

AWS Patch Managerを利用してみる

AWS Systems Manager Patch Managerとは

読んで時の如しですが、公式ドキュメントによると下記。

AWS Systems Manager Patch Manager automates the process of patching managed instances with both security related and other types of updates.

まあec2インスタンスへのpatch適用を自動化してくれるサービスです。あまり個人では使う機会がないのでひとまず試してみた。

使い方概要

作成が必要なリソース

Patch Managerを使うには下記のリソースを作成する必要がある。Patch groupはオプション。無くても問題なし。

• Patch baseline
• Patch group (optional)

各リソースの説明

Patch baseline

パッチを当てるルールみたいなもの。どのパッチを当てるかとか、自動的に承認するルールとか、承認しないルール等々設定可能。AWSが事前定義しているものも使えるし、自分で定義して(Custom Patch baseline)利用することも可能。Patch Managerを利用する場合、まずはPatch baselineを作成／選択する。詳細は公式ドキュメント読むこと。

Patch Group

同じPatchを適用するec2インスタンスのグループみたいなもの。Patch baselineに紐づける。要は紐づけたインスタンス群に対してPatch baselineが適用される。

PatchGroupに関して個人的にわかりにくかったこと => Patch Groupというリソースが明示的には存在しないという部分*1。実際Patch Groupって何なのというと、ec2インスタンスのタグです。Patch Group というKeyを設定し、Valueが同じもののグループ。例えば下記のようなタグが付いたインスタンスの集合が prod server という名の Patch Groupという感じ。

Key	Value
Patch Group	prod server

こちらも公式ドキュメント読めば分かる。

Patch Manager利用時の流れ

概要

1. Patch Baselineを選択／作成
2. Patch Groupを作成 (Patch Groupのタグを付けてec2インスタンスを作成)
3. Patch Configurationを作成

Patch Baselineを選択／作成

今回は自分でPatch Baselineを作成し適用してみる。Management Consoleで作成。詳細は公式ドキュメントを読んで設定する。

今回設定したもの

Patch baseline details

• Name: my-test-patch-baseline
• Operating system: Amazon Linux2
• Default patch baseline (チェックなしのまま)
  • これチェックすると、上で選んだOSのインスタンスに関して今回作成するpatch baselineがデフォルトとして自動で適用される

Approval rules for operating systems

• Product: All
• Classification: All
• Severity: All
• Auto-approval: Approve patches released up to a specific date
  • テストするために適当に2018-10-01とかに設定 ((後で2つインスタンス作成。1つはこの日付けより前に作成されたAMI、もうひとつはこの日付けより後に作成されたAMIでインスタンスを作成)
• Include nonsecurity updates: チェック

こんな感じ。

Patch Groupを作成

ec2インスタンスの作成

Key = Patch Group / Value = patch-test としたタグを付けてec2インスタンスを作成。今回は下表の2つのAmazon Linux2 AMIを利用。

----------------------------------------------------------------------------
|                              DescribeImages                              |
+------------------------------------------------+-------------------------+
|  amzn2-ami-hvm-2.0.20200917.0-x86_64-gp2       |  ami-0ce107ae7af2e92b5  |
|  amzn2-ami-hvm-2.0.20180810-x86_64-gp2         |  ami-08847abae18baa040  |
+------------------------------------------------+-------------------------+

インスタンス作成。

Patch GroupをPatch baselineに紐づけ

作成したPatch baselineの詳細を表示して、Actions --> Modify patch groups --> patch-testを入力してAdd 。するとこんな感じでPatch Groupに追加される。

Patch Configuration作成

Patchを適用するのにPatch Configurationを設定する必要がある。今回設定したものは下記。 - Instances to patch: Select a patch group .... patch-testを指定 - Patching schedule: Skip scheduling and patch instances now (テストなのですぐ適用) - Patching operation - テスト１回目：Scan only: これでpatch baselineで設定したポリシに違反しているか(complianceがどうなるのか)チェックしてみる - テスト２回目：Scan and Install: インストールしてみてComplianceのチェックがどうなるか確認

こんな感じ。

ひとまず設定して、Configure patchingをクリック。

テスト

1回目

• Configure patchingをクリックすると、直にScanが始まるはず
• Scanの進捗状況はRunCommandから確認可能。走り終わっていたらCommand historyにある。
• 走り終わっていたら、Complianceへ行って状況を確認
  • Patchのrawにて、Compliant resourcesとNon-Compliant resourcesがそれぞれ1になっているはず
• Non-Compliant resourcesの 1 をクリックすると、フィルタリングが更新され、下に該当インスタンスが表示される。インスタンスIDがリンクになっているのでそれをクリックするとManaged Instancesの該当インスタンスの画面へ推移。Patchの適用状況が確認可能。

2回目

• 今回はPatch 適用まで実施。1回目でNon-Compliant resourcesとなっていたインスタンスがPatch適用後にCompliant resourceとなるはず
• 1回目同様Patch Configurationを作成。今回は Scan and Install を選択
• 適用して待つ(RunCommandで状態を確認可能)
• Complianceで状態を確認
  • 素晴らしい。Non compliant resources --> Compliant resourcesとなっている
• Managed InstanceからPatchの適用状況も一応確認するとPatchが当たっているのが分かる*2

まとめ

• SSM Patch Managerを使ってec2インスタンスにPatchを適用してみた
• Patch Baseline/Patch Group/Patch Configurationを作成する必要あり
• Patch Groupはec2インスタンスのタグ
• Patch適用、適用中の状態確認、インスタンスのPatchの適用状況等等SSMの各種サービスで確認可能

SSM便利ですね。

*1:Patch Groupを作成するとか不可能

*2:GeoIP.x86_64とか

古いAMIを見つける

AWS SSMのPatchManagerで遊んでみようと思いあえて古いAMIを利用したかったんだけど、どうやって古いの見つければ良いのか分からなかったので検索。そのものずばりな手順がこちらで紹介されていました。さすがクラスメソッドさん。

上記記事にはOS毎の取得方法が記載されていますが、今回はAmazonLinux2の古いAMIを使いたかったので下記な感じ。

 
$ aws ec2 describe-images --owners amazon --filters "Name=name,Values=amzn2-ami-hvm*x86_64-gp2" --query 'reverse(sort_by(Images, &CreationDate))[].[Name,ImageId]' --output table
----------------------------------------------------------------------------
|                              DescribeImages                              |
+------------------------------------------------+-------------------------+
|  amzn2-ami-hvm-2.0.20200917.0-x86_64-gp2       |  ami-0ce107ae7af2e92b5  |
|  amzn2-ami-hvm-2.0.20200904.0-x86_64-gp2       |  ami-0053d11f74e9e7f52  |
|  amzn2-ami-hvm-2.0.20200824.0-x86_64-gp2       |  ami-0f4c5db25b18ba70d  |
|  amzn2-ami-hvm-2.0.20200722.0-x86_64-gp2       |  ami-0cc75a8978fbbc969  |
|  amzn2-ami-hvm-2.0.20200617.0-x86_64-gp2       |  ami-06ad9296e6cf1e3cf  |
|  amzn2-ami-hvm-2.0.20200520.1-x86_64-gp2       |  ami-0a1c2ec61571737db  |
|  amzn2-ami-hvm-2.0.20200406.0-x86_64-gp2       |  ami-0f310fced6141e627  |
|  amzn2-ami-hvm-2.0.20200304.0-x86_64-gp2       |  ami-052652af12b58691f  |
|  amzn2-ami-hvm-2.0.20200207.1-x86_64-gp2       |  ami-0af1df87db7b650f4  |
|  amzn2-ami-hvm-2.0.20191217.0-x86_64-gp2       |  ami-011facbea5ec0363b  |
|  amzn2-ami-hvm-2.0.20191116.0-x86_64-gp2       |  ami-068a6cefc24c301d2  |
|  amzn2-ami-hvm-2.0.20191024.3-x86_64-gp2       |  ami-0064e711cbc7a825e  |
|  amzn2-ami-hvm-2.0.20190823.1-x86_64-gp2       |  ami-0ff21806645c5e492  |
|  amzn2-ami-hvm-2.0.20190618-x86_64-gp2         |  ami-0c3fd0f5d33134a76  |
|  amzn2-ami-hvm-2.0.20190612-x86_64-gp2         |  ami-084040f99a74ce8c3  |
|  amzn2-ami-hvm-2.0.20190508-x86_64-gp2         |  ami-00d101850e971728d  |
|  amzn2-ami-hvm-2.0.20190313-x86_64-gp2         |  ami-0f9ae750e8274075b  |
|  amzn2-ami-hvm-2.0.20190228-x86_64-gp2         |  ami-097473abce069b8e9  |
|  amzn2-ami-hvm-2.0.20190218-x86_64-gp2         |  ami-05cd6c87a37390178  |
|  amzn2-ami-hvm-2.0.20190115-x86_64-gp2         |  ami-0d7ed3ddb85b521a6  |
|  amzn2-ami-hvm-2.0.20190110-x86_64-gp2         |  ami-0bab560bf1ee352f5  |
|  amzn2-ami-hvm-2.0.20181114-x86_64-gp2         |  ami-0a2de1c3b415889d2  |
|  amzn2-ami-hvm-2.0.20181024-x86_64-gp2         |  ami-00f9d04b3b3092052  |
|  amzn2-ami-hvm-2.0.20181008-x86_64-gp2         |  ami-04d3eb2e1993f679b  |
|  amzn2-ami-hvm-2.0.20180924-x86_64-gp2         |  ami-06962fe7164c1fe7b  |
|  amzn2-ami-hvm-2.0.20180810-x86_64-gp2         |  ami-08847abae18baa040  |
|  amzn2-ami-hvm-2.0.20180622.1-x86_64-gp2       |  ami-e99f4896           |
|  amzn2-ami-hvm-2017.12.0.20180509-x86_64-gp2   |  ami-2724cf58           |
|  amzn2-ami-hvm-2017.12.0.20180328.1-x86_64-gp2 |  ami-8fbab2f3           |
|  amzn2-ami-hvm-2017.12.0.20180115-x86_64-gp2   |  ami-c2680fa4           |
|  amzn2-ami-hvm-2017.12.0.20180109-x86_64-gp2   |  ami-6be57d0d           |
|  amzn2-ami-hvm-2017.12.0.20171212.2-x86_64-gp2 |  ami-2a34b64c           |
+------------------------------------------------+-------------------------+

すばらしい。