Amazon S3 source
apiVersion: sources.triggermesh.io/v1alpha1 kind: AWSS3Source metadata: name: sample spec: arn: arn:aws:s3:::triggermeshtest eventTypes: - s3:ObjectCreated:* - s3:ObjectRemoved:* auth: credentials: accessKeyID: valueFromSecret: name: awscreds key: aws_access_key_id secretAccessKey: valueFromSecret: name: awscreds key: aws_secret_access_key sink: ref: apiVersion: eventing.triggermesh.io/v1alpha1 kind: RedisBroker name: triggermesh
When TriggerMesh is running on Amazon EKS, you can use an IAM role for authentication rather than an access key and secret. In this case, TriggerMesh will generate a Kubernetes service account for you that will leverage this IAM role. You also have the option of specifying your own service account name, and if a service account with the same name already exists and it is already managed by the TriggerMesh controller, then it will be reused. By reusing the same serivce account in this way, you can avoid having to create many STS trust relationships for each generated service account.
For more details on authenticating with AWS, please take a look at our dedicated guide on AWS credentials.
- Bucket ARN: ARN of the S3 bucket, as described in the previous sections.
- Queue ARN: (optional) ARN of the SQS queue which acts as event destination, in case you prefer to manage this queue yourself as described in the previous sections.
- Event types: List of event types to subscribe to.
Events produced have the following attributes:
- Schema of the
See the Kubernetes object reference for more details.
- S3 Bucket
- Amazon Resource Name (ARN)
- SQS Queue (optional)
If you didn't already do so, create a S3 bucket by following the instructions at Create your first S3 bucket.
Amazon Resource Name (ARN)
A fully qualified ARN is required to uniquely identify the Amazon S3 bucket.
Although not technically required by S3, the ARN provided to this event source may include an AWS region and account ID, in addition to the bucket name. When this information is provided, it is used to set an accurate identity-based access policy between the S3 bucket and the reconciled SQS queue, unless a user-managed queue is provided as described in the SQS Queue section of this document.
The format of such ARN is:
This information is purely optional and will be determined automatically if not provided.
SQS Queue (optional)
By default, the source creates and manages a SQS queue for that purpose on behalf of the user. An identity-based policy is set on that SQS queue to only accept messages originating from the configured S3 bucket.
Alternatively, in case you prefer not to delegate this responsibility to the event source, it is possible to provide your own SQS queue as an event destination. In this scenario, it is your own responsibility to configure the queue according to Amazon's documentation: Configuring a bucket for notifications.