2025-01-14

Amazon ECR レジストリポリシーの新しいバージョンへのアップグレードのお知らせに対応する

通知が来ていたので対応しておく

tl;dr

Amazon ECR レジストリポリシーの新しいバージョンへのアップグレードは手動で ECR クロスアカウントレプリケーションを設定していても、特に気にせず更新して問題ない

背景

AWS から通知が来ていたので対応する

お客様のアカウントが Amazon ECR レジストリポリシーの以前のバージョン (V1) [1] を使用していることをお知らせいたします。
このポリシーでは、ecr:ReplicateImage、ecr:BatchImportUpstreamImage、ecr:CreateRepository の 3 つの ECR IAM アクションのみがサポートされています。2024 年 12 月 26 日、Amazon ECR はすべての ECR アクションをサポートするレジストリポリシーの新しいバージョン (V2) のサポートを発表しました。これにより、お客様は Amazon ECR レジストリ内のすべてのリポジトリの権限を簡単に制御できるようになります [2]。
今回の提供の一環として、Amazon ECR は put-account-setting API と get-account-setting API に「REGISTRY_POLICY_SCOPE」という新しい設定を導入しました。サポートされる値は V1 と V2 です。新しい Amazon ECR アカウントは、自動的にレジストリポリシー V2 を使用します。
AWS コンソールまたは次の put-account-setting API [3] を使用して、アカウントをレジストリポリシー V2 に簡単に切り替えることができます。
aws ecr put-account-setting --name REGISTRY_POLICY_SCOPE --value V2 Amazon ECR レジストリポリシー V2 は、すべての AWS 商用リージョンと AWS 中国リージョンで一般提供されています。レジストリポリシー V1 は 2025 年 7 月 31 日以降はサポートされなくなるため、できるだけ早い時期にこの切り替えを行うことをお勧めします。この日付を過ぎると、アカウントは自動的にレジストリポリシー V2 に移行されますのでご注意ください。

[1] https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry-permissions.html
[2] https://aws.amazon.com/about-aws/whats-new/2024/12/amazon-ecr-expands-registry-policy-ecr-actions/
[3] https://docs.aws.amazon.com/AmazonECR/latest/APIReference/API_PutAccountSetting.html

ecr put-account-setting コマンドでさくっといけそう。かつ今年の夏には期限が来そう。放っておいても移行されるらしいが確認していく

ECR レジストリポリシーって何

ECR のリポジトリではなくレジストリに対するアクセス制限

バージョンの違いって何

紹介されているレジストリ権限のドキュメントに記載がある通り
これまではレジストリポリシーで設定できていたアクションに制限があったらしい
Amazon でのプライベートレジストリのアクセス許可 ECR - Amazon ECR

V1 — バージョン 1 の場合、Amazon はプライベートレジストリレベルでECRのみ次のアクセス許可を適用します。
- ecr:ReplicateImage – ソースレジストリと呼ばれる別のアカウントに、そのイメージをレジストリにレプリケートする許可を付与します。これは、クロスアカウントレプリケーションのみに使用されます。
- ecr:BatchImportUpstreamImage – 外部イメージを取得し、プライベートレジストリにインポートするアクセス許可を付与します。
- ecr:CreateRepository – プライベートレジストリにリポジトリを作成するアクセス許可を付与します。レプリケートまたはキャッシュされたイメージを保存するリポジトリがプライベートレジストリにまだ存在しない場合は、この許可が必要となります。
V2 - バージョン 2 の場合、Amazon はポリシー内のすべてのECRアクションECRを許可し、すべてのECRリクエストにレジストリポリシーを適用します。

なるほど
これによってリポジトリ単位ではなくレジストリでアクセス制御ができるようになって嬉しいらしい

ちなみに今回は ECR のクロスアカウントレプリケーションを設定しているレプリケーション先 AWS アカウントから通知されていた
念の為設定を確認しておく

レプリケーション元では V2 になっていた

