Hi folks - on creating a DirectoryService, AWS aut...
# aws
e
Hi folks - on creating a DirectoryService, AWS auto-generates a security group for the domain controllers. I need to amend the 15-odd rules in that group (replacing their default CIDR with our own prefix list). Trouble is pulumi's DirectoryService resource only gives me the
security_group_id
. There's a method called getSecurityGroup() but that doesn't actually seem to get a handle on the security group, but instead looks like a metadata object. I guess I really want the equivalent of
pulumi import
command, but inline in my main script after creating the directory, so I the script itself can amend the generated rules. What's the best way to achieve this?
l
Are you sure you need the security group? When I did this, I just used code like
Copy code
new aws.ec2.SecurityGroupRule("ForMyCIDR", {
  securityGroupId: ad.securityGroupId,
  // ...
});
(Forgive the typescript...)
e
Well I need to replace the rules that are there
(or amend them at least)
l
Ah. So the default rules for it always use 0.0.0.0/0, I think? I didn't have a problem with that, because I put my AD in a couple of private subnets, whch share an NACL that restricts access by IP range. So I didn't need to worry about the existing 0.0.0.0/0.
Ok let's sort the problem as stated. Are you looking for the awsx or aws version of the SecurityGroup?
e
aws
(we have a different setup that wont allow me to mirror your solution with NACLs sadly - and yeah, it's the 0.0.0.0/0 range I need to replace)
l
The
getSecurityGroup()
method you mentioned is a wrapper around the SDK function, it returns the "real" SDK security group, rather than Pulumi's nicely-OO one.
You can use either
new SecurityGroup("x", { id: ad.securityGroupId }, {})
or
SecurityGroup.get("x", ad.securityGroupId)
to load the Pulumi view of the security group, with the latter being preferred. This gives you a read only (sort-of) version, which is good enough for creating security group rules.
However, if you're happy that you'll (almost) never delete the AD instance (which is a reasonable assumption in my mind), you might prefer not to worry about the SG itself, and instead import the SG rules directly.
👀 1
Hmm.. something I haven't tried, but just noticed in the docs..
security_group_id
seems to be allowed as an input value?
Ah, no, never mind, was looking in the "Look up existing directory resource" section. It's not there in the "Inputs" section.
e
OK, but import's a manual step, right?
I need to automate this as part of the directory creation
l
Yes, which is why it works only if you'll never delete the directory. Are you likely to have more than one directory?
You could create the directory, then update the code with the results of
pulumi import
.
However that won't work if you're creating directories on demand 😞
e
yeah we have multiple environments
and we'll have federated directories
The aim is to script it end to end
l
Just checking if the aim is flexible 🙂 I have a few steps in my code that would require editing if I was ever to recreate my VPC peering. I think you'll have to go with the
get()
static method.
e
This one, right?
It requires resource_name as an input...
l
Yep
e
presumably that's the pulumi resource name
not the "name" on the getSecurityGroup() result
l
Resource_name is the Pulumi name, same as all your resource constructors. It isn't related to AWS, only Pulumi's state.
Only the id field relates to AWS.
e
got it. So pulumi wont know about this resource
l
It will have a "I don't manage this" record in state. If (for example) you destroyed the stack, it wouldn't destroy the SG.
e
Oh ok, so... I can just just pass any resource_name there
l
Yes. You would use that only for things like
pulumi state delete
It goes into the Pulumi URN.
e
got it. So would that new SecurityGroup instance have the rules directly defined on it? If so, how do i update them?
(sorry I need spoon feeding here - feeling a little stupid... docs can be hard to follow)
l
Honestly, I have no idea 🙂 You can
pulumi stack export
after running it to see what objects are in it? If you're lucky, you might have an array in the
ingress
and
egress
properties, which you could empty, and create new SecurityGroupRule objects instead.
e
Yeah, I don't see any api that allows me to do that
l
But it's going to be a step-by-step learning approach.. I'm not even sure that you can empty the array and expect that to "just work".. you might have to fall back on the SDK...
If I was in your shoes, I'd be looking for ways to make the bulit-in rules work for you / with your constraints....
The NACL option is just one. There may be others.
For example, I might consider emailing all the solution / enterprise architects a link to this page: https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started_what_gets_created.html With highlighting of this bit:
Creates an AWS security group that establishes network rules for traffic in and out of your domain controllers. The default outbound rule permits all traffic ENIs or instances attached to the created AWS Security Group. The default inbound rules allows only traffic through ports that are required by Active Directory from any source (0.0.0.0/0). The 0.0.0.0/0 rules do not introduce security vulnerabilities as traffic to the domain controllers is limited to traffic from your VPC, from other peered VPCs, or from networks that you have connected using AWS Direct Connect, AWS Transit Gateway, or Virtual Private Network. For additional security, the ENIs that are created do not have Elastic IPs attached to them and you do not have permission to attach an Elastic IP to those ENIs. Therefore, the only inbound traffic that can communicate with your AWS Managed Microsoft AD is local VPC and VPC routed traffic. Use extreme caution if you attempt to change these rules as you may break your ability to communicate with your domain controllers.
That might make life easier?
e
Heh, maybe. It's an automated ruleset for ISO27001 I'm trying to comply with, so... maybe not either.
I'll give it a try tho - useful info.
Be nice to have that on pulumi tho 😉
Thanks for your help @little-cartoon-10569
👍 1
l
Contact your AWS client manager and find out if they have ISO27001-compatible evidence that their set-up is good as-is.
I know they have that for a few other standards.
You can just download something from them and keep it in your "For the auditors" folder.