【トラブル】【AWS】クロスアカウントでのS3アクセスに関するトラブル

■ はじめに

 クロスアカウントでのS3アクセスに関して
複数の原因があってハマりにハマったので、メモしておく。

目次

【0】教訓:S3バケットのアクセストラブルの勘所
【1】エラー「An error occured (403) when calling the HeadObject operation: Forbidden」が表示
【2】エラー「The ciphertext refers to a custom master key ...」が表示

【0】教訓:S3バケットのアクセストラブルの勘所

* 以下の点を落ち着いて当たってみるといいかも、、、

1)S3へアクセスしているIAM roleで、
  アクセスするS3にアクセス許可しているか
2)S3 Policyで、S3へアクセスしているIAM roleを許可しているか
 => S3 と IAM role のお互いが許可しているか確認

KMSで暗号化している場合

3)KMSのKey policyで、S3へアクセスしているロールを許可しているか
4)S3へアクセスしているロールがKMS使用を許可しているか
 => KMS と IAM role のお互いが許可しているか確認

【1】エラー「An error occured (403) when calling the HeadObject operation: Forbidden」が表示

Boto3 API で、クロスアカウント上のKMSキーで暗号化しているS3バケット内の
ファイルをダウンロードした際に以下「エラー内容」が表示されてしまう

1)エラー内容

botocore.exceptions.ClientError:
An error occured (403) when calling the HeadObject operation: Forbidden

2)原因

* 原因は、2点。

原因・その1

* アクセス先のS3バケットのPolicyでGlue Job のロールが許可されていなかった
 => 確認方法としては、対象S3バケットを選択し、タブ[Permissions]の配下の
  「Bucket Policy」を参照する

原因・その2

* 以下の2点。

[1] Glue で使用しているロールのPollicyで
  対象S3バケットを許可していなかったため
[2] Glue で使用しているロールのPollicyで
  対象S3バケットに紐づけいるKMSキーの使用許可がなかったため

3)解決案

* 以下の通り。
 => ただし、また別エラーが発生(【2】を参照)

原因・その1の解決案

* アクセス先のS3バケットのPolicyでGlue Job のロールが追加
 => 今回の場合、ReadObject/ListBucketを許可するようにPolicyを修正

原因・その2の解決案

* Glue で使用しているロールのPollicyを修正
 => 今回の場合、以下の通り。

[1] GetObjectを許可しているPolicyのResourceに対して
 対象S3バケットのARNを追加
[2] kms:Encrypt/DescribeKey/Decryptなどを許可しているPolicyのResourceに対して
 対象S3バケットのKMSのARNを追加

【2】エラー「The ciphertext refers to a custom master key ...」が表示

 Glue JobからBoto3 API を使い、
クロスアカウント上のKMSキーで暗号化しているS3バケット内の
ファイルをダウンロードした際に以下「エラー内容」が表示されてしまう

1)エラー内容

botocore.exceptions.ClientError:
An error occured (AccessDenied) when calling the GetObject operation:
The ciphertext refers to a custom master key that does not exists,
does not exist in this region, or you are not allowed to access.

2)原因

S3バケットに紐づいているKMSキーのKey Policyで
Glue Job のロールが許可されていなかった

 => 確認方法としては、対象S3バケットを選択し、タブ[Permissions]の配下の
  「Default encryption」で指定されているKMSキーのリンクから参照できる

3)解決案

KMSキーのPolicyでGlue Job のロールを許可するように修正する
 => 今回の場合、kms:Encrypt/DescribeKey/Decryptなどを許可している
  Key PolicyのResourceに対して使用しているGlue JobのロールのARNを追加

関連記事

IAM ~ クロスアカウント ~
https://dk521123.hatenablog.com/entry/2022/05/23/000000

【Snowflake】Snowflake ~ ストレージ統合 ~

■ はじめに

Snowflakeのストレージ統合(Storage Integration)について
予習をする

目次

【1】ストレージ統合(Storage Integration)
【2】利点
【3】関連するSQL文
 1)ストレージ統合作成
 2)ストレージ統合確認
 3)ストレージ統合の一覧表示

【1】ストレージ統合(Storage Integration)

https://docs.snowflake.com/ja/sql-reference/sql/create-storage-integration.html

より抜粋
~~~~~
外部クラウドストレージ用に生成されたIDおよび
アクセス管理(IAM)エンティティを許可またはブロックされたストレージの場所
(Amazon S3、Google Cloud Storage、またはMicrosoft Azure)の
オプションセットとともに格納するSnowflakeオブジェクト
~~~~~
 => 分かりづれ、、、
 => クラウドストレージ(S3/Google Cloud Storage/Microsoft Azure)と
  Snowflakeとを接続するためのオブジェクト
 => クラウドストレージにアクセスする際には、
  この「ストレージ統合」を経由して、接続する