$ aws ecr get-account-setting --name REGISTRY_POLICY_SCOPE 
{
    "name": "REGISTRY_POLICY_SCOPE",
    "value": "V2"
}

レプリケーション先では通知の通り V1

$ aws ecr get-account-setting --name REGISTRY_POLICY_SCOPE                                                            
{
    "name": "REGISTRY_POLICY_SCOPE",
    "value": "V1"
}

俺達のクラスメソッドを見る限り副作用もないらしいのでやっていく

既存設定（手動設定した ECR レプリケーション）への影響

ちなみに作業対象は AWS CDK で管理している AWS アカウントだが、構築した段階の CDK バージョンで ECR クロスアカウントレプリケーションが設定できず手動設定しているということで適用して設定が変わっても何も検知されない。かなしい

念の為手動設定した内容をおさらいして有効化の影響がないか確認しておく ECR のクロスアカウントレプリケーションの設定は以下の通り

レプリケーション元
1. レジストリのレプリケーションルールから設定する
2. レプリケーションルールを追加
3. 送信先タイプに クロスアカウント を選択
4. 送信先アカウントを設定
5. 送信するリポジトリに関するフィルターを追加
レプリケーション先
1. レジストリのアクセス許可から設定する
2. ステートメントを適切に設定する

レプリケーション元では今回設定を変更しないので無視
レプリケーション先の レジストリアクセス許可 が変更されないかくらいをみておけばよさそうか

なおサブコマンドの説明を見た感じでも影響は特になさそう put-account-setting — AWS CLI 2.22.34 Command Reference

BASIC_SCAN_TYPE_VERSION か REGISTRY_POLICY_SCOPE を設定できるコマンドらしい

ECR レジストリポリシーのアップグレード

作業前の確認

作業前の状態を確認しておく
作業時点の AWS CLI （2.22.13）でレジストリの情報が取れそうなサブコマンドは以下

describe-registry
get-registry-policy
get-registry-scanning-configuration

それぞれ確認してみる

$ aws ecr describe-registry 
{
    "registryId": "012345678901",
    "replicationConfiguration": {
        "rules": []
    }
}

$ aws ecr get-registry-policy                                                                                         
{
    "registryId": "012345678901",
    "policyText": "{\n  \"Version\" : \"2012-10-17\",\n  \"Statement\" : [ {\n    \"Sid\" : \"EcrCrossAccountReplication\",\n    \"Effect\" : \"Allow\",\n    \"Principal\" : {\n      \"AWS\" : \"arn:aws:iam::109876543210:root\"\n    },\n    \"Action\" : [ \"ecr:CreateRepository\", \"ecr:ReplicateImage\" ],\n    \"Resource\" : \"arn:aws:ecr:ap-northeast-1:012345678901:repository/*\"\n  } ]\n}"
}

$ aws ecr get-registry-scanning-configuration
{
    "registryId": "012345678901",
    "scanningConfiguration": {
        "scanType": "BASIC",
        "rules": []
    }
}

レプリケーション先のレジストリとしてレプリケーション元の AWS アカウント 109876543210 からのアクセスを受け付けるようになっている（さっきの手動作業の 2.2 の内容どおり）設定後にこのあたりが変わらないことくらいを見ればよさそう

設定変更

通知されたコマンドを実行

aws ecr put-account-setting --name REGISTRY_POLICY_SCOPE --value V2

特にエラーなく終了

$ aws ecr put-account-setting --name REGISTRY_POLICY_SCOPE --value V2
{
    "name": "REGISTRY_POLICY_SCOPE",
    "value": "V2"
}

作業後

設定変更前と特に差分がないか確認

レプリケーション先でも V2 になった

$ aws ecr get-account-setting --name REGISTRY_POLICY_SCOPE           
{
    "name": "REGISTRY_POLICY_SCOPE",
    "value": "V2"
}

レジストリのサブコマンドでも特に変化はない

$ aws ecr describe-registry 
{
    "registryId": "012345678901",
    "replicationConfiguration": {
        "rules": []
    }
}

$ aws ecr get-registry-policy                                                                                         
{
    "registryId": "012345678901",
    "policyText": "{\n  \"Version\" : \"2012-10-17\",\n  \"Statement\" : [ {\n    \"Sid\" : \"EcrCrossAccountReplication\",\n    \"Effect\" : \"Allow\",\n    \"Principal\" : {\n      \"AWS\" : \"arn:aws:iam::109876543210:root\"\n    },\n    \"Action\" : [ \"ecr:CreateRepository\", \"ecr:ReplicateImage\" ],\n    \"Resource\" : \"arn:aws:ecr:ap-northeast-1:012345678901:repository/*\"\n  } ]\n}"
}

$ aws ecr get-registry-scanning-configuration
{
    "registryId": "012345678901",
    "scanningConfiguration": {
        "scanType": "BASIC",
        "rules": []
    }
}

CDK で diff かけても特に差分はでていなかった問題ないね

結論

手動で ECR クロスアカウントレプリケーションを設定していても Amazon ECR レジストリポリシーの新しいバージョンへのアップグレードは気にせず更新して問題ない

蛇足

ちなみに AWS CDK 2.175.1 時点では L1 Constructs だけど ECR レプリケーションが設定できるようになっているぽい class CfnReplicationConfiguration (construct) · AWS CDK

2017-02-05

AWS の Amazon Inspector を定期実行させる

Amazon Web Service

今年の1月に Amazon Inspector の定期実行のための Lambda の blueprint が公開されました。
Amazon Inspector launches support for Ubuntu 16.04 and an AWS Lambda blueprint for assessment scheduling
これで Inspector の定期実行が楽になったよ。

公式手順

Amazon Inspector とは

AWS が用意したルールを使ってOSの脆弱性をチェックしてくれる
AWS 上のインスタンスしか利用できない
エージェントの導入が必要

AWSのインスタンス限定やエージェント導入が必要という制限がありますが、AWSで運用しているなら問題なく利用できるのでは。

Inspector 設定

既に設定済みであれば、スルーで

評価ターゲットの設定
- EC2 インスタンスに設定するタグを定義して Inspector の実行対象を設定する
評価テンプレートの設定
- 実行されるルールパッケージを選択する
- OS が特定の AmazonLinux （2014.09～2015.03）でない限り、CIS OS Security Configuratio Benchmarks-1.0 は不要

Lambda 設定

Select BluePrint にて inspector-scheduled-run を選択する
CloudWatch Events の設定を行う
- デフォルトで 1、5、15、60分毎、1日毎、平日17時が選択可能
  - 毎週水曜の19時とかなら cron(0 10 ? * wed *) ※時刻はGMTで評価される
  - 毎月1日の19時とかなら cron(0 10 1 * * *) ※時刻はGMTで評価される
- 有効化は後でもよい
Function の設定
- Runtime は Node.js 4.3 を設定
- Environment variables の assessmentTemplateArn に 1で設定した評価テンプレートのARNを設定
- Hundler は index.handler を設定
- Role の設定は以下を設定

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "inspector:StartAssessmentRun",
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "*"
    }
  ]
}

これで日々の脆弱性チェックが少しは楽になるかと。

Amazon Web Services完全ソリューションガイド

作者: 大澤文孝,川上明久,大嶋和幸
出版社/メーカー: 日経BP社
発売日: 2016/12/22
メディア: 単行本
この商品を含むブログを見る

2016-09-21

NTP 再整理

Linux

NTP とは

Network Time Protocol の略
時刻情報を取得するためのプロトコル
時刻同期と呼ばれる
時刻を合わせておくことで情報解析が捗る

時刻同期の実現方法

自動で時刻を同期させるためには以下の2つがある

ntpd を起動させて、時刻同期先を指定する
定期的に ntpdate を実行する（注）

それぞれの違いは以下の通り

ntpd と ntpdate の違い

ntpd

設定次第で1秒の時間を調整してうまいこと時刻を同期してくれる
常駐して動作する

ntpdate

強制的に時刻を同期してくれる
随時で動作する

