S3エンドポイント利用してっとyumが通らない
ある日のことであった。
私は、おもむろにEC2からyum installコマンドをたたいたところ、
以下のようなエラーが出たではないか。
ということで、私が出会ったThe 虎舞竜(トラブル)事象について、ご紹介したいと思います。
今回は、『S3エンドポイント利用時においてyumコマンドが通らない！』件についてです。
※今回文章ばっかです。
いきなり本題
[ec2-user@ip-192-168-5-117 ~]$ sudo yum install squid
Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
Could not retrieve mirrorlist http://amazonlinux.ap-northeast-1.amazonaws.com/2/ core/latest/x86_64/mirror.list error was14: HTTP Error 403 - Forbidden
One of the configured repositories failed (Unknown),
and yum doesn't have enough cached data to continue. At this point the only
safe thing yum can do is fail. There are a few ways to work "fix" this:
- Contact the upstream for the repository and get them to fix the problem.
- Reconfigure the baseurl/etc. for the repository, to point to a working
upstream. This is most often useful if you are using a newer
distribution release than is supported by the repository (and the
packages for the previous distribution release still work).
- Run the command with the repository temporarily disabled
yum --disablerepo=<repoid> ...
will then just ignore the repository until you permanently enable it
again or use --enablerepo for temporary usage:
yum-config-manager --disable <repoid>
or
subscription-manager repos --disable=<repoid>
- Configure the failing repository to be skipped, if it is unavailable.
Note that yum will try to contact the repo. when it runs most commands,
so will have to try and fail each time (and thus. yum will be be much
slower). If it is a very temporary problem though, this is often a nice
compromise:
yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true
Cannot find a valid baseurl for repo: amzn2-core/2/x86_64
という感じで、yumが通りません。
ボク「いと、悔し」
と、思ひけるに、
原因はどうもS3エンドポイントで、アクセス制限を絞りまくっていたためであったようだった。
当時、S3エンドポイントを作成し、ルートテーブルをあるサブネットに関連付けていた。
その関連付けていたサブネットに所属したEC2に影響があったらしく、
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::pompom-s3-sgw-001",
]
}
]
}
↑のような感じで、S3エンドポイントのポリシーを書いていた。
要は、S3へのアクセスは、pompom-s3-sgw-001というバケットにのみアクセスを許可していたのだ。
そこで起こった今回の悲劇。
そこで、以下のように、ポリシーを修正した。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::pompom-s3-sgw-001",
"arn:aws:s3:::amazonlinux.*.amazonaws.com/*"
]
}
]
}
↑赤字の部位にリポジトリが入ってる。
で、あらためて、実行したところ
[ec2-user@ip-192-168-5-117 ~]$ sudo yum install squid
Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
amzn2core | 3.7 kB 00:00:00
amzn2extradocker | 3.0 kB 00:00:00
(1/5): amzn2core/2/x86_64/group_gz | 2.5 kB 00:00:00
(2/5): amzn2core/2/x86_64/updateinfo | 253 kB 00:00:00
(3/5): amzn2extradocker/2/x86_64/updateinfo | 69 B 00:00:00
(4/5): amzn2extradocker/2/x86_64/primary_db | 68 kB 00:00:00
(5/5): amzn2core/2/x86_64/primary_db | 44 MB 00:00:01
Resolving Dependencies
--> Running transaction check
---> Package squid.x86_64 7:3.5.20-15.amzn2.1.1 will be installed
--> Processing Dependency: squid-migration-script for package: 7:squid-3.5.20-15.amzn2.1.1.x86_64
--> Processing Dependency: perl(Digest::MD5) for package: 7:squid-3.5.20-15.amzn2.1.1.x86_64
--> Processing Dependency: perl(Data::Dumper) for package: 7:squid-3.5.20-15.amzn2.1.1.x86_64
--> Processing Dependency: perl(DBI) for package: 7:squid-3.5.20-15.amzn2.1.1.x86_64
--> Processing Dependency: libltdl.so.7()(64bit) for package: 7:squid-3.5.20-15.amzn2.1.1.x86_64
--> Processing Dependency: libecap.so.3()(64bit) for package: 7:squid-3.5.20-15.amzn2.1.1.x86_64
ボク「いと、をかし」
というわけで、中途半端な古文を交えつつも、
これで、整理すると、
① yumコマンドを実行してリポジトリである、S3に行こうとする
② ルートテーブルに従ってS3エンドポイントへ誘導される
③ エンドポイントで、ポリシーと照らし合わされる
④ ポリシー上許可されているリソースに対してだけアクセスが許されるが、特定バケットしか許可してないので、リポジトリに行けない。
という状況だったようです。
S3への閉域アクセスとしてよくよく使用されるS3エンドポイントですが、厳密なポリシーを敷くと、このように思わぬ事態に出会ってしまいました。
ただ、けがの功名と言うべきか、通信がちゃんとS3エンドポイントを利用している、という確認にもなりました。
同じ状況に陥った方の一助になれば、幸いです。
ではでは。