【2】利点

1)ステージの作成時/データのロードまたはアンロード時に
  認証情報の提供を回避できる

【3】関連するSQL

1)ストレージ統合作成

https://docs.snowflake.com/ja/sql-reference/sql/create-storage-integration.html

-- AWS/S3の場合
CREATE STORAGE INTEGRATION 【ストレージ統合名}
    TYPE = EXTERNAL_STAGE
    STORAGE_PROVIDER = S3
    ENABLED = TRUE
    STORAGE_AWS_ROLE_ARN = 'arn:aws:iam::【S3のAWSアカウントID】:role/【ロール名】'
    STORAGE_ALLOWED_LOCATIONS = ('s3://【S3のバケット名】/【パス】/');

2)ストレージ統合確認

https://docs.snowflake.com/ja/sql-reference/sql/desc-integration.html

DESC INTEGRATION 【ストレージ統合名】;

3)ストレージ統合の一覧表示

https://docs.snowflake.com/ja/sql-reference/sql/show-integrations.html

SHOW INTEGRATIONS;

SHOW INTEGRATIONS LIKE '【絞り込みたいパターン】' ;

参考文献

https://dev.classmethod.jp/articles/snowflake-s3-integration-by-cfn/
https://blog.serverworks.co.jp/snowflake-import-from-s3
https://dmscube.com/view/post/0/38558

関連記事

Snowflake ~ 基礎知識編 ~
https://dk521123.hatenablog.com/entry/2021/11/02/130111
Snowflake ~ 入門編 / Hello world
https://dk521123.hatenablog.com/entry/2021/11/22/212520
Snowflake ~ テストデータ作成 / generator ~
https://dk521123.hatenablog.com/entry/2022/06/20/095659

【Pulumi】pulumiで対象リソースのみデプロイ / 削除(--target)

■ はじめ

小ネタ。
よく使うし、今後も使いそうなので、メモ。

目次

【1】対象リソースのみデプロイ
【2】対象リソースのみ削除

【1】対象リソースのみデプロイ

* pulumi up --target で URN(ARN)を指定してデプロイ
* From Pulumi CLI 1.3.0

https://tech.guitarrapc.com/entry/2019/12/21/000000
https://qiita.com/ttkn9a/items/6fb71af2d265939184c3

* URN(ARN) を調べるのは、「pulumi stack --show-urns」
 => 以下のAPI仕様書を参照のこと

https://www.pulumi.com/docs/reference/cli/pulumi_stack/

コマンド例

Step1: Stack を選択

# どんなStackが選択できるかを調べるには「pulumi stack ls」を実行)
pulumi stack select nonprod

Step2: URN(ARN) を調べる

pulumi stack --show-urns

# 絞り込みたい場合は、パイプ(|) & grep を利用する
# pulumi stack --show-urns | grep "<キーワード>"

Current stack is dev:
    Managed by LAPTOP-RXXXQSF6
    Last updated: 12 minutes ago (2022-03-22 23:04:57.8516092 +0900 JST)
    Pulumi version: v3.26.1
Current stack resources (5):
    TYPE                                 NAME
    pulumi:pulumi:Stack                  quickstart-dev
    │  URN: urn:pulumi:dev::quickstart::pulumi:pulumi:Stack::quickstart-dev
    ├─ demo:DemoComponent                hello-world
    │  │  URN: urn:pulumi:dev::quickstart::demo:DemoComponent::hello-world
    │  ├─ kubernetes:apps/v1:Deployment  nginx
    │  │     URN: urn:pulumi:dev::quickstart::demo:DemoComponent$kubernetes:apps/v1:Deployment::nginx
    │  └─ kubernetes:core/v1:Service     nginx
    │        URN: urn:pulumi:dev::quickstart::demo:DemoComponent$kubernetes:core/v1:Service::nginx
    └─ pulumi:providers:kubernetes       default_3_17_0
          URN: urn:pulumi:dev::quickstart::pulumi:providers:kubernetes::default_3_17_0

Current stack outputs (1):
    OUTPUT  VALUE
    ip      10.106.169.203

Step3: --target を指定して実行

# 構文:pulumi up --target <URN>
pulumi up --target urn:pulumi:dev::quickstart::demo:DemoComponent::hello-world

# 不安な場合は、pulumi preview --target <URN> で実行

【2】対象リソースのみ削除

* pulumi up の 「補足:対象リソースのみデプロイ(--target)」
 の逆バージョンで pulumi destroy --targetを実行する

コマンド例

# xxxxxx は対象のURN
pulumi destroy --target 'xxxxxx'

関連記事

Pulumi ~ 基礎知識編 ~
https://dk521123.hatenablog.com/entry/2021/10/23/025230
Pulumi ~ 基本編 / CLI