feat(sc-dbuser) add policy for sc-dbuser

[morga471]

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.

[badra001]

Change this to be sc-dbuser
See other changes/comments

[morga471]

changes applied from feedback

[badra001]

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 Name). rds_username is what we should be using (so we'll add this doc somewhere), with a condition like

    condition {
      test     = "StringEquals"
      variable = "secretsmanager:ResourceTag/rds_username"
      values   = ["$${aws:PrincipalTag/jbid}"]
    }

[morga471]

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 Name). rds_username is what we should be using (so we'll add this doc somewhere), with a condition like

    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.

[morga471]

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.

[badra001]

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?

[morga471]

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 rds-db:connect to function, the user needs to be enabled for iam login inside the db. This permission grants nothing if the db isn't configured to enable it.

ADSD doc includes connection instructions in a docx. I can attach that here if desired.

[badra001]

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 rds-db:connect to function, the user needs to be enabled for iam login inside the db. This permission grants nothing if the db isn't configured to enable it.

ADSD doc includes connection instructions in a docx. I can attach that here if desired.

yes please