よくあるパターンとしてサーバの起動時に ntpdate を仕込んで、起動したら ntpd を動作させる
- 時刻が大きくズレすぎていると同期できないことがあるため
なお、同じポートを使うため、どちらかが起動しているとどちらかは使えない。

ntpd をうまいこと設定する

時刻同期には以下のモードがある。

STEP モード
SLEWモード

STEPモード

ズレている時間を一気に修正する

SLEWモード

1秒の時間を調整して徐々に修正する
起動時に ntpd -x で起動するか、
/etc/ntp.conf にて tinker step 0 に設定する必要がある

基本的には SLEW モードがオススメ

うるう秒について

※ 23:59:59 と 00:00:00 の間にうるう秒が挿入される場合。

通常の時刻の流れ

23:59:59.000000 →（略）→ 23:59:59.999999 → 00:00:00.000000

うるう秒の場合

23:59:59.000000 →（略）→ 23:59:59.999999 → 23:59:59.000000 →（略）→ 23:59:59.999999 → 00:00:00.000000

NTP ではうるう秒のタイミングで Leap Indicator （LI）を送る。 ntpd が STEP モードで動作している場合、LI が送られると上記のように一度時間が逆進する。

対策

SLEW モードで動作させておくとズレが生じて少しづつ調整する。また Leap Indicator を送らないので影響も出さない。

動作等々

設定ファイル
- /etc/ntp.conf
時刻同期状態確認

$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*ntp-a2.nict.go. .NICT.           1 u  198 1024  177   18.326    5.511   4.370
+ntp2.jst.mfeed. 133.243.236.17   2 u  490 1024  377   15.422    5.076   2.296

# NTPサーバの前に * or + が表示されていれば同期している
# 空白の場合、時刻同期中

手動同期

$ sudo ntpdate ntp.jst.mfeed.ad.jp
21 Sep 13:28:44 ntpdate[9121]: adjust time server 210.173.160.27 offset 0.004727 sec

ままならないものだ。いろいろとこぼれ落ちていくものである。

ソフトウェアデザイン 2016年 10 月号 [雑誌]

出版社/メーカー: 技術評論社
発売日: 2016/09/17
メディア: 雑誌
この商品を含むブログを見る

2016-07-26

mintty に monokai カラースキーム設定

Windows

WindowsOS 変えてから mintty のカラースキームが気持ちキツい気がする。
カラースキームを変更してみる。

mintty にカラースキームを適用する

やってみたがなんか物足りんな。。。
背景は黒いほうが好きマンだからな。
しかし、みんな Solarized なのか？
それとも BackGroud だけいじってんのかな？

ググったらリポジトリ公開してる人がいた。
mintty-color-schemes

試してみる。
1. ダウンロードして適当なディレクトリに解凍
2. 設定したいカラースキーム名のファイルの内容を .minttyrc に追記
※ .minttyrc はデフォルトなら C:\MinGW\msys\1.0\home\USERNAME にあるはず

簡単。

余談だけど ReadMe がディ・モールトベネ

2016-07-25

AWS Config にて設定していない RDS の通知が届くようになった

Amazon Web Service

7/22 から以下の通知が届くようになった。

[AWS Config:ap-northeast-1] AWS::RDS::DBSnapshot hogehoge Created in Account fugafuga

AWS Config に RDS リソースなんて設定してないけどなと思いつつ確認した。

このリリースが原因ぽい
影響範囲を確認したところ

RDS DB instance is associated with
* EC2 security group
* RDS DB security group
* RDS DB subnet group

なるほど。
確かに EC2 Sevcurity Group の notification は受け取っている。
だからか。

これはでも RDS リソース選択してなかったけども記録されるように（課金対象に）なるのかな。。

2016-07-20

todoist の web 版で toggle 連携が表示されなくなっていた

その他

chrome を使ってるんですが todoist と toggle でタスクと時間管理をしております。
超便利。

この子達は連携させることで、以下の通りタスクベースでのお仕事を手助けしてくれ、大変重宝しておりました。

