Datapipelineで押さえておく権限

Datapipelineとは

AWSのサービスの一つです。
ETLのようなバッチ処理のようなジョブスケジューラのような存在です。

正直癖があります。
エラーになった時に復旧よくわからないし、ActivityとJDBC接続とで挙動が違ったりとか。
Deactivateしておいて、Activateすると、
停止していた期間のjobが一気に流れるとか。
まさにじゃじゃ馬。でも使いこなせたら結構いいんじゃないかと。

「使わないほうが。。。」との声もありますけどね。

Datapipelineで意識する権限

Datapipeline関連で意識すべき権限は大きく分けて4つあります。

1.Datapipelineを使用する権限

主にIAMユーザーに付与するものかと思います。
IAMのポリシーで制御することになりますが、
チームごととか利用者ごとにIAMユーザーを持っているとかであれば、
IAMユーザー名のtagがついたJOBのみ編集可能、みたいな感じでしょうか。
あとは後続に記述する「2.Datapipeline自身の権限」を付与する権限も必要かと思います。

特定のタグがついたJOBのみを編集する権限はこんな感じです。
多分設定はコンソールじゃないと難しいかなーと思います。

    {
        "Effect": "Allow",
        "Action": [
            "datapipeline:ListPipelines",
            "datapipeline:DescribePipelines",
            "datapipeline:GetAccountLimits"
        ],
        "Resource": "*"
    },
    {
        "Effect": "Allow",
        "Action": [
            "datapipeline:*"
        ],
        "Resource": "*",
        "Condition": {
            "StringEquals": {
                "datapipeline:Tag/<TagName>": "<TagValue>"
            }
        }
    }

ちなみに特定のロールを付与する箇所はこんな感じ。
PassRoleはよく使う気がします。

    {
        "Effect": "Allow",
        "Action": [
            "iam:PassRole"
        ],
        "Resource": [
            "arn:aws:iam:::role/<RoleName>"
        ]
    }

また操作ユーザーに「3.Datapipelineで起動されたEC2が使用する権限」を付与する権限はいらないみたいです。設定はできるはできます。でもDatapipelineが処理を開始したときに、EC2が起動できずエラーに。
「3.Datapipelineで起動されたEC2が使用する権限」の実際の設定は「2.Datapipeline自身の権限」の方につけておく必要があります。

2.Datapipeline自身の権限

Datapipelineが処理を実行する時の権限です。
主に、EC2関連の起動や停止、削除などでしょうか。
RDSやRedshift関連のActivityを使用する場合はその辺も必要かもしれません。
エラー時のSNS通知とかもここの権限となります。
snsの権限付与してなくて、エラー検知できないとか残念ですし。
大切なのは起動するインスタンスの制限。特定のサブネット、特定のセキュリティグループで起動する必要がということです。じゃないと別のセキュリティグループで起動したインスタンスからアクセスされることで、
秘匿したい情報へのアクセスが可能となる可能性があります。

特定のサブネット、特定のセキュリティグループやサブネットで起動、停止、開始、削除させる権限はこんな感じ。

    {
        "Effect": "Allow",
        "NotAction": [
            "ec2:RunInstances",
            "ec2:StartInstances",
            "ec2:StopInstances",
            "ec2:TerminateInstances"
        ],
        "Resource": "*"
    },
    {
        "Effect": "Allow",
        "Action": [
            "ec2:RunInstances",
            "ec2:StartInstances",
            "ec2:StopInstances",
            "ec2:TerminateInstances"
        ],
        "Resource": [
            "arn:aws:ec2:::instance/*",
            "arn:aws:ec2:::volume/*",
            "arn:aws:ec2:::image/*",
            "arn:aws:ec2:::network-interface/*",
            "arn:aws:ec2:::key-pair/*",
            "arn:aws:ec2:::security-group/<SecurityGroup-id>",
            "arn:aws:ec2:::subnet/<subnet-id>"
        ]
    }

3.Datapipelineで起動されたEC2が使用する権限

ResourceRoleと呼ばれます。そのまんまですが、とても大事です。
起動したEC2がFullaccess権限もってたとか、こわたん。
起動されたインスタンスにはTaskRunnerと呼ばれるエージェントがいて、
Datapipelineから処理をPollingして実行していく仕様。以下はARNが*である必要があるみたいです。

GetAccountLimits
PollForTask
ReportTaskProgress
SetTaskStatus
ReportTaskRunnerHeartbeat

4.S３のバケットの権限

ログがS3に出力されるので必要です。
実はログには危険要素満載の情報が入っていますので、書き込み権限だけ与えて、
中身は見せないとかの対応も必要。
たとえばRedshiftに接続してS3からコピーするコマンド発行する場合にアクセスキーが必要ですが、
ログに丸々出力されてます。

ログ格納先の許可はこれです。
S3の制限は必要ですが、Datapipelineがインスタンスを起動した時に
ドライバやら、いろいろaws所有のS3からもってくる処理が走ります。そこも付与しておきましょう。リージョンにもよりますが、東京は「datapipeline-ap-northeast-1」です。

    {
        "Effect": "Allow",
        "Action": [
            "s3:Put*",
            "s3:Get*"
        ],
        "Resource": [
            "arn:aws:s3:::<Bucket-Name>",
            "arn:aws:s3:::datapipeline-ap-northeast-1/*"
        ]
    },
    {
        "Effect": "Allow",
        "Action": [
            "s3:Get*"
        ],
        "Resource": [
            "arn:aws:s3:::datapipeline-ap-northeast-1/*"
        ]
    },

DatapipelineのTIPS

自分が使用して学んだことです。

1.RedshiftCopyActivityとJDBC接続してコピーコマンド発行では、挙動が違う。

2.Deactivateしておいて、Activateすると、停止していた期間のjobが一気に流れる（らしい）

聞いた話なので体験ではありませんが、そうらしいです。
MQみたいにキューに溜まっていくんですね。

3.コマンドに環境変数を追加するときの特殊な書き方。

4.「Datapipeline自身の権限」で叩かれるAPIのレイヤーの違い

5.ログ格納先へアクセス権限がないとログが消失する。

思い出ししだい追加していきます。
あと、jsonを綺麗に表示させられなかったので、誰か教えてください。。。