A Previously Working AWS Service Control Policy Is Broken: Let’s Find Out Why
In a previous article I wrote about how the SCP that rates regions broke. This SCP can be found in the AWS documentation.
Today I’m testing a Lambda function that worked before and is now failing. This is the error I get from CloudFormation when I try to deploy a Lambda function:
“The resource manager returned the message: \”User: arn:aws:iam::464339214996:user/SandboxAdmin is not authorized to execute: lambda:GetFunction on resource: arn:aws:lambda:xxxxxx :xxxxxxxxxxxx:function:codecommittos3Lambda with an explicit deny in a service control policy (Service: Lambda, Status Code: 403, Request ID: 60e239da-6bef-4ab8-bd87–959278ba520a)\” (RequestToken: c80b1e8f- 1403–6219-eb7d-d5ce6a07eed9, HandlerErrorCode: AccessDenied »
This SCP previously worked when I used it to block requests that did not specifically originate from my VPC endpoint in the VPC and subnet where my EC2 instance exists.
I demonstrated in a previous article that with this service policy in place, I can only invoke Lambda functions from the authorized private network:
The problem is that now I deploy a Lambda function and it tells me that my user, SandboxAdmin, is being prevented by an explicit denial from calling the GetFunction action in an SCP.
This is not correct. This user is not blocked. What is blocked is the IP address that is trying to make this call, so regardless of whether it is true or false (I think it is false), the error message should be corrected to state with clarify the problem.
But let’s see what happens. I checked my VPC flow logs where I run a script to deploy a CloudFormation template. I don’t see anything blocked in the logs.