Prerequisites for AWS Lambda Sidecar Connector
Trust Policy Configuration in AWS Lambda
Customers who plan to use AWS Lambda Sidecar Connector must ensure prerequisites are met accurately. The following guidelines are provided for configuring the AWS Account with role and trust policy that allows the TIBCO Mashery Sidecar Connector to invoke Lambda function hosted/deployed by a customer.
Procedure
To configure trust policy for providing access to Mashery, create a cross account assume role by following these steps:
- In the AWS Management console, click .
- Click Another AWS account. Input the Account ID as 809167139867 and in the Options field input the External ID and click Next:Permissions.
- Provide permission to invoke AWS Lambda to this role. You can select an existing policy such as AWSLambdaFullAccess or you can create a new policy by selecting the Create Policy button.
- Define the custom policy in the
tab. Provide access only to invoke Lambda function and click
Review policy.
Note: Sample ARN is for reference only. Customer Lambda resource ARN may be different and specific to the customer's Lambda function.
- In the
Review policy section, input the
Name and
Description and click
Create policy.
- Select the new policy from the list of policies and click Next:Tags.
- In the Add tags section, input the Key and Value for the tags that you wish to add. This is optional. Click Next:Review.
- In the Review section, input the Role name, Role description and then click Create role.
- The role name "tibco_sidecar_conector" will be created successfully.
Tip: Copy roleARN of this newly created role and provide it in pre-input configurations.
Sample Trust Policy for Assume Role
Following is a sample trust policy with TIBCO AWS account ID
809167139867 and External ID
111122223333pqrst.
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::809167139867:role/java_proxy" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "<external ID that customer sets for AWS Lambda function >" } } }] }
Assume Role Support In AWS Lambda SideCar Integration
- In order to comply with AWS shared responsibility model secure best practices, Sidecar Integration supports Assume Role functionality.
- With Assume Role support available in the Connector, customer is not required to share AWS IAM basic credentials. Sidecar Connector assumes role for roleARN provided in pre-input configuration.
- Customer needs to set trust policy for role in AWS account and needs to define that roleARN in pre-input configuration.
- Customer is required to set External ID in trust policy. External ID in trust policy is a part of AWS secure practices to mitigate risk of confused deputy attack. (AWS documentation on confused deputy attack.)
Securing Customer ExternalID As Secret
- Mashery stores External Id value in the AWS Systems Manager Parameter Store using key-value pair. TIBCO CloudSecurity team recommendation is to treat externalID as a secret for AWS IAM accounts.
- This is one of the best and secure cloud practices to protect customers resources and mitigate the risk of unauthorized access to Lambda functions.
- TIBCO CloudSecurity guidance has been that externalID value should be treated as a secret and should not be entered into pre-input configuration in plain-text.
- Customer needs to share External ID key-value pair for provisioning in TIBCO AWS Parameter Store infrastructure.
- AWS recommends that the Parameter Store key should be defined in hierarchy. Customer should define external id in proper hierarchy.
- The following guidelines should be complied between TIBCO Mashery and customer who plans to use AWS Lambda Sidecar Connector.
- Customer should follow hierarchy as <Customer Name>/<Environment>/<Key Name>. Why this format is designed?
- This format is designed to allow a unique namespace for each TIBCO customer that use AWS Lambda Sidecar Connector.
- It also provides customer a flexibility to manage externalID for their different environments which may be different.
- A recommended secure practice to keep secrets different for prod and non-prod environments.