I am using aws lambda authorizer with api gateway.My handler is written in Java,
while returning IAM policy document I am getting json mapping exception ,
attaching the screenshot of logs from cloudwatch , I have also logged the handler response pojo you can check in the screenshot.
cloudwatch logs image
However , If I test lambda output it is giving correct json as expected
but it is breaking when I hit the same function through api gateway , Please suggest ,
any help would be appreciated.
{
"policyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Action": "execute-api:Invoke",
"Effect": "Allow",
"Resource": "arn:aws:execute-api:us-east-1:304262502320:uz4gxmilu8/Test/GET/*"
}
]
},
"context": {
"sub": "auth"
}
}
Related
I created an AWS Lambda function that I want to call from an event trigger in my Aurora PostgreSQL database, but I'm having trouble even calling the Lambda function at all from within pgAdmin.
When I attempt to invoke the Lambda, I get this message:
ERROR: invoke API failed
DETAIL: AWS Lambda client returned 'User: arn:aws:sts::xxxxxxxxxxxx:assumed-role/AuroraLambdaInvoker/dbc-role-mem-id-null is not authorized to perform: lambda:InvokeFunction on resource: arn:aws:lambda:us-west-2:xxxxxxxxxxxxx:function:aws_lambda_arn_1 because no identity-based policy allows the lambda:InvokeFunction action'.
SQL state: XX000
But I have an IAM role (that I named AuroraLambdaInvoker) that gives the lambda:InvokeFunction permission attached to my database cluster. Here's the policy attached to that role:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-west-2:xxxxxxxxxxx:function:TestLambda"
}
]
}
I'm not sure what to do since, the error message specifically mentions the AuroraLambdaInvoker role I created but says "no identity-based policy allows the lambda:InvokeFunction action," which is literally the only permission I have attached to that role. Is there something simple here that I'm missing for some reason?
Can you add below permission to your Action and try ?
lambda:InvokeFunction
lambda:InvokeFunctionConfiguration
lambda:GetFunctionConfiguration
or you can try with this also
"lambda:*"
Full Policy
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"lambda:*"
],
"Resource": [
"arn:aws:lambda:us-west-2:xxxxxxxxxxx:function:TestLambda"
],
"Effect": "Allow"
}
]
}
I have an API in AWS API gateway secured with AWS-Cognito. In order to use the endpoint the user must to be recognized by Cognito that will return a token.
The question here is related to the CREATE USER process. In order to use this endpoint the user must to exist in the Cognito, then receive the token and use it to connect to the CREATE USER endpoint. But at the moment of the creation of the user in the database (api-endpoint) the user is not created in Cognito and has no permission to get access to the API.
So, how should be the best approach to this process?
You don't need to always use the TOKEN authorizer. API Gateway allows you to configure another type of authorizer: REQUEST.
In that case it's entirely up to you how you want to tell if someone is (or is not) authorized to make a call to your API endpoint.
The event will look something like this (taken from AWS documentation):
{
"type": "REQUEST",
"methodArn": "arn:aws:execute-api:us-east-1:123456789012:abcdef123/test/GET/request",
"resource": "/request",
"path": "/request",
"httpMethod": "GET",
"headers": {
"X-AMZ-Date": "20170718T062915Z",
"Accept": "*/*",
"HeaderAuth1": "headerValue1",
"CloudFront-Viewer-Country": "US",
"CloudFront-Forwarded-Proto": "https",
"CloudFront-Is-Tablet-Viewer": "false",
"CloudFront-Is-Mobile-Viewer": "false",
"User-Agent": "..."
},
"queryStringParameters": {
"QueryString1": "queryValue1"
},
"pathParameters": {},
"stageVariables": {
"StageVar1": "stageValue1"
},
"requestContext": {
"path": "/request",
"accountId": "123456789012",
"resourceId": "05c7jb",
"stage": "test",
"requestId": "...",
"identity": {
"apiKey": "...",
"sourceIp": "...",
"clientCert": {
"clientCertPem": "CERT_CONTENT",
"subjectDN": "www.example.com",
"issuerDN": "Example issuer",
"serialNumber": "a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1",
"validity": {
"notBefore": "May 28 12:30:02 2019 GMT",
"notAfter": "Aug 5 09:36:04 2021 GMT"
}
}
},
"resourcePath": "/request",
"httpMethod": "GET",
"apiId": "abcdef123"
}
}
Then you need to tell API Gateway that it can pass this response through:
{
"principalId": "any-identifier-you-choose-like-uuid",
"policyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Action": "execute-api:Invoke",
"Effect": "Allow",
"Resource": "arn:aws:execute-api:eu-west-1:111111111111:abcdef/prod/GET/myresource"
]
}
}
There is also caching policy involved, but this should be enough for you to start.
I have an app I am trying to move to a new k8s cluster, having a permissions issue when trying to ConfirmSubscription:
"sns confirmation failed. Reason: AuthorizationError: User: arn:aws:sts::-:assumed-role/-/- is not authorized to perform:
SNS:ConfirmSubscription on resource: arn:aws:sns:-:-:topicname
status code: 403, request id: 000d2844-3a3d-5544-922a-7d9e3db07a16"
The app was able to execute a confirm subscription in the old cluster, so I assume it's an IAM issue, but the role policy it's assuming is:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"sns:ConfirmSubscription",
"sns:Subscribe"
],
"Effect": "Allow",
"Resource": [
"arn:aws:sns:::*"
]
}
]
}
I haven't been able to diagnose where the IAM issue is.
I was able to get this working by fully qualifying the sns topic to which I wanted to confirm subscription:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"sns:ConfirmSubscription",
"sns:Subscribe"
],
"Effect": "Allow",
"Resource": [
"arn:aws:sns:us-east-1:000000000:full-topic-name-no-wildcard"
]
}
]
}
I'm deploying some REST apis using API Gateway and Lambda Functions. Because of some architectural restrictions, the API must be available only by REST endpoints. On top of the API's I need to implement a GraphQL interface to allow part of our users to query this data. To deploy the GraphQL endpoints I'm using AWS AppSync. Based on that restrictions, I created the AppSync HTTP DataSource pointing to API Gateway stage url (https://api-gateway-api-id.execute-api.eu-central-1.amazonaws.com). It worked fine. Then I secured the API Gateway REST endpoint to use AWS_IAM, created a role for the datasource with permissions to invoke-api on the selected api inovocation arn and configured the HTTP Datasource using aws cli.
For example, here is my Role:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "appsync.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
And here is the policy attached to this role:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "execute-api:Invoke",
"Resource": "arn:aws:execute-api:eu-central-1:9999999999:api-gateway-api-id/*/*/*"
}
]
}
And after all of that I updated my data source from aws cli with the following config:
{
"dataSource": {
"dataSourceArn": "arn:aws:appsync:eu-central-1:99999999999:apis/appsync-pi-id/datasources/Echo",
"name": "Echo",
"type": "HTTP",
"serviceRoleArn": "arn:aws:iam::99999999999:role/roleName",
"httpConfig": {
"endpoint": "https://api-gateway-api-id.execute-api.eu-central-1.amazonaws.com",
"authorizationConfig": {
"authorizationType": "AWS_IAM",
"awsIamConfig": {
"signingRegion": "eu-central-1",
"signingServiceName": "appsync"
}
}
}
}
}
Now when I try to make a query, I get the following error:
Credential should be scoped to correct service: 'execute-api'
As I understand, the correct service to be used to formulate the signature is the execute-api. I have some experience creating AWSV4 Signatures and knows that for this case it would be this one.
Somebody knows where I'm making a mistake?
With help from Ionut Trestian I found the error. I changed the configuration to use a different signatureService, like the following:
{
"dataSource": {
"dataSourceArn": "arn:aws:appsync:eu-central-1:99999999999:apis/appsync-pi-id/datasources/Echo",
"name": "Echo",
"type": "HTTP",
"serviceRoleArn": "arn:aws:iam::99999999999:role/roleName",
"httpConfig": {
"endpoint": "https://api-gateway-api-id.execute-api.eu-central-1.amazonaws.com",
"authorizationConfig": {
"authorizationType": "AWS_IAM",
"awsIamConfig": {
"signingRegion": "eu-central-1",
"signingServiceName": "execute-api"
}
}
}
}
}
Apparently I didn't understand correctly the configuration values. In my defense, I didn't found any documentation regarding this options, only a few examples scattered through the web. :-)
In case anyone else ends up here as I did wondering what else can be placed as a signingServiceName (I was looking for s3 specifically), I found this helpful blog post https://blog.iamjkahn.com/2019/12/invoking-even-more-aws-services-directly-from-aws-appsync.html
My team has a pipeline which runs under an execution IAM role. We want to deploy code to AWS through CloudFormation or the CDK.
In the past, we would upload some artifacts to S3 buckets before creating/updating our CloudFormation stack, using the execution IAM role.
We recently switched to the CDK, and are trying to get as much automated with using CDK Deploy as possible, but are running into a lot of permission items we need to add which we didn't have prior (for instance, cloudformation:GetTemplate).
We don't want to just grant * (we want to follow least privilege) but I can't find any clear documented list.
Is there a standard list of permissions that CDK Deploy relies on? Are there any "nice to have's" beyond a standard list?
The CDK v2 now brings and assumes its own roles. No more manual permission management required. You only need to grant permission to assume the cdk roles:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": [
"arn:aws:iam::*:role/cdk-*"
]
}
]
}
These roles are created via cdk bootstrap, which then of course requires the permission to create the roles and policies. After the bootstrapping though, this no longer is required. So you could run this manually with a privileged role.
Apparently CDK proceeds if any of the cdk roles cannot be assumed. So it's still possible to manually manage a CDK policy as below, but it might now requires additional permissions.
Be aware, the CFN role has the Administrator policy attached.
Previous answer for CDK v1:
I'm using below policy to deploy CDK apps. Besides CFN full access and S3 full access to the CDK staging bucket, it grants permission to do everything through CloudFormation.
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"cloudformation:*"
],
"Resource": "*",
"Effect": "Allow"
},
{
"Condition": {
"ForAnyValue:StringEquals": {
"aws:CalledVia": [
"cloudformation.amazonaws.com"
]
}
},
"Action": "*",
"Resource": "*",
"Effect": "Allow"
},
{
"Action": "s3:*",
"Resource": "arn:aws:s3:::cdktoolkit-stagingbucket-*",
"Effect": "Allow"
},
{
"Effect": "Allow",
"Action": [
"ssm:GetParameter"
],
"Resource": "arn:aws:ssm::*:parameter/cdk-bootstrap/*"
}
]
}
You might want to add some explicit denies for things you don't want to allow.
Also, be aware that above condition does not mean the principal is limited to things possible with CloudFormation. A potential attack vector would be to create a custom CFN resource, backed by a Lambda function. When creating resources through that custom resource you then could do anything in the Lambda, because it is triggered via CloudFormation.
When you use lookups (those are the .fromXxx(...) methods), the CDK will make read/list requests to the related service at runtime - while the CDK synth is running, not the CloudFormation deploy. Which permissions you need, of course, depends on the lookups you have in your code. For example, if you would have a Vpc.fromLookup() you should allow the action ec2:DescribeVpcs. Of course you could attach the ReadOnlyAccess policy, if you have no concerns about accessing sensitive content.
Since I couldn't find any documentation anywhere I had to do some trial and error to get this to work.
Apart from the permissions you need to create the actual resources you define in your stack, you need to give the following:
cloudformation:DescribeStacks
cloudformation:CreateChangeSet
cloudformation:DescribeChangeSet
cloudformation:ExecuteChangeSet
cloudformation:DescribeStackEvents
cloudformation:DeleteChangeSet
cloudformation:GetTemplate
To the stack ARN you are creating, as well as the bootstrap stack:
arn:aws:cloudformation:${AWS::Region}:${AWS::AccountId}:stack/CDKToolkit/*
You also need s3 permissions to the bucket that the boostrap added (otherwise you get that dreaded Forbidden: null error):
s3:*Object
s3:ListBucket
s3:GetBucketLocation
to
arn:aws:s3:::cdktoolkit-stagingbucket-*
CDK has two phases the bootstrap and the synth/deploy.
In the case of bootstrap the IAM role or profile used must have the following policy permissions:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "StsAccess",
"Effect": "Allow",
"Action": [
"sts:AssumeRole",
"iam:*Role*"
],
"Resource": [
"arn:aws:iam::${AWS_ACCOUNT_ID}:role/cdk-*"
]
},
{
"Action": [
"cloudformation:*"
],
"Resource": [
"arn:aws:cloudformation:${AWS_REGION}:${AWS_ACCOUNT_ID}:stack/CDKToolkit/*"
],
"Effect": "Allow"
},
{
"Sid": "S3Access",
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": [
"*"
]
},
{
"Sid": "ECRAccess",
"Effect": "Allow",
"Action": [
"ecr:SetRepositoryPolicy",
"ecr:GetLifecyclePolicy",
"ecr:PutImageScanningConfiguration",
"ecr:DescribeRepositories",
"ecr:CreateRepository",
"ecr:DeleteRepository"
],
"Resource": [
"arn:aws:ecr:${AWS_REGION}:${AWS_ACCOUNT_ID}:repository/cdk-*"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:GetParameter*",
"ssm:PutParameter*",
"ssm:DeleteParameter*"
],
"Resource": "arn:aws:ssm:${AWS_REGION}:${AWS_ACCOUNT_ID}:parameter/cdk-bootstrap/*"
}
]
}
While in the case of deployment, the role or profile must have the following as mandatory permission:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": [
"arn:aws:iam::*:role/cdk-*"
]
}
]
}
Plus with all the permissions needed for the infrastructure you're deploying.
The thing I can recommend is to use two different roles so that you have more security, and in case you're using GitHub workflow to take advantage of the OpenIdConnect.
The bootstrap policy could be improved by restricting permissions but the documentation is lacking so I do not delve into specific aspects (example s3)
We also needed to add below permissions as well.
ssm:PutParameter
ecr:SetRepositoryPolicy
ecr:GetLifecyclePolicy
ecr:PutImageScanningConfiguration
ssm:GetParameters
ecr:DescribeRepositories