Aurora Severless V2 の DB ユーザーに GRANT ALL PRIVILEGES をするとエラーが出たので対処をまとめた

タダです.

Aurora Serveless V2 で管理者ユーザーと同等の権限を持つ DB ユーザーを作りたいと思い, GRANT ALL PRIVILEGES でユーザーに権限を付与しようとしたら実行ができないことを知りました.この記事ではどのように対応したのかをまとめます.

事象の概要

Aurora Serveless V2 に管理者ユーザーと同等のユーザー(今回は blog というユーザー)を作りたいと思ったが,GRANT ALL PRIVILEGES を実行したら下記のエラーがでました.AWS の解説ページでも GRANT ALL PRIVILEGES が紹介されておらず管理者ユーザーの権限を確認して同じ権限を振るという案内がされています.

> GRANT ALL PRIVILEGES ON *.* TO 'blog'@'%';
ERROR 1045 (28000): Access denied for user 'admin'@'%' (using password: YES)

aws.amazon.com

管理者ユーザーの権限を確認する

そこで管理者ユーザーの権限を参照してから付与してみることにしました.すると,rds_superuser_roleという見たことない権限が与えられていました.

> SHOW GRANTS for 'admin'@'%';
+-----------------------------------------------+
| Grants for admin@%                            |
+-----------------------------------------------+
| GRANT USAGE ON *.* TO `admin`@`%`             |
| GRANT `rds_superuser_role`@`%` TO `admin`@`%` |
+-----------------------------------------------+
2 rows in set (0.00 sec)

調べてみたところ,Aurora MySQL バージョン3 では rds_superuser_roleが特別なロールとして作られておりそれが管理者ユーザーに設定されていました.

ドキュメント引用文(クリックすると表示されます)

Aurora MySQL バージョン 3 には、以下のすべての権限を持つ特別なロールが含まれています。ロールの名前は rds_superuser_role です

ALTER

APPLICATION_PASSWORD_ADMIN

ALTER ROUTINE

CONNECTION_ADMIN

CREATE

CREATE ROLE

CREATE ROUTINE

CREATE TABLESPACE

CREATE TEMPORARY TABLES

CREATE USER

CREATE VIEW

DELETE

DROP

DROP ROLE

EVENT

EXECUTE

INDEX

INSERT

LOCK TABLES

PROCESS

REFERENCES

RELOAD

REPLICATION CLIENT

REPLICATION SLAVE

ROLE_ADMIN

SET_USER_ID

SELECT

SHOW DATABASES

SHOW VIEW

TRIGGER

UPDATE

XA_RECOVER_ADMIN

docs.aws.amazon.com

てことであれば,この権限を振ってあげればいいと思い,その設定を行いましたところロールを割り当てられることができました.

> GRANT 'rds_superuser_role' TO 'blog'@'%';
Query OK, 0 rows affected (0.05 sec)

> SHOW GRANTS for 'blog'@'%';
+----------------------------------------------+
| Grants for blog@%                            |
+----------------------------------------------+
| GRANT USAGE ON *.* TO `blog`@`%`             |
| GRANT `rds_superuser_role`@`%` TO `blog`@`%` |
+----------------------------------------------+
2 rows in set (0.00 sec)

まとめ

MySQL バージョン8.0 の Aurora 環境での管理者ユーザーと同等の権限を割り振ろうとしてみた時に調べたことと試したことをまとめました.8.0 の環境を使う機会は今後増えそうなので初めて遭遇したことは生理として記事に残りしていければと思います.

Aurora Serverless に IAM 認証で接続を試した

タダです.

Aurora Serverless V2 が今年の4月にリリースされました.Aurora Serveless V2 を使う機会があり,IAM 認証での接続を試したのでこの記事にまとめていきます.

aws.amazon.com

Aurora Severless V2 で IAM 認証 を行う方法

Aurora Severless V2 で IAM 認証を行うための方法を整理していきます.まず Aurora Serverless V2 の IAM 認証を有効化します.

次に下記のような IAM ポリシーを作成します.これを接続するクライアントになる AWS サービス(EC2 等)の IAM ロールにアタッチしておきます.

{
   "Version": "2012-10-17",
   "Statement": [
      {
         "Effect": "Allow",
         "Action": [
             "rds-db:connect"
         ],
         "Resource": [
             "arn:aws:rds-db:[リージョン名]:[アカウント番号]:dbuser:[クラスター ID][DB ユーザー名]",
         ]
      }
   ]
}
            

DB ユーザーの作成と権限設定

Aurora Serverless V2 の DB でユーザーや DB への権限付与などを行えば準備完了です.

CREATE USER [DB ユーザー名] IDENTIFIED WITH AWSAuthenticationPlugin as 'RDS';
CREATE DATABASE [データベース名];
GRANT [必要な権限] ON [データベース名].* TO '[DB ユーザ名]'@'%';

参考情報

aws.amazon.com

EC2 から Aurora Serveless V2 へ接続

EC2 から Aurora Serveless V2 へ IAM 認証接続にはトークンが必要で generate-db-auth-token を使います.下記のようなコマンドで接続ができました.

