By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post

Network ACL inbound rule for public subnet prevents Fargate from accessing Secrets Manager

0

I have a Fargate service in a public subnet. I've tried to limit the Public Subnet inbound traffic through Network ACLs with the following rules:

Enter image description here

As you can see all inbound traffic except for ports 80 and 443 are blocked by rule 300. All outbound traffic are allowed:

Enter image description here

I have also added a VPC Endpoint to my VPC for the Secrets Manager since reading this article and still am getting this error when trying to start Fargate tasks:

Enter image description here

I tried to use VPC flow logs to detect what's being denied but am unable to spot anything meaningful.

What I'm sure about is that when rule 300 is removed all tasks will start as expected. Could someone point out what about denying all other inbound traffic is stopping Fargate tasks from accessing the Secrets Manager?

Topics
Networking & Content DeliveryServerlessContainersSecurity, Identity, & Compliance
Tags
Amazon VPCAWS FargateAmazon Elastic Container ServiceAWS Secrets Manager
Language
English
AWS-User-Arman
asked a year ago318 views
1 Answer
2

I think you need to allow the higher ephemeral ports on the inbound rules. The Fargate task is calling the Secrets Manager endpoint over TCP 443 but there is no incoming rule to allow the response.

You could also use a VPC interface endpoint for Secrets Manager so that these requests don't leave the subnet. See: Using an AWS Secrets Manager VPC endpoint.

profile pictureAWS
EXPERT
kentrad
answered a year ago
  • Brettski-AWS EXPERT
    a year ago

    And there was this other question asked within minutes of this one: https://repost.aws/questions/QUQTOI3m3KRsGLi0x9Yh1bLg/ecs-fargate-task-running-in-private-subnet-cant-pull-container-from-private-ecr-repository

  • AWS-User-Arman
    a year ago

    The advice I normally give customers is: use security groups as much as possible because they are stateful and easy to manage. Trying to nail down ephemeral ports with NACLs is a lot of hard work for (probably) little benefit.

    Those sound like the key take aways from the other forum post. Thank you.

  • AWS-User-Arman
    a year ago

    You could also use a VPC interface endpoint for Secrets Manager so that these requests don't leave the subnet

    I did do that like this but no difference as long as NACL inbound rule 300 is there. I wonder why.

    vpc.addInterfaceEndpoint(
  'SmEndpoint', {
    service: InterfaceVpcEndpointAwsService.SECRETS_MANAGER, 
    privateDnsEnabled: true, 
    open: true
  }
);
  • kentrad EXPERT
    a year ago

    If the endpoint is created without specifying a security group, the default SG is used. The default SG of the VPC allows inbound from others in the SG only. That could be blocking. If the endpoint is in another subnet the NACLs can block the traffic.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions

Relevant content