什么是设置ECS任务的最合适,最安全的方法 - 弹性缓存群集连接?

发布于 2025-02-10 17:57:25 字数 2078 浏览 3 评论 0原文

我有一个弹性缓存群和一个ECS服务,该服务共享一个子网和一个安全组,并具有以下描述:

{
    "SecurityGroups": [
        {
            "Description": "Allow Redis inbound traffic",
            "GroupName": "allow_redis_ingress",
            "IpPermissions": [
                {
                    "FromPort": 6379,
                    "IpProtocol": "tcp",
                    "IpRanges": [
                        {
                            "CidrIp": "0.0.0.0/0",
                            "Description": "Redis"
                        }
                    ],
                    "Ipv6Ranges": [],
                    "PrefixListIds": [],
                    "ToPort": 6379,
                    "UserIdGroupPairs": []
                }
            ],
            "OwnerId": "aws_account_id",
            "GroupId": "sg-xxxxxxxxxxxx33290",
            "IpPermissionsEgress": [
                {
                    "IpProtocol": "-1",
                    "IpRanges": [
                        {
                            "CidrIp": "0.0.0.0/0"
                        }
                    ],
                    "Ipv6Ranges": [
                        {
                            "CidrIpv6": "::/0"
                        }
                    ],
                    "PrefixListIds": [],
                    "UserIdGroupPairs": []
                }
            ],
            "Tags": [
                {
                    "Key": "Environment",
                    "Value": "production"
                },
                {
                    "Key": "Private",
                    "Value": "true"
                }
            ],
            "VpcId": "vpc-xxxxxxxxxxxx380b4"
        }
    ]
}

我想知道这是否是设置安全权限的最合适方法,因为它们在同一安全组中。 是吗?

我得到了两个具有相同子网和安全组的CodeBuild项目,这两个项目无需任何问题即可访问集群的缓存节点。

我什至应该为群集子网创建一个专用的子网和安全组,而是允许从任务和代码构造项目安全组从另一个子网?

进入群集,我正在使用缓存, node cache.amazonaws.com url,这是正确的,还是有更安全的方法来路由任何localhost:6379 甚至cache:6379 < /code>主机URL自动到弹性高速缓存簇节点?

I've got a Elastic Cache cluster and a ECS service which share a subnet and a security group with the following description:

{
    "SecurityGroups": [
        {
            "Description": "Allow Redis inbound traffic",
            "GroupName": "allow_redis_ingress",
            "IpPermissions": [
                {
                    "FromPort": 6379,
                    "IpProtocol": "tcp",
                    "IpRanges": [
                        {
                            "CidrIp": "0.0.0.0/0",
                            "Description": "Redis"
                        }
                    ],
                    "Ipv6Ranges": [],
                    "PrefixListIds": [],
                    "ToPort": 6379,
                    "UserIdGroupPairs": []
                }
            ],
            "OwnerId": "aws_account_id",
            "GroupId": "sg-xxxxxxxxxxxx33290",
            "IpPermissionsEgress": [
                {
                    "IpProtocol": "-1",
                    "IpRanges": [
                        {
                            "CidrIp": "0.0.0.0/0"
                        }
                    ],
                    "Ipv6Ranges": [
                        {
                            "CidrIpv6": "::/0"
                        }
                    ],
                    "PrefixListIds": [],
                    "UserIdGroupPairs": []
                }
            ],
            "Tags": [
                {
                    "Key": "Environment",
                    "Value": "production"
                },
                {
                    "Key": "Private",
                    "Value": "true"
                }
            ],
            "VpcId": "vpc-xxxxxxxxxxxx380b4"
        }
    ]
}

I'm wondering if this is the most appropriate way to set up security permissions as they're in the same security group. Is it?

I got two CodeBuild projects which have the same subnet and security group in common, these two projects access to a cache node of the cluster without any issues.

Should I even create a dedicated subnet AND security group for the cluster subnet and instead allow ingress from the tasks and codebuild project security groups even from another subnet?

For connection to the cluster, I'm using the cache node cache.amazonaws.com URL, is this correct or would there be a safer way to route any localhost:6379 or even cache:6379 host url to the Elastic Cache cluster nodes automatically?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

且行且努力 2025-02-17 17:57:25

我什至是否应该为该专用子网和安全组创建
群集子网,而是允许从任务和代码构建
项目安全组甚至来自另一个子网?

不需要专用子网。但是,绝对需要一个专门的安全组。为同一安全组分配多种类型的多种服务是一个反模式。将它们分配给同一安全组没有任何好处,并且很难正确限制流量。

您应该为Elasticache创建一个安全组,并为您的ECS服务创建另一个安全组。然后,在您的Elasticache安全组中,您应该为端口6379创建一个入站规则,该规则允许分配给ECS服务的安全组流量。您可以通过在入站规则中指定安全组ID而不是CIDR块来执行此操作。

要连接到群集,我正在使用缓存节点
cache.amazonaws.com URL,这是正确的还是有更安全的方式
路由任何Local主机:6379甚至缓存:6379主机URL到弹性
缓存群集节点自动?

localhost显然无法正常工作,因为它们不在同一主机上。

您可以将Route53私有托管区域添加到VPC,然后为Cache.mydomain> eustrasticache群集创建一个DNS条目。但是,您当前正在这样做的方式,使用“ cache.amazonaws.com”端点URL完全可以,如果您想对连接进行SSL验证,则必须使用该URL。

Should I even create a dedicated subnet AND security group for the
cluster subnet and instead allow ingress from the tasks and codebuild
project security groups even from another subnet?

A dedicated subnet is not needed. However a dedicated security group is absolutely needed. Assigning multiple services of different types to the same security group is an anti-pattern. Assigning them to the same security group provides no benefit, and makes it difficult to properly restrict traffic.

You should create a security group for Elasticache, and another security group for your ECS service. Then, in your Elasticache security group you should create an inbound rule for port 6379 that allows traffic from the security group assigned to the ECS service. You would do this by specifying security group ID in the inbound rule, instead of CIDR block.

For connection to the cluster, I'm using the cache node
cache.amazonaws.com URL, is this correct or would there be a safer way
to route any localhost:6379 or even cache:6379 host url to the Elastic
Cache cluster nodes automatically?

Well localhost obviously isn't going to work because they aren't on the same host.

You could add a Route53 private hosted zone to the VPC, and then create a DNS entry for something like cache.mydomain that points to the Elasticache cluster. However the way you are currently doing it, with the "cache.amazonaws.com" endpoint URL is totally fine, and if you ever wanted to do SSL verification on your connections you would have to use that URL.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文