什么是设置ECS任务的最合适,最安全的方法 - 弹性缓存群集连接?
我有一个弹性缓存群和一个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 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
不需要专用子网。但是,绝对需要一个专门的安全组。为同一安全组分配多种类型的多种服务是一个反模式。将它们分配给同一安全组没有任何好处,并且很难正确限制流量。
您应该为Elasticache创建一个安全组,并为您的ECS服务创建另一个安全组。然后,在您的Elasticache安全组中,您应该为端口
6379
创建一个入站规则,该规则允许分配给ECS服务的安全组流量。您可以通过在入站规则中指定安全组ID而不是CIDR块来执行此操作。好
localhost
显然无法正常工作,因为它们不在同一主机上。您可以将Route53私有托管区域添加到VPC,然后为
Cache.mydomain
> eustrasticache群集创建一个DNS条目。但是,您当前正在这样做的方式,使用“ cache.amazonaws.com”端点URL完全可以,如果您想对连接进行SSL验证,则必须使用该URL。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.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.