Add SSM Parameter option for DBOwner User and Database Name

[davidholsgrove]

• Extending the use of SSM Parameters for the RDS DBOwner details, to match the Password capability.
• Add log level in line with binxio cfn secret provider
• Add is_valid_request in line with binxio cfn secret provider
• Add 60 second connection timeout on db connection

[mvanholsteijn]

Hi @davidholsgrove, good to see you this provider is useful for you. Can you explain me the rationale of getting everything from the parameter store? I only use the parameter store to avoid having the password in clear text in CloudFormation.

Would SSM parameter as CFN parameter solve your problem as well? https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html#parameters-section-ssm-examples

[davidholsgrove]

Apologies @mvanholsteijn, my PR didn't describe the reason very well.

I have a cloudformation template database-and-user.yaml that is used by my team as a nested template they drive with by providing a small set of parameters, e.g;

TestDBAndUser:
    Type: "AWS::CloudFormation::Stack"
    Properties:
      TemplateURL: "../templates/postgres/database-and-user.yaml"
      Parameters:
        Company: example
        ProjectName: project
        CreateDatabase: "true"
        DeletionPolicy: "Retain"
        SSMParamsMasterDB: "/shared/devqa/database/master"
        DBEndpointAddress: !GetAtt SharedRDS.Outputs.RDSInstanceEndpoint

This nested template creates the following resources;

• DatabaseAddress (AWS::SSM::Parameter)
• DatabaseNameParam(AWS::SSM::Parameter)
• DatabaseUserParam(AWS::SSM::Parameter)
• DatabasePassword (Custom::Secret)
• DatabaseAndUser (Custom::PostgreSQLUser)

with the custom PostgreSQLUser being created as;

DatabaseAndUser:
    Type: Custom::PostgreSQLUser
    Properties:
      Name: !GetAtt DatabaseNameParam.Value
      User: !GetAtt DatabaseUserParam.Value
      Password: !GetAtt DatabasePassword.Secret
      WithDatabase: !Ref CreateDatabase
      DeletionPolicy: !Ref DeletionPolicy
      # the database instance to create the new user or database in;
      Database:
        Host: !Ref DBEndpointAddress
        Port: !Ref DBInstancePort
        # The db owner details (database name, user and password) are retrieved from SSM by parameter name:
        DBNameParameterName: !Sub "${SSMParamsMasterDB}/dbname"
        UserParameterName: !Sub "${SSMParamsMasterDB}/user"
        PasswordParameterName: !Sub "${SSMParamsMasterDB}/password"
      ServiceToken: !Sub 'arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:function:binxio-cfn-postgresql-user-provider'

Being able to provide the db owner database name, user and password to the custom resource function the same way provides a consistent way to create those details, store them in SSM under a common prefix, and then allow them to be retrieved when needed.

I originally had my nested template take the db owner database name, etc as input SSM Parameters, and then the password as a string but felt that was a bit inconsistent?

DBInstanceAdminUserParamName:
    Type: AWS::SSM::Parameter::Value<String>
    Description: Name of SSM Parameter storing RDS Master Admin User

DBInstanceAdminPasswordParamName:
    Type: String
    Description: RDS Master Admin Password SSM Parameter Name

[mvanholsteijn]

Hmmm, would it be helpful if we would support Postgres IAM authentication to get rid of the 'Database' connect parameter settings?

…

On Wed, Sep 18, 2019 at 8:14 AM David Holsgrove ***@***.***> wrote: Apologies @mvanholsteijn <https://github.com/mvanholsteijn>, my PR didn't describe the reason very well. I have a cloudformation template database-and-user.yaml that is used by my team as a nested template they drive with by providing a small set of parameters, e.g; TestDBAndUser: Type: "AWS::CloudFormation::Stack" Properties: TemplateURL: "../templates/postgres/database-and-user.yaml" Parameters: Company: example ProjectName: project CreateDatabase: "true" DeletionPolicy: "Retain" SSMParamsMasterDB: "/shared/devqa/database/master" DBEndpointAddress: !GetAtt SharedRDS.Outputs.RDSInstanceEndpoint This nested template creates the following resources; - DatabaseAddress (AWS::SSM::Parameter) - DatabaseNameParam(AWS::SSM::Parameter) - DatabaseUserParam(AWS::SSM::Parameter) - DatabasePassword (Custom::Secret) - DatabaseAndUser (Custom::PostgreSQLUser) with the custom PostgreSQLUser being created as; DatabaseAndUser: Type: Custom::PostgreSQLUser Properties: Name: !GetAtt DatabaseNameParam.Value User: !GetAtt DatabaseUserParam.Value Password: !GetAtt DatabasePassword.Secret WithDatabase: !Ref CreateDatabase DeletionPolicy: !Ref DeletionPolicy # the database instance to create the new user or database in; Database: Host: !Ref DBEndpointAddress Port: !Ref DBInstancePort # The db owner details (database name, user and password) are retrieved from SSM by parameter name: DBNameParameterName: !Sub "${SSMParamsMasterDB}/dbname" UserParameterName: !Sub "${SSMParamsMasterDB}/user" PasswordParameterName: !Sub "${SSMParamsMasterDB}/password" ServiceToken: !Sub 'arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:function:binxio-cfn-postgresql-user-provider' Being able to provide the db owner database name, user and password to the custom resource function the same way provides a consistent way to create those details, store them in SSM under a common prefix, and then allow them to be retrieved when needed. I originally had my nested template take the db owner database name, etc as input SSM Parameters, and then the password as a string but felt that was a bit inconsistent? DBInstanceAdminUserParamName: Type: AWS::SSM::Parameter::Value<String> Description: Name of SSM Parameter storing RDS Master Admin User DBInstanceAdminPasswordParamName: Type: String Description: RDS Master Admin Password SSM Parameter Name — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#8?email_source=notifications&email_token=AAEMY2ZURUBKM6TB53BT6JDQKHBL7A5CNFSM4IWLNZF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD665UCA#issuecomment-532535816>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEMY267WJZOA6GIMSP5CSDQKHBL7ANCNFSM4IWLNZFQ> .

-- ing.Mark van Holsteijn tel: +316-22-374-114