This plugin will sign a request with AWS SIGV4 and temporary credentials from sts.amazonaws.com requested using an OAuth token.
It enables the secure use of AWS Lambdas as upstreams in Kong using Lambda URLs.
At the same time it drives down cost and complexity by excluding the AWS API Gateway and allowing to use AWS Lambdas directly.
The required AWS setup to make the plugin work with your Lambda HTTPS endpoint is described below.
aws_assume_role_arn - ARN of the IAM role that the plugin will try to assume
type = "string"
required = true
aws_assume_role_name - Name of the role above.
type = "string"
required = true
aws_region - AWS region where your Lambda is deployed to
type = "string"
required = true
aws_service - AWS Service you are trying to access (lambda)
type = "string"
required = true- You have a Lambda function deployed with
Function URLenabled and Auth type :AWS_IAM
Show image
- Your OpenID Connect provider is added to AWS IAM
- You have a role with
arn:aws:iam::aws:policy/AWSLambda_FullAccesspermision and the trust relationship below:
Show JSON
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "${arn_of_the_open_id_connect_provider_step_1}"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"${the_open_id_connect_provider_step_1}:aud": "${audience_of_the_lambda_given_by_your_open_id_provider}"
}
}
}
]
}So if your provider is https://sts.windows.net/organization.onmicrosoft.com/ and your app identity is app_identity_1, the trust relationship above will look like:
Show JSON
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::300000000000:oidc-provider/sts.windows.net/organization.onmicrosoft.com/"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"sts.windows.net/organization.onmicrosoft.com/:aud": "app_identity_1"
}
}
}
]
}About the code and differences from Kong Lambda Plugin
Some of the code was reused from Kong Lambda Plugin specifically the SIGV4 creation code and some parts for getting the temporary credentials from AWS STS. There are some considerable differences that will be outlined below:
- Unlike Kong-Lambda This plugin does not perform the Lambda invocation. But only signs the request coming from the consumer which Kong then forwards to the upstream that it is configured in the service that the plugin is bound to.
- The plugin works only with temporary credentials that are fetched from
sts.amazonaws.comusing AssumeRoleWithWebIdentity, this requires some configuration in AWS which can be found above. - This plugin has a low priority and is compatible with the rest of Kong plugins because as mentioned above, it only performs SIGV4 on the request and then appends the necessary headers to be authorized in AWS.