Feature request: SAM Connector Suggestions

[allanchua101]

Describe your idea/feature/enhancement

Seeing multi-destination connector update was really awesome! However, there are a few more opportunities to improve this feature IMHO.

1. Support for services is limited
2. We could still reduce the number of lines required to define connectors in batch.

Proposal

1. Add support for the following services:
   • Secrets manager (Highly used in production apps)
   • SSM parameter (Highly used in production apps)
   • SES
   • Rekognition
   • KMS
   • CloudWatch
   • CodeCommit
   • CodePipeline
   • CodeBuild
   • CodeDeploy
   • Firehose
2. We could reduce number of lines if we can get hold of the following syntax:

  GetStripePrices:
    Type: AWS::Serverless::Function
    WriteConnectors:
      - Id: SampleTableA
      - Id: SampleTableB
      - Arn: arn:aws:secretsmanager:ap-southeast-1::secret:sample-credential-Lw92LOwe
    ReadConnectors:
      - Id: SampleTableC
      - Id: SampleTableB
      - Arn: arn:aws:secretsmanager:ap-southeast-1::secret:sample-credential-Lw92LOwe

Cheers guys!

[jfuss]

@allanchua101 Thanks for the feature request. Since this relates to the spec over the CLI, I will transfer this to the correct repo.

[ccaum]

Thanks, @allanchua101.

Regarding simplifying connector syntax, I hear you that connectors can be verbose to write, but we think it's best to be explicit about the list of permissions assigned to each connector via a Permissions property. This makes it easier to mix and match permissions as well as makes it simpler for us to add new permissions in the future without disrupting existing naming conventions.

Thank you for the list of services you'd like to see supported by connectors. I'd like to learn more about how you'd like to use them with SSM and Secrets Manager specifically. Would it look something like the following?

Resources:
  AppSecret:
    Type: AWS::SecretsManager::Secret
    Properties:
      ... {omitted for brevity} ...
  Function1:
    Type: AWS::Serverless::Function
    Connectors:
      FunctionReadSecret:
        Permissions:
          - Read
        Destination:
          - AppSecret
    Properties:
      ... {omitted for brevity} ...
  Function2:
    Type: AWS::Serverless::Function
    Connectors:
      FunctionReadSecret:
        Permissions:
          - Read
        Destination:
          - AppSecret
    Properties:
      ... {omitted for brevity} ...

In the above example, you would expect the function to automatically be able to read the AppSecret secret? Would you ever want write permissions? If so, why?

[allanchua101]

Hi @ccaum,

In my current team, we have to implement Xero OAuth token rotation every 9 minutes (Though it expires at around 30 minutes) to prevent it from expiring and keeping the valet keys secured! We basically have an OAuth token rotator function that is in charge of this process (XeroAuthRenewer). Defining the IAM permission for that one was quite painful compared to connecting to a DynamoDB or an SQS Queue, though its just nice to have, I believe that it can significantly improve developer experience when rotating secrets in general.

We don't define secrets inside SAM files though! We just want to simplify the IAM permission definition involve with resources that manage and retrieve it.

Would you expect the function to automatically read the AppSecret secret?

• Yes sir! This would make rotated secret consumption much more convenient to build.

Would you ever want write permissions? If so why?

• Yes, write would be desirable too because we have several key rotation function similar to how we handle Xero API.

Sharing this documentation for Xero API rotation key process:

• https://developer.xero.com/documentation/guides/oauth2/auth-flow/