Secrets manager plus usage in RDS create

[sckott]

@seankross Here's the high level changes here:

Add family of functions for AWS secrets manager

fix #29

• aws_secrets_all
• aws_secrets_create
• aws_secrets_delete
• aws_secrets_get
• aws_secrets_list
• aws_secrets_pwd
• aws_secrets_rotate
• aws_secrets_update

Integrate secrets into RDS database create

Redshift uses the user's IAM credentials so I think it only makes sense to use secrets manager in RDS.

So aws_db_rds_create now allows the user to not pass in a user or password, and we create them for the user. Likewise, aws_db_rds_con automatically detects secrets in the users aws secrets manager and presents those in a prompt and asks which one they'd like to use, an example:

Make the DB

aws_db_rds_create(
  id = "pineapple", class = "db.t3.micro",
  security_group_ids = list("sg-xxx")
)

#> i `user` is NULL; created user: EvergreenMartyrd
#> i `pwd` is NULL; created password: *******
#> i Uploading user/pwd to secrets manager
#> Instance is up!
#> i See `aws_db_rds_con` for connection info
#> i Instance details:
#> i   host:
#> i   port:
#> i   dbname: dev
#> i   engine: mariadb
#> i   class: db.t3.micro

Get the conn

con_rds <- aws_db_rds_con(id = "pineapple")
#> No credentials were supplied
#> We found 2 in your AWS secrets manager
#> Which set of database credentials do you want to use?
#> 
#> 1: Secret name: bean-a60f072a
#>    Engine: mariadb
#>    Host: bean.xxxx.us-west-2.rds.amazonaws.com
#> 2: Secret name: abear-4027ba84
#>    Engine: mariadb
#>    Host: abear.xxxx.us-west-2.rds.amazonaws.com
#> 
#> Selection:

Secrets management

• gitignoring some test fixtures related to aws_secrets* functions and to the RDS create function
• added a make target make scan_secrets to run the command line tool gitleaks (https://github.com/gitleaks/gitleaks) on the repo. this isn't run automatically anywhere yet, just manually. they do have a github action for it too
• i'll talk or will have talked to you about testing strategy in our meeting ...

[sckott]

sean feedback

• aws_db_rds_create:
  • [x] what to return? invisible()? probably invisible, with some kind of success message
• aws_db_rds_con:
  • [ ] document security groups
  • [ ] possibly make it easier to handle/negotiate automagically ideally
  • [ ] maybe make passing 1 or more security group IDs to security_group_ids required? this would be a good way to lessen security group related problems - main one being that a naive user likely won't pass one and then be confused as to why they can not connect

[sckott]

workflow from sean:

aws_user_create("scott") # exists
aws_db_rds_create("aaa", "mariadb") # exists
add_user_to_rds_db("scott") # DOES NOT EXIST
aws_db_rds_list() # exists
#> # A tibble: 2 × 5
#>   DBInstanceIdentifier DBInstanceClass Engine  DBInstanceStatus DBName
#>   <chr>                <chr>           <chr>   <chr>            <chr>
#> 1 aaa                db.t3.micro      mariadb available         dev
#> 2 bbb                db.t3.micro      mariadb available         dev
con <- aws_db_rds_con("aaa") # exists
# do things with DBI/dplyr/etc

3 steps that need to happen for connecting to a DB instance using IAM authentication::

1. Enabling and disabling IAM database authentication
   • done with fxn: aws_db_rds_create with arg iam_database_auth=TRUE (possibly on by default?)
2. Creating and using an IAM policy for IAM database access
   • done with fxns: document_create, aws_policy_create, aws_policy_attach
3. Creating a database account using IAM authentication
   • done with fxn: not sure yet, a SQL eg for mariadb is CREATE USER jane_doe IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS';

Probably add_user_to_rds_db("scott") could handle steps 2 and 3

[sckott]

Going to try to split up this PR or possibly close and create two new ones for:

• secrets manager + vpc stuff
• stuff specifically for RDS create/etc.