説明
Ansibleのaws_access_keyは、AWSリクエストの認証に使うアクセスキーIDを指定するフィールドであり、シークレットアクセスキーを入れる場所ではありません。実際のシークレットキーを誤って入れると、認証に失敗するだけでなく、プレイブックやデプロイ記録にシークレットが残ります。疑わしい値が公開された例か、実際のシークレットかを確認してください。
Ansibleのデプロイ認証とLambda実行ロールは別のものです。タスクのroleは、実行中の関数がAWSリソースにアクセスするためのロールを指定します。Ansibleのデプロイ要求を認証するものではありません。
想定される影響
- 実際のシークレットキーと、ほかに必要な認証情報が漏えいすると、その権限の範囲で意図しないAWSリクエストに使われる可能性があります。
- 誤った認証フィールドはデプロイ失敗につながります。共有キーが漏えいした場合は、それを使うほかの処理も調査・修正する必要があります。
対処方法
- 実際の認証情報をプレイブックに埋め込まず、モジュールの実行環境が対応する一時的な認証情報や外部の認証設定を使用してください。
- 関数には必要な権限を持つ実行ロールを割り当て、デプロイ主体と関数実行ロールの権限をそれぞれ最小限にしてください。
- 有効なキーが漏えいしたら、速やかに無効化または失効させて交換してください。リポジトリの履歴、デプロイ記録、アクセスログを調査し、依存する処理を更新したうえで正常なデプロイと関数動作を確認してください。
例
キー文字列はAWSの公開文書の例で、実際の認証情報ではありません。lambda_functionsにはnameとzip_fileを持つ項目の一覧を渡し、lambda_runtimeにはコードに対応するサポート対象のランタイムを指定してください。実行ロールARNとデプロイファイルは別途準備する必要があります。
変更前
yaml
- name: looped creation
amazon.aws.lambda:
aws_access_key: "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
name: "{{ item.name }}"
state: present
zip_file: "{{ item.zip_file }}"
runtime: "{{ lambda_runtime }}"
role: "{{ lambda_execution_role_arn }}"
handler: "hello_python.my_handler"
loop: "{{ lambda_functions }}"
シークレットアクセスキーの例がIDフィールドに誤って指定されています。実際のキーをこのように渡さないでください。
変更後
yaml
- name: looped creation
amazon.aws.lambda:
name: "{{ item.name }}"
state: present
zip_file: "{{ item.zip_file }}"
runtime: "{{ lambda_runtime }}"
role: "{{ lambda_execution_role_arn }}"
handler: hello_python.my_handler
loop: "{{ lambda_functions }}"
認証情報を直接記述せず、モジュールの実行環境から提供します。roleは関数の実行権限を指定するため、デプロイ認証も別途準備してください。フィールドを削除するだけで漏えい済みのキーが失効するわけではありません。