-1

I'm using CloudFormation to set up a DocumentDB cluster inside a new VPC. CloudFormation is setting up everything, including the VPC, the DocumentDB password secret, and the secret's rotation. I'm following closely the DocumentDB example at AWS::SecretsManager::RotationSchedule.

I'm at the point where I'm setting up the AWS::SecretsManager::RotationSchedule HostedRotationLambda for MongoDBSingleUser. The confusing bit is the VpcSecurityGroupIds, which says:

A comma-separated list of security group IDs applied to the target database.

The templates applies the same security groups as on the Lambda rotation function that is created as part of this stack.

The example seems to use Fn::GetAtt to get the default security group of the VPC.

          Fn::GetAtt:
          - TestVPC
          - DefaultSecurityGroup

But I've set up a special security group just for the database, allowing ingress on port 27017 for DocumentDB. Wouldn't I want to simply reference this MyCustomDocumentDBSecurityGroup for the lambda, rather than the VPC's default security group?

I guess the crucial part I'm missing is that I don't understand the purpose of VpcSecurityGroupIds. It looks like it's assigning the security group to the lambda. But I'm not sure why the lambda would need a security group. Or rather, it would seem that the lambda would need the inverse of the database's security group—it needs egress to port 27017, not ingress, in order to connect to the database and update its password, no?

After reading the documentation again, it sounds like this security group is placed on the lambda when it is created, and then when the lambda runs it applies that same security group to the database. But why? My template already applies that security group to the database. Maybe this is to apply another security group to the database after rotation? But why?

I see that VpcSecurityGroupIds is optional. If I just leave it off, will everything be fine and the database will keep the security group I've already assigned? But then why does the example assign a security group?

Update: From the comments here it would seem that I should provide a separate security group for the lambda in order for it to access the VPC endpoint. But Set up automatic rotation for Amazon RDS, Amazon Redshift, or Amazon DocumentDB secrets using the console says "The rotation functions … have the same VPC and security group as the database …." That seems to indicate I should just set the lambda to use the security group I created for the database. The documentation is very confusing and inconsistent.

Garret Wilson
  • 18,219
  • 30
  • 144
  • 272
  • 1
    I'm highly suspicious of that documentation language. You provide the security groups of the DocumentDB and then "The templates applies the same security groups as on the Lambda rotation function" ? I suspect what it *means* to say is that you supply security group(s) that are attached to the lambda, but instead it makes the suggestion to use the *same* security groups. I don't know if the template actually creates security group rules (allowing itself I guess?) or just assigns the security group to the lambda – erik258 Apr 08 '23 at 15:18
  • … and that's why I'm wondering the _purpose_ of the security group. If I knew what it was used for, it might be more obvious which sort of security group I should reference here. – Garret Wilson Apr 08 '23 at 15:22
  • 1
    Suspect what's happening here is that AWS is keeping the sample as simple as possible with everything in the default security group (which you can, of course, customize). The HostedRotationLambda needs access to Secrets Manager and it does this via SecretsManagerVPCEndpoint which has the default security group. And the default security group allows inbound traffic on all ports, all protocols from network interfaces and instances that are assigned to the same security group. – jarmod Apr 08 '23 at 15:36
  • But why does the lambda need to _know_ about a security group? If you as a remote user try to access a web server in my VPC using your browser, the security group is _applied_, but you as the requesting client don't need to name the security group when making the request. Why does the lambda need to know anything about the security group? Why doesn't it just make the request, and it either succeeds or fails based upon whether I've set up a security group correctly to allow it? – Garret Wilson Apr 08 '23 at 15:40
  • Or is the security group somehow applied to the lambda itself? But the documentation says the security group is applied to the target database. – Garret Wilson Apr 08 '23 at 15:43
  • 1
    Applied to both afaik. Lambda functions that access private endpoints such as databases in VPC or VPC endpoints *must* be attached to the VPC. That requires you to supply a subnet ID and optional security group. – jarmod Apr 08 '23 at 15:51
  • 1) But if I already have a security group applied to my database, why would it apply _another_ one? 2) And if the lambda security group is optional as you point out, what happens if I leave it off? – Garret Wilson Apr 08 '23 at 15:52
  • Maybe the name `VpcSecurityGroupIds` is misleading. [Apparently](https://stackoverflow.com/a/68618372) there used to be something called a "DB security group" for databases not in a VPC, so maybe the name `VpcSecurityGroupIds` simply means "not that old thing called a 'DB security group', but the new 'VPC security group' everyone should use now". So maybe this just means I should reference the security group I've associated with the database cluster? – Garret Wilson Apr 08 '23 at 15:59
  • 1
    If you want to customize the template, feel free to do that. Typically you would not use the default security group for these things but, as suggested earlier, this keeps the sample easy to understand. If the Lambda function is attached to VPC but has no security group then it can't communicate with endpoints that only allow ingress from the [default security group](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/default-custom-security-groups.html) i.e. your database and the Secrets Manager VPC endpoint. – jarmod Apr 08 '23 at 16:00
  • "Typically you would not use the default security group for these things …" OK, then what would one typically do for these things? Should I set up a custom security group for the lambda to access SecretsManagerVPCEndpoint thing? But then what addresses or ports would I need to open? Is there documentation on this? I want to do it the right way. – Garret Wilson Apr 08 '23 at 16:13
  • Oh, I see in the example that it is creating a `SecretsManagerVPCEndpoint`. I missed that. And it is specifying the same VPC default security group. So I suppose I need to specify the same security group for the lambda. But if it's best practice to create a custom security group for the VPC endpoint, how should I configure it? – Garret Wilson Apr 08 '23 at 16:38
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/253049/discussion-between-jarmod-and-garret-wilson). – jarmod Apr 08 '23 at 17:00
  • OK, but see my (new) related question, [Use of security group for AWS Secrets Manager endpoint](https://stackoverflow.com/q/75966588). – Garret Wilson Apr 08 '23 at 17:04

1 Answers1

0

If I got it correctly, you want to know why AWS::SecretsManager::RotationSchedule HostedRotationLambda asks for a list of VpcSecurityGroupIds. As you got from the documentation:

A comma-separated list of security group IDs applied to the target database. The templates applies the same security groups as on the Lambda rotation function that is created as part of this stack.

This means that when this property is set with VpcSubnetIds, your lambda will be inside a VPC.

If your DocumentDB cluster/instance is inside a private subnet group, you'll need to place your lambda in the same VPC in a security group with explicit access to the database subnet group and specific port. You mentioned that you created a specific security group that allows access to the database. This is needed to access the database and rotate the password.

matheusopedro
  • 128
  • 1
  • 13