Customizing EFS Mount Targets using Cloud Formation and EFS Security Group

[robogeek]

Description

The name for Mount Targets generated for EFS volumes have a coded string making it impossible to create an override in an Cloud Formation overlay.

Further, it seems the Security Group is incorrectly set up.

Example:

  ProjecthomeNFSMountTargetOnSubnet5d96ee76:
    Properties:
      FileSystemId: fs-6d32c069
      SecurityGroups:
      - Ref: DefaultNetwork
      SubnetId: subnet-5d96ee76
    Type: AWS::EFS::MountTarget

The name includes a coded value for SubnetNNNNN. It looks to be impossible to create an overlay to target these items.

The other issue is that these Mount Targets use DefaultNetwork as the security group. That security group is configured in a funny way that prevents desired usage of the EFS mount.

Steps to reproduce the issue:

1. Create a Compose file that mounts an externally defined EFS partition
2. Launch an EC2 instance in the same VPC, and attempt to NFS-mount the EFS partition
3. Notice that the mount attempt takes forever, then errors with a timeout

Describe the results you received:

The result is that running docker compose convert on the Compose file shows me a Cloud Formation template that I cannot customize.

I have determined that one can modify the DefaultNetwork security group with ingress for more CIDR's and then the mount attempt works. But because of how the Cloud Formation template is structured, I cannot add another security group to the Mount Targets.

I could write an overlay to modify DefaultNetwork but that security group is used by many other things. It's best to target modifying the security group settings of the EFS mount targets.

Describe the results you expected:

I want to launch an EC2 instance that can mount an EFS partition being used by a Compose file. e.g. If the EFS partition has the directory tree for a Wordpress site, to be able to use SSHFS to access that EFS volume to edit files.

In other words, the expectation is that the EFS Mount Target would have a Security Group allowing NFS within the VPC.

This is somewhat related to an issue I filed earlier about mounting the same EFS partition from different Compose files -- #1085

Additional information you deem important (e.g. issue happens only occasionally):

This always happens

Output of docker version:

$ docker version
Client: Docker Engine - Community
 Cloud integration: 1.0.7
 Version:           20.10.2
 API version:       1.41
 Go version:        go1.13.15
 Git commit:        2291f61
 Built:             Mon Dec 28 16:12:42 2020
 OS/Arch:           darwin/amd64
 Context:           ecs-env
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.2
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       8891c58
  Built:            Mon Dec 28 16:15:28 2020
  OS/Arch:          linux/amd64
  Experimental:     true
 containerd:
  Version:          1.4.3
  GitCommit:        269548fa27e0089a8b8278fc4fc781d7f65a939b
 runc:
  Version:          1.0.0-rc92
  GitCommit:        ff819c7e9184c13b7c2607fe6c30ae19403a7aff
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Output of docker context show:
You can also run docker context inspect context-name to give us more details but don't forget to remove sensitive content.

$ docker context show
ecs-env
$ docker context inspect ecs-env
[
    {
        "Name": "ecs-env",
        "Metadata": {
            "Description": "credentials read from environment",
            "Type": "ecs"
        },
        "Endpoints": {
            "docker": {
                "SkipTLSVerify": false
            },
            "ecs": {
                "CredentialsFromEnv": true
            }
        },
        "TLSMaterial": {},
        "Storage": {
            "MetadataPath": "/Users/david/.docker/contexts/meta/...",
            "TLSPath": "/Users/david/.docker/contexts/tls/..."
        }
    }
]

Output of docker info:

$ docker info
Command "info" not available in current context (ecs-env), you can use the "default" context to run this command

Additional environment details (AWS ECS, Azure ACI, local, etc.):

I'm running against AWS ECS from a macOS 10.15.7 machine

[ndeloof]

SubnetNNNNN is not a random/coded name but the subnet ID (see https://github.com/docker/compose-cli/blob/main/ecs/volumes.go#L36) so fully predictible.

[robogeek]

But... how does one go about accessing SubnetNNNNNN in a Cloud Formation overlay? The capabilities available in a Compose file to access the Subnet ID's and use them to construct object names are limited

One question -- Can one write this:

ProjecthomeNFSMountTargetOnSubnet${SUBNET_ID_1):
    Properties:
         ...

It's not clear from the documentation on the Docker website whether this is possible. Hurm...

[robogeek]

FYI -- I have worked out some crazy code using Terraform to generate a Cloud Formation overlay then to inject that into the Compose file.

But -- as I thought about this -- I'm curious about why do the mount targets have the DefaultNetwork security group?

This security group looks to be pretty generic, and is not designed for the use of an EFS Mount Target. Such a security group should focus solely on the NFS protocol, and limit access from CIDR's associated with the VPC. That's not what the DefaultNetwork security group does.

This security group is much more appropriate for EFS Mount Targets. The cloud formation overlay I wrote attaches this security group to the mount targets, and then I can easily NFS mount the EFS partition from an EC2 instance.

resource "aws_security_group" "allow-nfs" {
    name = "allow-nfs-sg"
    description = "allow NFS access"
    vpc_id = module.default-vpc.default_vpc_id

    ingress {
        description = "NFS"
        protocol    = "TCP"
        from_port   = 2049
        to_port     = 2049
        cidr_blocks = [ module.default-vpc.default_vpc_cidr ]
    }

    egress {
        protocol = "-1"
        from_port = 0
        to_port = 0
        cidr_blocks = ["0.0.0.0/0"]
    }
}

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because it had not recent activity during the stale period.