Unable to set two notification handlers for same Bucket

[kdybicz]

• Expected behaviour:

claudia add-s3-event-source --profile private --region eu-west-1 --bucket test.secretescapes.com --events s3:ObjectCreated:* --prefix sales-upload/ --suffix .jpg allows me to setup S3 Bucket Notification handler.

• What actually happens:

Unfortunately, this command allows to setup only one command at all for one bucket. So when I run: claudia add-s3-event-source --profile private --region eu-west-1 --bucket test.secretescapes.com --events s3:ObjectCreated:* --prefix sales-upload/ --suffix .png to add new handler for different suffix I get:

{ ResourceConflictException: The statement id (test_secretescapes_com-access) provided already exists. Please provide a new statement id, or remove the existing statement.
    at Object.extractError (/Users/kamil/work/aws-lambda-image/node_modules/aws-sdk/lib/protocol/json.js:43:27)
    at Request.extractError (/Users/kamil/work/aws-lambda-image/node_modules/aws-sdk/lib/protocol/rest_json.js:37:8)
    at Request.callListeners (/Users/kamil/work/aws-lambda-image/node_modules/aws-sdk/lib/sequential_executor.js:105:20)
    at Request.emit (/Users/kamil/work/aws-lambda-image/node_modules/aws-sdk/lib/sequential_executor.js:77:10)
    at Request.emit (/Users/kamil/work/aws-lambda-image/node_modules/aws-sdk/lib/request.js:671:14)
    at Request.transition (/Users/kamil/work/aws-lambda-image/node_modules/aws-sdk/lib/request.js:22:10)
    at AcceptorStateMachine.runTo (/Users/kamil/work/aws-lambda-image/node_modules/aws-sdk/lib/state_machine.js:14:12)
    at /Users/kamil/work/aws-lambda-image/node_modules/aws-sdk/lib/state_machine.js:26:10
    at Request.<anonymous> (/Users/kamil/work/aws-lambda-image/node_modules/aws-sdk/lib/request.js:38:9)
    at Request.<anonymous> (/Users/kamil/work/aws-lambda-image/node_modules/aws-sdk/lib/request.js:673:12)
  message: 'The statement id (test_secretescapes_com-access) provided already exists. Please provide a new statement id, or remove the existing statement.',
  code: 'ResourceConflictException',
  time: 2017-02-12T14:18:48.898Z,
  requestId: '2be6e299-f12e-11e6-86a0-7d781ad7b133',
  statusCode: 409,
  retryable: false,
  retryDelay: 73.63990209771674 }

• Steps to reproduce the problem:

Just try to add second handler for same Bucket but different prefix or suffix.

[gojko]

This could be supported by adding a current timestamp or some kind of rule source hash to the statement ID here:

claudia/src/commands/add-s3-event-source.js

Line 37 in c3b837d

PolicyName: iamNameSanitize(`s3-${options.bucket}-access`),

would you like to give it a try and submit a PR?

[kdybicz]

I would rather think of checking if policy for that bucket already exists and skipping that step if it does. This could be accomplished by checking in IAM or storing policies together with role in claudia.json. What do you think about such approach?

[gojko]

It would be good to have a check if the equivalent policy exists in IAM, but that wouldn't work by name, it should work by checking the contents.

[kdybicz]

As Claudia is setting Inline Policy for that role and it's using Bucket name based convention, I do not see a reason why we could not trust this approach. I believe I'm missing something here, so I would appreciate some help in understanding this aspect.

Looking over every policy content seems to be out of question, because seems to be overcomplicated for what we are trying to achieve here.

As a different approach we could be simulating/testing if our role already has all needed permissions, without the need of going into the details. We should be able to use AIM itself to do such check, which would be a equivalent of aws iam simulate-principal-policy --policy-source-arn arn:aws:iam::12345678901234:role/aws-lambda-image-executor --action-names "s3:*" --resource-arns "arn:aws:s3:::test.secretescapes.com/*"

I also understand that user is able to provide his own policies in create step, but this still should not stay in conflict with the name based approach, right?

[gojko]

it's possible for someone to attach additional policies outside claudia, so I wouldn't trust too much the fact that the policy with that name exists. I didn't know about simulate-principal-policy, that actually sounds quite nice. If I understand correctly what will happen there, if the simulation succeeds we know not to add the policy? This would allow eg externally allowed roles and so on to be used without duplicating policy rights.

[kdybicz]

Thanks for this fix! 👍 I've had no time to work on it :/

[gojko]

this is now on NPM as 2.8.0