When creating users in the DB2 console on IBM Cloud is there a way to resrtict user access to selected schema/s only? I am running on the SMP Small version.
Different options exist, can be mixed depending on your security model and operational requirements. This is a large topic. Refer to the Db2 documentation for details of CREATE ROLE and GRANT and REVOKE statements, and plan whether you will use ROLES or USERS/GROUPS or both
Related
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.
We are looking at having multiple databases in a Single Server setting on Azure Database for Postgres SQL.
Per documentation at Microsoft
Customers can manage database permissions using external (Azure AD)
groups.
Azure AD authentication uses PostgreSQL database roles to
authenticate identities at the database level
Support of token-based
authentication for applications connecting to Azure Database for
PostgreSQL
Has anyone tried doing this i.e. databaseA and databaseB with permission to ADGroupA and ADGroupB respectively, under single Azure DB server instance ? Does this give complete data isolation between the different databaseA and databaseB ?
Yes, you can use 2 separate AD groups on 2 different databases for access control on a single server. Two different users will have access to their own database.
I'm migrating an on-premise application (basically a database + a dashboard) to Azure. In my database on-premise, I had set up some access rules and RSL (Row Level Security) for different user profiles. Those were done at the level of my database which is postgres.
Now on the plateforme of Azure, I have to add an intermediare layer, Azure Analysis service between my postgres and dashboard. I want to know how to ensure my database access management & RLS with the addition of Azure Analysis service.
Do I need to replicate it in Analysis Service? Or it will still work and I do nothing with it.
Thanks
As I understand in the intial design you did not have AAS and the RLS was at the database level . Once you moved to Azure you introduced the AAS ( may be to boost performance) , to me it should work fine . We will have to think how will you refresh the data from the database to AAS and for that you may have add an user .
[there is some internal server error while creating database instance in cloud][1]
[1]:[ https://i.stack.imgur.com/I5tty.png]
Raise a support ticket with IBM.
Operational issues on commercial cloud services are not for stackoverflow.
Additionally, if you are on the "lite" plan (as suggested by your image), there is no ability to create a Database instance. Instead, you can only connect to a shared multi-tenanted database with your your account. It has a schema which is your account-name.