feat(sc-dbuser) add policy for sc-dbuser #3
Conversation
morga471
changed the title
|
changes applied from feedback |
|
I'm not seeing anything here which describes how one would use this with specific secrets. I do not believe we have defined (at an ent level) how to leverage secretsmanager with JBIDs. We need to define that. The two options shown in there should be more clearly scoped. For example, the jbid should be in a tag which we define (not condition {
test = "StringEquals"
variable = "secretsmanager:ResourceTag/rds_username"
values = ["$${aws:PrincipalTag/jbid}"]
} |
So this condition is saying that the secret should have a tag on it that is the rds_username tag, and the values in that tag should include the jbid of the caller, which is validated by the caller (aws:principalTag/jbid) having their jbid on their session? I don't think we currently add the jbid of a user to the IAM role or user that makes this call. So this wont work either. I included them per our conversation but this approach is definitely not ready for prime time. I am getting pressure to move this forward as it's part of a POAM. Since we know this wont work as is, I will remove the conditions until we are ready to implement something for secrets management. |
|
Follow up conversation with Mike Jones and Kalyana. Clarified effort is only for postgres and oracle concerns are out of scope. pulled out statements that were not relevant for postgres. |
Can you include the references to ADSD DBA documentation for how access to Postgres using IAM is to be setup and used, from both the command linux (say a linux host with a linux cli and python connection) as well as a DB tool such as DBeaver? Also, this policy allows connecting to every database in the account to which this role/policy is applied. How are we restricting access by DB to only the approrpriate SSO users? |
Yeah, this grants access to every DB because it's a two sided operation. In order for ADSD doc includes connection instructions in a docx. I can attach that here if desired. |
yes please |
|
Security Impact Analysis: |
|
rename to sc-dbuser update from comments fix syntax for passthrough var remove jbid stuff reduce to postgres usecase requirements only update changelog fix name Create README.md adding RDS MFA converted from .docx Update README.md with RDS MFA steps Create temp file in folder Add files via upload
|
|
||
| Choose one path depending on your deployment type. | ||
|
|
||
| ### RDS PostgreSQL instance |
There was a problem hiding this comment.
Would like terraform null resource example of making this change via Terraform (will not hold up merge for it though)
| } | ||
| ``` | ||
|
|
||
| ### Aurora PostgreSQL cluster |
There was a problem hiding this comment.
Would like terraform null resource example of making this change via Terraform (will not hold up merge for it though)
| ```json | ||
| { | ||
| "Version": "2012-10-17", | ||
| "Statement": [ | ||
| { | ||
| "Effect": "Allow", | ||
| "Action": ["rds-db:connect"], | ||
| "Resource": ["arn:aws:rds-db:us-east-1:123456789012:dbuser:cluster-ABCDEFGHIJKL01234/mydbuser"] | ||
| } | ||
| ] | ||
| } | ||
| ``` |
There was a problem hiding this comment.
Where does this value come from? I'd expect some details on how to construct the specific ARN here. We should also have a terraform data resource for the policy statement and not hardcode stuff. Also, we won't be able to do this with an SSO role.
| ```json | ||
| { | ||
| "Version": "2012-10-17", | ||
| "Statement": [ | ||
| { | ||
| "Effect": "Allow", | ||
| "Action": ["rds-db:connect"], | ||
| "Resource": ["arn:aws:rds-db:us-east-1:123456789012:dbuser:db-ABCDEFGHIJKL01234/mydbuser"] | ||
| } | ||
| ] | ||
| } | ||
| ``` |
There was a problem hiding this comment.
Where does this value come from? I'd expect some details on how to construct the specific ARN here. We should also have a terraform data resource for the policy statement and not hardcode stuff. Also, we won't be able to do this with an SSO role.
| } | ||
| ``` | ||
|
|
||
| ## 2. Create or update IAM policy for connect permission |
There was a problem hiding this comment.
What is dbuser? Is it the JBID? The email address?
There was a problem hiding this comment.
According to the policy, it is the email address (all lowercase). See https://github.e.it.census.gov/terraform-modules/aws-sso/pull/3/files#diff-fb90d613136f0d47a7d3fd49d287d6fcb5a7dc7005dd0704ffc05ee272f5cef8R27-R37.
Please indicate that it's an email address.
| ``` | ||
|
|
||
| Token notes: | ||
| - Token lifetime is about 15 minutes. |
|
Be sure to address the comments post-testing. |
This creates the policy object for sc-dbuser.
this will be used to create sso PS following normal patterns.
this is only to resolve the postgres dbuser use-case, we will address oracle specific concerns at a later time.