あまり日常的に触らないサービスの１つである。
何度もこの違いについて過去に調べてはいたが、使わないものは忘れてしまう。
メモがてら残す。
https://aws.amazon.com/jp/inspector/
また、脆弱性チェック対象のインスタンスは、エージェントをインストールする必要がある。
https://aws.amazon.com/jp/premiumsupport/technology/trusted-advisor/
の5つの項目について、チェックすることが出来るツール。
それぞれ１行でまとめると
AWS Inspector は脆弱性検知することが必要でエージェントが必須
AWS Trusted Advisor は AWS のベストプラクティスに沿って作られているかスキャン、レポーティングしてくれる機能
と考えておけば良さそうだ
{
"Id": "xxxxx",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "xxxxx",
"Action": [
"s3:GetObject"
],
"Effect": "Allow",
"Resource": "arn:aws:s3:::hoge-hoge",
"Principal": "*"
}
]
}
この設定をしていて アクションはステートメント内のどのリソースにも適用されません とエラーが出る
原因は、バケットのみ Resource として指定しているためであり、この問題を解消するには
"Resource": "arn:aws:s3:::hoge-hoge/*",
のようにバケット内のどのオブジェクトにアクセスを許可するかを必ず指定する必要がある。
AWS 管理のCMK は我々ユーザーで管理することはできないが、 3年ごとに自動でローテーションされる
AWS 管理の CMK AWS 管理の CMK のキーローテーションを管理することはできません。AWS KMS は AWS 管理の CMK を 3 年ごと (1095 日) に自動的にローテーションします。
https://docs.aws.amazon.com/ja_jp/kms/latest/developerguide/rotate-keys.html
なお、我々ユーザーが管理する CMK は 365 日に設定されている
キーの自動ローテーションを有効にすると、AWS KMS は有効にした日から CMK を 365 日ローテーションし、その後は 365 日ごとにローテーションします。
https://docs.aws.amazon.com/ja_jp/kms/latest/developerguide/rotate-keys.html
監査などを目的とし、どのリソースをどれだけ使われているか確認したいことがあるが、
それを確認するには AWS config が便利なので紹介。
とはいえ AWS config からリソースを選択するだけ。
s3 は通常、静的ウエブサイトをホストすることができるが、JavaScript 経由で バケットに対する GET/POST を行う際は注意が必要である。
S3 に hoge.com という名前でホストしたとする。
このバケットに保存されている JavaScript によって、S3 のエンドポイントである hoge.s3.ap-northeast-1.amazonaws.com に GET/POST を行おうとすると、
ブラウザは通常、別ドメインに対する接続しようとする JavaScript をブロックする。
CORS を使用すると、hoge.com からのクロスオリジンリクエストを許可できるようにバケットを設定することができる。
https://docs.aws.amazon.com/AmazonS3/latest/userguide/cors.html
カスタムIAM ポリシーを設定することで、MFA を有効化することができる。
"Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
ポイントは、
Conditiol 文を使用すると、ユーザーが MFA 認証されている場合にのみリソースを操作できるようになる。
aws:MultiFactorAuthPresent 句を true としてマークする必要がある。
参考情報
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html
ある時、
go get -v github.com/rubenv/sql-migrate/...
を実施したら出るようになった。
go get -v github.com/rubenv/sql-migrate/...
github.com/rubenv/sql-migrate (download)
get "gopkg.in/gorp.v1": found meta tag get.metaImport{Prefix:"gopkg.in/gorp.v1", VCS:"git", RepoRoot:"https://gopkg.in/gorp.v1"} at //gopkg.in/gorp.v1?go-get=1
(中略)
get "gopkg.in/yaml.v2": found meta tag get.metaImport{Prefix:"gopkg.in/yaml.v2", VCS:"git", RepoRoot:"https://gopkg.in/yaml.v2"} at //gopkg.in/yaml.v2?go-get=1
gopkg.in/yaml.v2 (download)
# cd .; git clone -- https://gopkg.in/yaml.v2 /go/src/gopkg.in/yaml.v2
Cloning into '/go/src/gopkg.in/yaml.v2'...
fatal: unable to access 'https://gopkg.in/yaml.v2/': server certificate verification failed. CAfile: none CRLfile: none
package github.com/rubenv/sql-migrate/sql-migrate
imports gopkg.in/yaml.v2: exit status 128
証明書によるエラーが発生している。
apt-get --allow-releaseinfo-change update && apt upgrade -y
sam local で自動で見に行く環境変数
sam （で立ち上がる docker）はデフォルトでそのディレクトリを見に行く作りになっている。
-v, --docker-volume-basedir TEXT
Specifies the location basedir where the SAM
file exists. If the Docker is running on a
remote machine, you must mount the path
where the SAM file exists on the docker
machine and modify this value to match the
remote machine.
ただし、公式資料らしき記載は help とこのパワポのみなので、もう少しドキュメントを充実してほしいところ。
個人で利用している GCP で、ある時予算の 50% に達したというメールが届いた。
調べてみると
Micro Instance with burstable CPU running in Americas
という項目で課金が発生していた。
自分が使っていたサービスは
Google Cloud の Google Compute Engine にはAlways Freeによる無料枠でサーバ１台たてていた。
GCE の無料枠として、f1-microというインスタンスタイプのサーバーとしてを無料で利用することができる。
ただし、運用するには弱小すぎるので実際にはサーバーとしては使えず、私のように勉強用サーバーとして使う人が多いだろう。
今回の件で掘り下げて調べてみると、原因はfi-micro に備わっている CPU バーストという機能ということがわかった。
https://cloud.google.com/compute/docs/machine-types#cpu-%E3%83%90%E3%83%BC%E3%82%B9%E3%83%88
> N1: f1-micro、g1-small 共有コア VM には、短時間のバーストに使用できる 1 個の vCPU があります。
なんらかのきっかけで CPU が足りなくなると勝手に課金し、バーストしてくれるらしい。
今回のアラート設定していたので3日目には気付きましたが、この設定してなかったら来月月初の請求書で気づくことになったと思います。
無料枠とはいえ料金のアラート設定は大事ですね。それでは。
curl コマンドで https 接続する際
curl: (60) SSL: no alternative certificate subject name matches target host name '127.0.0.1'
というエラーになることがある。
これは証明書の URL と、リクエストURL が一致しないことによる 証明書のエラーになる。
curl コマンドの場合 -k オプションでエラーを無視することができる
curl -k