Add master_password output to return generated password.

[petur]

what

• Add a master_password output for the generated password.

why

• The generated password needs to be stored somewhere so that it's possible to use it to connect to the cluster.
• This can for example be done by storing it in an aws_secretsmanager_secret_version as part of the terraform configuration that creates the cluster.
• Exposing the password as a module output makes it available to other parts of the configuration so that the password can be passed to the resource that stores it.

references

• closes Error: Invalid count argument for random_password resource #43

[erikhaq]

/test all

[kevcube]

Terraform didn't support sensitive until 0.14.0 so this PR should also update versions.tf @petur

I asked in CloudPosse slack for them to review this when they can.

[milldr]

We try to avoid writing secrets to Terraform state. Instead we can save the password to SSM and add the path to the SSM parameter to outputs

[petur]

We try to avoid writing secrets to Terraform state. Instead we can save the password to SSM and add the path to the SSM parameter to outputs

The random_password resource saves the generated password in the terraform state, so that is already happening. This PR doesn't change that.

[kevcube]

Yes @milldr all object attributes are saved in terraform state regardless. Though the SSM parameter does make it easier to access this password from other places.

[milldr]

The random_password resource saves the generated password in the terraform state, so that is already happening. This PR doesn't change that.

Good point. I'll trigger the tests and approve once they pass

[milldr]

/test all

[milldr]

/rebuild-readme

[milldr]

/test all

[milldr]

We should revert this change, since Cloud Posse modules still support v 0.13

[kevcube]

@milldr without that change outputs can't be marked sensitive, and then we definitely need the SSM component. But see Here, it looks like CloudPosse is ok with moving forward from 0.13

[kevcube]

Check with Erik please (I know he was a part of the discussion with Matt), I think if we're good to move past 0.13 then this PR should jump to 1.3.0 or even 1.4.2 so that we don't face this version upgrading problem in the future in this module.

[milldr]

okay I've checked and it's no problem to bump that version. But in order for the tests to pass we need to update the version provided with testing

https://github.com/cloudposse/terraform-aws-documentdb-cluster/blob/master/examples/complete/versions.tf#L2

[kevcube]

@milldr friendly ping for re-review

[milldr]

/terratest

[milldr]

/terratest

[milldr]

Looks good! thanks for following up on this