Serverless-application-model: AWS::Serverless::Function does not work with X-Ray and Inline policies in non aws partitions

[imgaray]

Description:
I am not able to deploy my lambda function that use X-Ray in other partitions than aws. The reason is that AWS SAM attempts to put the deprecated AWSXrayWriteOnlyAccess policy when the lambda definition has the tracing attribute in its definition and the function is passing the roles explicitly instead of a role. But said policy was deprecated by X-Ray team and it's not being deployed in any new partition. As a consequence, deployment of lambdas with this configuration in other partitions than aws fail due to the policy not existing. After reaching out to X-Ray team, they recommended AWS SAM to migrate to the new policy AWSXRayDaemonWriteAccess

Steps to reproduce the issue:

1. Create a cloudformation template with the following resource:

  "TestLambdaFunction":
    "Properties":
      "Events":
        "Source":
          "Properties":
            "BatchSize": !!int "10"
            "StartingPosition": "LATEST"
            "Stream":
              "Fn::GetAtt":
              - "TestDDBTableLambdaStream"
              - "StreamArn"
          "Type": "DynamoDB"
      "FunctionName": "TestLambdaDDBStream"
      "Handler": "test"
      "InlineCode": "def test():\n  return True"
      "MemorySize": !!int "512"
      "Policies":
      - "Statement":
        - "Action":
          - "dynamodb:*"
          "Effect": "Allow"
          "Resource": "*"
        "Version": "2012-10-17"
      "Runtime": "python3.6"
      "Timeout": !!int "15"
      "Tracing": "Active"
    "Type": "AWS::Serverless::Function"

1. Deploy the function to aws-cn (ZHY or BJS).

Observed result:
CloudFormation stack fails due to missing policy AWSXrayWriteOnlyAccess

Expected result:
CloudFormation should succeed, and use the new managed policy AWSXRayDaemonWriteAccess

[keetonian]

The fix for this was rolled back in the latest release (see https://github.com/awslabs/serverless-application-model/issues/1421#issuecomment-586509850). We are working with XRay for a path forward.

[copumpkin]

This is causing me some pain

[copumpkin]

Does https://github.com/awslabs/serverless-application-model/pull/1452/files#diff-87d43f83d256604d59eff480b322bddaL433 mean that the bad managed policy will get added regardless of the value of Tracing, if it's set at all? I made it conditional to be Active or PassThrough based on partition (even though Xray is available in all partitions) but am still seeing this error. Is there an easy workaround? I could set it to AWS::NoValue but that seems to make cfn-lint very unhappy 😦

[copumpkin]

Even setting it to AWS::NoValue doesn't seem to stop it from trying to attach the bogus policy. I'm pretty stumped ☹️

[copumpkin]

I ended up having to semi-manually convert my Serveless::Function back to its expanded template form.

[imgaray]

If it is of any help, This bug only shows up if you rely on SAM creating the role for you with the policies you passed. However if you instead pass a role as a reference, SAM function transform should work, or at least that’s what I’ve observed.

[bnusunny]

This bug breaks all Java sample applications in AWS Lambda Developer Guides. None of them work in aws-cn partition. This is really puts off Java developers trying to learn AWS Lambda in China.

Is it possible to have this issue worked on faster?

[Pauldic]

Any solution on this yet? Am able to deploy but put_item() within the function says

ClientError: An error occurred (AccessDeniedException) when calling the PutItem operation: User: arn:aws:sts::74xxxxxxx:assumed-role/websocketengine-local-ConnectFunctionRole-1PCCYG1DTLQYW/websocketengine-local-ConnectFunction is not authorized to perform: dynamodb:PutItem on resource: arn:aws:dynamodb:us-east-2:74xxxxxxx:table/sbws_connection_dev

ConnectFunction:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: !Sub ${AWS::StackName}-ConnectFunction
      Description: !Sub
        - Stack ${StackTagName} Environment ${EnvironmentTagName} Function ${ResourceName}
        - ResourceName: ConnectFunction
      CodeUri: src
      Handler: handler.connect
      Runtime: python3.7
      MemorySize: 3008
      Timeout: 30
      Tracing: Active
      Policies:
        - AWSXRayDaemonWriteAccess
        - DynamoDBCrudPolicy:
            TableName: !Ref WebSocketConnectionTable
      Environment:
        Variables:
          TABLE_NAME: !Ref WebSocketConnectionTable
          TABLE_ARN: !GetAtt WebSocketConnectionTable.Arn

Am sorry, I am not sure how to format this for readability

[awsjeffg]

We are aware of this issue with deployments in the AWS China Beijing and Ningxia regions and apologize for any inconvenience this has caused. We are looking for a long-term solution to the problem that won’t cause unintended stack changes, and will post updates as more information becomes available.

In the meantime, you can work around the issue by manually creating an IAM role for the function that uses the new managed policy template. When you explicitly attach a role to an AWS::Serverless::Function resource SAM will not attach any of its default managed policies and deployments will go forward normally:

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31

Resources:
  ExecutionRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: 2012-10-17
        Statement:
          - Effect: Allow
            Principal:
              Service:
              - lambda.amazonaws.com
            Action:
              - 'sts:AssumeRole'
      Path: /
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
        - arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess
        # any additional policy ARNs required for the function to perform its work

  TracingFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: python3.6
      Tracing: Active
      Role: !GetAtt ExecutionRole.Arn

Again, we apologize for any inconvenience this has caused.

[awsjeffg]

We've resolved this issue by making the deprecated policy available in non-aws partitions - you should be able to deploy templates using the old policy into eg aws-cn now without a deployment failure.