todoist の画面からタスクを確認
タスク着手時に toggle を start
toggle を stop してタスクを完了させる

問題

ただ PC の 10 への移行した辺りから、web 版と toffle timer との連携ボタンが表示されなくなっていた。
わざわざ toggle のボタンを押さねばならない。

こうだったのが
f:id:tesiri:20160720100217p:plain

こうなってた
f:id:tesiri:20160720100245p:plain

超不便。

対処

toggle 側の拡張機能の設定の問題だった模様

1. chrome の設定 → 拡張機能を選択して、toggle の拡張機能を表示
2. オプションを選択する
f:id:tesiri:20160720100220p:plain 3. Permissions タブを選択する
f:id:tesiri:20160720100227p:plain 4. Url Permissions 欄に todoist と入力（入力途中で絞り込まれるはず） f:id:tesiri:20160720100231p:plain 5. todoist.com を有効化する f:id:tesiri:20160720100241p:plain

設定画面をとじて todoist画面を再読込すると表示されるようになった
よかったよかった

2016-07-16

アプリケーションログ（ソース：CAPI2、ID4107 )の出力原因について

Windows

概要

WindowsServer 2008 R2 SP1 （Standard Edition ）にてアプリケーションログにエラーが出力されていた。

イベントログ　：アプリケーションログ
ソース　：CAPI2
ID　：4107
レベル　：エラー
内容
次の自動更新 cab からサードパーティのルート一覧シーケンス番号を抽出できませんでした。http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab エラーは次のとおりです。現在のシステム時計または署名ファイルのタイムスタンプで確認すると、必要な証明書の有効期間が過ぎています。

オフライン環境なので、ルート証明書が取れないのは想定通り。
しかし出力されるサーバと出力されないサーバがあり、差が気になったので確認した。

原因

MSサポートに問合せた結果、以下の通りだった。

ルート証明書更新プログラム機能が原因
- ルート証明書更新プログラム機能の動作は以下のとおり
  1. 各プログラム等で証明書の検証が行われる
  2. CA証明書がインストールされているか確認する
  3. インストールされておらず、ルート証明書更新プログラム機能が有効な場合、CA 証明書の取得が試行される
  4. ローカルに取得された authrootstl.cab のキャッシュ情報の有無を確認する
  5. キャッシュが存在している場合は、有効であるかを確認する
  6. 有効ではない (署名証明書が有効期限切れ等) 場合イベントが記録される
ルート証明書更新プログラムは、一度でもインターネット接続した環境では継続的に再取得しようとする

確かに構築時にインターネット接続したマシンのみ出力されていた。

対処

ルート証明書更新プログラムの無効化

手順

指示された手順を実施
今回は当該マシンがオフライン環境かつワークグループ環境※だった

スタートメニューより、”gpedit.msc” と入力し、[OK] をクリックする
ローカルグループポリシーエディターが開くので以下を確認する [コンピュータの構成] -> [Windowsの設定] -> [セキュリティの設定] -> [公開キーのポリシー] -> [証明書パス検証の設定]
[証明書パス検証の設定] を右クリック、[プロパティ] を開く
[ネットワークの取得] タブより、以下の通り設定を行い、[OK] をクリックする
- [これらのポリシーの設定を定義する] 　：有効
- [Microsoft ルート証明書プログラムで証明書を自動更新する] 　：無効

上記手順で以下のレジストリが作成され、ルート証明書更新プログラムが無効化される。

キー　： HKEY_LOCAL_MACHINE\Software\policies\Microsoft\SystemCertificates\AuthRoot
REG_DWORD　： DisableRootAutoUpdate
値　：1

※補足

インターネット環境に接続できる場合は以下の手順内のキャッシュの削除で抑止されることもある Windows Vista、Windows Server 2008、および以降のバージョンの Windows および Windows Server のアプリケーションログにイベント ID 4107 またはイベント ID 11 が出力される
ドメインに所属している場合はドメイン、ローカルどちらのポリシーでもよいが適用範囲に注意

うむ。抑止された。