Question : how is this more secure than sharing the password with devs ?

[christopheblin]

In the demo-stack.yaml, you are doing :

Outputs:
  Secret:
    Value: !GetAtt 'DBPassword.Secret'
    Description: the generated secret, do expose this as Output Parameter in production

Doing this, when I access the CloudFormation service (a service that the dev team also has access to) I can directly see the password in the Ouputs tab of the stack

So how is this more secure than sharing the password with devs ?

[mvanholsteijn]

This was only done for the demo. If you specify ReturnSecret = False (the default), the secret is not available except through the ParameterStore.

[christopheblin]

Thanks for the quick answer !

My next question is : if you dont export the password, how do you access the password from another stack ? and how do you access the password to configure external tools (if any) ?

For ex, I am used to give the login and password via parameters, creating the RDS instance and then exporting the necessary info :

Outputs:
  DevRDSInstanceDbName:
    Description: The database name
    Value: "somename"
    Export:
      Name: DevRDSInstanceDBName
  DevRDSInstanceAddress:
      Description: The address of the RDS
      Value: !GetAtt RDSInstance.Endpoint.Address
      Export:
        Name: DevRDSInstanceAddress

Then in another stack, I can give the same parameters for login and password and do :

Environment:
    Variables:
      DB_USERNAME: !Ref RDSLogin
      DB_PASSWORD: !Ref RDSPassword
      DB_NAME:
        Fn::ImportValue: DevRDSInstanceDBName
      DB_HOST:
        Fn::ImportValue: DevRDSInstanceAddress

With your technique, I suppose that you use the DBPassword.Arn in some way ?

[christopheblin]

And another question : how do you change a secret and propagate the new value ?

For ex, I have a stack with an RDS instance that use a secret and stack that uses this password.

How do I change the password and "reload" the other stacks ?

[mvanholsteijn]

Hi @christopheblin,

If you set the property 'RefreshOnUpdate' and 'Returnsecret' a new secret will be generated and accessible through Fn::GetAtt. You can force CFN to update the password by specifying a new value for the property 'Version'.

If you specify !GetAtt 'DBPassword.Secret' as your value for the MasterPassword, the change will propagate.

The clients will need to reread the secret from the parameter store.

Hope this helps.

Cheers,

Mark

[mvanholsteijn]

@christopheblin,

Perhaps you will find some use for the postgresql-user-provider. It allows you create users with their own set of credentials while using the MasterUserPassword obtained from the parameter store to create that user.

Cheers,

Mark