mysql -h [Aurora Serveless V2 エンドポイント] -u [DB ユーザー名] -p`aws rds generate-db-auth-token --hostname [Aurora Serveless V2 エンドポイント] --port 3306 --username [DB ユーザ名] --region ap-northeast-1` --enable-cleartext-plugin 

参考情報

docs.aws.amazon.com

まとめ

Aurora Serverless V2 で IAM 認証を試したのでその模様をまとめました.IAM ポリシーの設定で誤りハマっちゃったのですが,接続できてよかったです.

AWS の特定タグが付けられているリソースを抽出する

タダです.

特定タグのついたリソースを絞って抽出したいことがあり,AWS CLI の resourcegroupstaggingapi を使ってみました.この記事でまとめます.

背景

そもそもこの対応をする必要があったかをまとめておきます.今回は,リソース管理の観点で,特定タグが付与されているのを確認するために実施しました.そのタグがちゃんと徹底するためにもリソースへの適用状況を確認しました.

確認のために使ったコマンド

AWS CLI のコマンドとしては以下のものです.get-resources のタグフィルターで絞り込んで結果の ARN を得られるという形です.

$ aws resourcegroupstaggingapi get-resources \
    --tag-filters Key=Name,Values=hoge \
     --query "ResourceTagMappingList[*].ResourceARN"

[
    "arn:aws:ec2:ap-northeast-1:1234567891011:vpc/vpc-1234567891011"
]

まとめ

小ネタですが,特定タグを付与されたリソースを抽出したく resourcegroupstaggingapi を使ってみたのでその模様をまとめました.

AWS WAF のスコープダウンステートメントを使ってブロックされたリクエストを通す

タダです.

AWS WAF のマネージドルールを運用していると,これまではブロックされなかったアクセスがブロックされる経験があります.その中にはアクセスを通したいリクエストもあったりするのですが,ルールを緩めずにアクセスを通したいと思い,スコープダウンステートメントを使う機会があったのでこの記事でやったことをまとめます.

スコープダウンステートメントとは

スコープダウンステートメントはルールが評価するリクエストのスコープを絞れます.今回はマネージドルールにブロックされたリクエストの中でも特定の IP アドレスからのリクエストは通したいと思い,使ってみました.

マネージドルールグループステートメント – スコープダウンステートメントをマネージドルールグループステートメントに追加すると、スコープダウンステートメントと一致しないすべてのリクエストは、ルールグループと一致しません。スコープダウンステートメントに一致するリクエストのみがルールグループに対して評価されます。

docs.aws.amazon.com

スコープダウンステートメントの設定

対象の AWS WAF WebACL のマネージドルールにチェックを入れて,Editします.Scope-down statement セクションまで移動し,Enable scope-down statementを有効化後 If a request doesn't match the statement(NOT) を選びます.これで特定の条件下のリクエストはルールに評価されなくなります.つまり今回の場合,ブロックされたリクエストがマネージドルールに評価されず,AWS WAF を通過するようになります.次に,特定の条件を定めていきますが，今回は特定の IP アドレスからのリクエストを許可したいので,Inspect は Originates from an IP address in に,IP Set でリクエストを許可したい IP アドレス郡を選択します.最後に,IP address to use as the originating address で Source IP address を選べば設定完了です.

この設定を行ったことで特定の IP アドレスのリクエストだけリクエストがブロックされずに通るようになりました.

まとめ

AWS WAF のスコープダウンステートメントを初めて使ったので設定をまとめました.この機能を使うまではルールを緩めることを検討していましたが,今回の経験でこの機能も考えてみる価値あると感じました.

Reusable workflows に Terraform 実行に必要な Secrets を渡す

タダです.

GitHub Actions の Reusable workflows を使って,terraform plan をすることがあったのですが,その際に GitHub Actions に設定した Secrets を渡す必要がありました.他にも Reusable workflows を使う Actions はあるため,Secrets が渡されたときはその値をセットし,それ以外はスキップするよう処理を書きました.この記事では備忘録としてその内容をまとめます.

出来上がった GitHub Actions の定義ファイル

まず呼び出し元の定義ファイルは次のように書きました.Reusable workflows の with で Secrets を渡すようにしています.

terraform_plan:
    uses: "./.github/workflows/reusable_workflow_test.yml"
    with:
      TF_VAR_hoge_api_key: "${{ secrets.hoge_api_key }}"

次に,呼び出される側の定義ファイルは次のように書きました.secrets セクションで呼び出し元から渡された値を受け取ります.その次に,stepsの中で渡された値をenv に入れて if で変数に値がセットされていれば GITHUB_ENV に書き出し,なければ何もしないようにしました.

secrets: 
      TF_VAR_hoge_api_key:
        required: false
~中略~

- if: ${{ env.TF_VAR_hoge_api_key != null }}
   env:
      TF_VAR_hoge_api_key: ${{ secrets.TF_VAR_hoge_api_key }}
   run: echo "TF_VAR_hoge_api_key=${{ env.TF_VAR_hoge_api_key }}" >> $GITHUB_ENV

こうすることで Secrets を渡されたときだけ処理が動き,それ以外はスキップされるようにすることができました.

まとめ

Reusable workflows に Secrets を渡して必要な Actions からの呼び出しだけ Secrets を環境変数にセットすることができました.検証で結構時間を喰ってしまったのですが,自分が経験したことない知見を詰めてよかったです.