Referencing the default security group is possible using:
{ "Fn::GetAtt" : ["VPC", "DefaultSecurityGroup"] }
Where "VPC" is your VPC resource name.
With AWS::EC2::SecurityGroupIngress
and AWS::EC2::SecurityGroupEgress
, you can augment the permissions of this default security group.
I think this is what you want:
"VPCDefaultSecurityGroupIngress": {
"Type" : "AWS::EC2::SecurityGroupIngress",
"Properties" : {
"GroupId": { "Fn::GetAtt" : ["VPC", "DefaultSecurityGroup"] },
"IpProtocol":"tcp",
"FromPort":"22",
"ToPort":"22",
"CidrIp":"0.0.0.0/0"
}
},
As mentioned by @artbristol and @gabriel, this allows Ingress/Egress rules to be added to the default security group for the VPC in a single stack deployment.
I'm pretty sure that the self-referential problem still impacts any attempts at changing any of the other properties on the default security group of the VPC. A good example of this would be adding Tags, or a Description. If you wish to change these things, you'll have to deal with extraneous security groups laying around.
First, before I get to the real answer, I'm going to explain why I'm not directly answering your question. Sure, you could likely write up some script that would do what you wanted. It would solve this problem, but would do nothing at all to solve the dozens of other potential problems you'll run into sooner or later.
So with that, here's the real answer...
You've run afoul of the most important rule when using AWS for anything serious: the web console is for inspection only, not making changes. It is just plain too easy to forget steps, mess things up, terminate the wrong instance, etc. when using the web console.
When creating instances, you and your staff should only be using one of the many technologies AWS provides to create resources in a controlled, reliable, repeatable manner.
At the very least, get to know the AWS Powershell Tools. After you've familiarized yourseif with them, create, publish, and distribute to your staff a standard method of interacting with AWS.
Ideally, you would create a wrapper around their API, which your staff can use, which would force them to provide relevant tag info before instance creation.
Additionally, ensure that all of your staff are using their own IAM user. Do not, under any circumstances, permit anyone other than the account owner have the account root credentials - even that person should only use those credentials for the bare minimum of tasks, instead using an IAM user as well.
Best Answer
You can use the
autoscaling describe-auto-scaling-instances
command together with the option--instance-ids
, like this:I'm interpreting this as you want to get the tags of the autoscaling group from which the instance belongs to? Using the
AutoScalingGroupName
returned from the command shown above, you can use the following command: