I am testing the CloudSQL IAM automatic authenticationby using IAM service account users. The goal is to deploy a backend service running in cloud with an service account (SA), which can connect onto a CloudSQL database without using password auth.
So this is what I did:
Create a cloud SQL database demo-db via gcloud console
Create a service account sa via gcloud console
Create a backend service and run it in k8s with sa as the account, with the help of cloud-sql-jdbc-socket-factory
. And make the backend service having liquibase schema migration so it can create tables
Create a IAM service account user user-sa in demo-db via gcloud console
Create a normal built-in user user-db (with a password) in demo-db via gcloud console (for my local login/psql to the db)
Deploy the backend to production, and it connected (with user-sa) and created tables in demo-db (with liquibase)
And this is a problem I have now:
When I use cloud-sql-proxy to login the demo-db locally via psql, with user user-db and the password, I realise that I cannot view or select the table created by the backend service (via user-sa).
Then how can I view the data in the database as a developer?
PS: Fow now I don't have access to user-sa or sa's secret/key files. As it is managed by our infra. I only have ownership of demo-db and I could give access right of my db to user-sa ...
I had the same issue on AWS's Postgres RDS.
You (as the backend creation service) basically have to create a role, place your deployment role (user-sa) into that role and also your app user (user-db).
Then your deployment script will have to use ALTER <OBJECT> OWNER TO <ROLE>. Now every role or user in that role will have access. You'll have to do this for functions, tables, etc
Another alternative is to set default permissions via ALTER DEFAULT PRIVILEGES, but note that those only take effect on new objects. If you add a new db role afterward and want to grant it permissions to a table that already existed, you'd still have to add explicit permissions for the new role.
* Note that in postgres, a role and user are interchangeable in commands. In my view, a role does not log in, but it can be used to hold a set of permissions. Instead of assigning permissions to individual users, assign them to a group/role, then grant the user membership to the group/role. Ensure that your inheriting permissions is allowed on the users and roles for this to work.
Related
I have an application with a Postgres CloudSQL instance where the tables were set up by a developer's IAM account. Thus they are owned by that IAM account, and I'd now like to set them so they are owned by a IAM service account instead. However, I'm having a hard time getting REASSIGN OWNED to work, just getting permission issues instead.
I found this somewhat similar documentation entry on how to reassign ownership by doing GRANT "user#domain" TO "serviceaccount#project.iam". However, as soon as I do this, the service account is no longer able to log in, getting FATAL: Cloud SQL IAM user authentication failed for user serviceaccount#project.iam. Revoking the grant allows login again, but I'm then unable to reassign ownership...
When testing on a separate instance, I did get the procedure to work between user accounts, and also from a service account to a user account, but not user account to service account.
Is there a either a way for a service account to be able to log in while GRANTed on the user account, or some other way to do ownership reassignments?
I have data held in an Azure Data Lake Gen 2 storage container. I would like to provision this data for an existing report authored in Crystal Reports using SQL on demand.
During development I used my own Azure AD login via an ODBC connection on my local machine. I have access to the Synapse environment and also the data lake. This worked successfully and although slow, pulled all information required.
To deploy this solution correctly I need to remove my AAD creds and use a provisioned service principle. I have given the service principle to read from the data lake and also added the principle to the SQL database. Now I am stuck on how to use the principle to connect to Crystal Reports.
I have tried the same authentication type as with my AAD but now I am using a clientID not a email. So when the system prompts for connection details it wants you to sign in and does not accept the clientID.
Does anyone have any suggestions on how to connect to Crystal Reports using this way or any other way?
Also: My org does not want this user or app reg to have restricted permissions so therefore adding them to the RBAC "synapse admin" wont work.
Thanks
Tom
Found a way around this.
Create a service account user on Azure Portal. Head to Synapse Analytics and open blank SQL script to give the user minimal permissions.
*USE [master]*
CREATE LOGIN [serviceaccountsynapseuser#company.onmicrosoft.com] FROM EXTERNAL PROVIDER
GRANT CONNECT ANY DATABASE TO [serviceaccountsynapseuser#company.onmicrosoft.com]
GRANT SELECT ALL USER SECURABLES TO [serviceaccountsynapseuser#company.onmicrosoft.com]
*USE [Reporting] (Serverless SQL DB)*
CREATE USER [serviceaccountsynapseuser#company.onmicrosoft.com] FROM EXTERNAL PROVIDER
ALTER ROLE db_datareader ADD MEMBER [serviceaccountsynapseuser#company.onmicrosoft.com]
Finally head to the storage account and give the user storage blob reader role.
I'd like to limit the privileges afforded to any given user that I create via the Google Terraform provider. By default, any user created is placed in the cloudsqlsuperuser group, and any new database created has that role/group as owner. This gives any user created via the GCP console or google_sql_user Terraform resource total control over any database that is (or was) created in a similar fashion.
So far, the best we've been able to come up with is creating and altering a user via a single-run k8s job. This seems circuitous, at best, especially given that that resource must then be manually imported later if we want to manage it via Terraform.
Is there a better way to create a user that has privileges limited to a single, application-specific database?
I was puzzled by this behaviour too. Its probably not the answer you want but if you can use GCP IAM accounts the user gets created in the PostgreSQL instance with NO roles.
There are 3 types of account you can create from "gcloud sql users create" or terraform module "google_sql_user"
"CLOUD_IAM_USER", "CLOUD_IAM_SERVICE_ACCOUNT" or "BUILT_IN"
The default is the built_in type if not specified.
CLOUD_IAM_USER and CLOUD_IAM_SERVICE_ACCOUNTS get created with NO roles.
We are using these as integration with IAM is useful in lots of ways (no managing passwords at database level is a major plus esp. when used in conjunction with SQL Auth Proxy).
BUILT_IN accounts (ie old school need a postgres username and password) for some reason are granted the "cloudsqlsuperuser" role.
In the absence of being allowed the superuser role on GCP this is about as privileged as you can get so to me (and you) seems a bizarre default.
I would need to have a CloudSQL instace created with particular service account. Trying API call instances.insert:
POST https://www.googleapis.com/sql/v1beta4/projects/{project}/instances
{
"serviceAccountEmailAddress": "<my account>#managed-gcp.iam.gserviceaccount.com",
"name": "pvtest20200611-3",
"settings": {
"tier": "db-n1-standard-1"
},
"databaseVersion": "MYSQL_5_7"
}
The instance is created but it has a generated svc account (e.g. p754990076948-kf1bsf#gcp-sa-cloud-sql.iam.gserviceaccount.com) instead of mine.
For my SA, I have storage admin/storage object admin roles assiged (this is what I would need newly created instances to always have). I also added cloudsql admin role. When I thought it was a role problem so even tried the Project Editor role, but this didn't work.
I have tried MySQL and Postgres db types.
Would you know why is not my account picked up, why is CloudSQL engine always assigning it's own?
What are requirement/setup for custom SA to work with CloudSQL instance?
When you create an instance in Cloud SQL, it will use the default one during the creation, so, you won't be able to set a custom one during the creation.
It's possible, however, for you to give access and permissions for a Service Account after the creation. As explained in the official documentation Granting roles to a service account for specific resources, you can provide specific permissions to your Service Account. You can try using the gcloud command as follows:
gcloud projects add-iam-policy-binding my-project-123 \
--member serviceAccount:my-sa-123#my-project-123.iam.gserviceaccount.com \
--role roles/editor
Besides that, you can also check all your available Service Accounts using this link here, to verify if your custom one is there and even add the permissions via UI, if you think it's better via this way.
Let me know if the information helped you!
I want to give access to my developer to my MongoDB which is hosted by an EC2 Instance on AWS.
He should be able to make mongodump, upload the new backend and do some changes on our control Panel.
I created an IAM User with EC2FullAccess Permissions - I have seen that he was able to add his own IP to the Security Group so he could connect.
I don't feel so comfortable with that - what should I do, to secure myself that he has just enough access to do the necessary work:
Upload new code to server
Do MongoDB dump
I don't want him to be able to switch off/delete my instance or be able to delete my database at all.
Looking at your use case, you do not need to give any EC2 permissions, your developer does not even need IAM user, he can simply have the IP of the instance and the login credentials to the EC2 Instance, that should be suffice to log in to the instance and make the required changes. No need for an IAM user or AWS Console access.
IAM roles are for the purpose of accessing a service on behalf of another. Say, you want to access AWS DynamoDB or S3 from EC2 instance. In this case, an IAM role with required permissions attached to EC2 will server the purpose.
IAM User is for users who need access to AWS services either through Console or through API (programmatic). AWS credentials are required to access the service.
In your case, MongoDB is installed on EC2 and your developer needs access to "the server on which MongoDB is installed" and is not required any access of "AWS EC2 Service".
As correctly pointed out in answer by #X-Men, IAM role or IAM user is not at all required. What required is, your developer to have the IP of server and credentials to login to that server. Username-password or username-key.
Restriction which you need on developer related to MongoDB are to be configured on MongoDB itself and not on EC2 level.