{
"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
Dockerを使ってMySQLを簡単に起動する際、外部からの接続設定にちょっとしたコツが必要です。
この記事では、その手順をシンプルにまとめています。
基本的には、MySQLの設定を変更して、どのホストからでも接続を受け入れるようにする必要があります。加えて、Dockerコンテナ内のMySQLユーザー設定も変更する必要があります。
以下のコードを実行します:
git clone https://github.com/GitSumito/CodeArsenal.git
cd CodeArsenal/mysql-external-access
sh ./main.sh
custom_my.cnf という設定ファイルを作成し、MySQLがどのホストからでも接続を受け入れるように bind-address を設定します。custom_my.cnf をMySQLの設定ディレクトリにマウントします。docker exec を使用してMySQLコンテナ内でユーザー設定を行います。この例では、任意のホストからの接続を受け入れるrootユーザーを作成しています。この設定は開発やテスト環境での利用を想定しています。セキュリティの観点から、本番環境での利用は推奨しません。特に、パスワードなしのrootユーザーを外部から接続できるようにする設定は、公開環境での利用は避けてください。