I can create basic user and it's subusers. Is it possible to create administrator user in ceph who can access all objects and buckets from all users?
The answer is: Yes
And I know it's a tricky question. Because creating admin user is still not very straightforward.
The Ceph Storage Cluster provides an administrative API that enables users to execute administrative functions via the REST API. By default, users do NOT have access to this API. To enable a user to exercise administrative functionality, provide the user with administrative capabilities.
To add administrative capabilities to a user, execute the following:
radosgw-admin caps add --uid={uid} --caps={caps}
You can add read, write or all capabilities to users, buckets, metadata and usage (utilization). For example:
--caps="[users|buckets|metadata|usage|zone|amz-cache|info|bilog|mdlog|datalog|user-policy|oidc-provider|roles|ratelimit]=[*|read|write|read, write]"
For example:
radosgw-admin caps add --uid=johndoe --caps="users=*;buckets=*"
To remove administrative capabilities from a user, execute the following:
radosgw-admin caps rm --uid=johndoe --caps={caps}
Related
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.
Is there the possibility to limit the access to Service Fabric Explorer to certain services or specific users?
We have a scenario where we host multiple services on the same cluster. The log information of the Explorer shall be only visible for the 'owner' of each service.
No.
You can use access control to limit access to certain cluster
operations for different groups of users. This helps make the cluster
more secure. Two access control types are supported for clients that
connect to a cluster: Administrator role and User role.
Users who are assigned the Administrator role have full access to
management capabilities, including read and write capabilities. Users
who are assigned the User role, by default, have only read access to
management capabilities (for example, query capabilities). They also
can resolve applications and services.
https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-security#role-based-access-control-rbac
https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-security-roles
You can assign different roles to groups, but you cannot scope a role to a service, so basically its all or nothing, you cannot give granular control
Want to identify the users/login with Administrative access on server to migrate them to new server's. I have tried Select * from $System.TMSCHEMA_ROLE_MEMBERSHIPS but these give information regarding the particular database i need more at server level.
Ssas users are done quite differently from normal databases. Ssas uses only the active directory account of the user trying to connect.
On server level the only security is done in the properties of the server, there you can select active directory users with administrative access to the server.
On database level you can create roles, give them access to (part of a) database and link active directory users/groups to them.
Using the analysisservices namespace of microsoft you already mentioned you can look trough every role in every database and note the permissions.
As far as I know you can't actually use this namespace to see all the administrators of the user. But unless you have an unreasonable amount of administrators the best solution might be to just open the server in sql server management studio, click on properties, security and write down all the AD members manually.
I hope this helps you and good luck!
I am admin for our AWS environment, and wanted to use PowerShell, but I get these errors whenever I try to do anything
Get-EC2Region : You are not authorized to perform this operation.
or
Get-CSDomain : User: arn:aws:iam::123456789012:user/Jane.Doe is not authorized to perform: cloudsearch:DescribeDomains on resource: arn:aws:cloudsearch:eu-west-1:123456789012:domain/*
In my personal AWS account, everything works fine. We had a look at our policies, and us four admins can all do everything using the webconsole.
I have regenerated my access keys just in case that might be it, but there was no change.
So I guess my questions is:Do we need to implement some CLI specific policies to allow access via PowerShell?
You need to make sure the user you are using the correct AWS user credentials and the correct IAM policy to allow the given user to do the operation.
There are no CLI specific policies to PowerShell. The user simply has not been granted those permissions.
A good test would be to grant the user ec2:* and cloudsearch:* and confirm. then you can tighten down the permissions, having confirmed that the user can be successfully given a more permissive set of permissions.
I want to get details of Azure Subscription of my client. But I do not want to ask for special permission from client.
What I need is the bare minimum things from my client so that I can login from powershell or rest api and read status of runbook jobs.
If i login from admin account of the subscription than I can easily get those details. But you understand it is not possible to have admin account credential of my client.
Please suggest some workaround.
What you need to do is create a user in Azure Active Directory and grant that user specific rights using either the Azure Portal or PowerShell\Cli\SDK.
Say read all, or read properties of desired automation account. If you would want like a super minumim, you would need to create a custom role first.
https://azure.microsoft.com/en-us/documentation/articles/role-based-access-control-custom-roles/
If your client placed specific resources within a Resource Group, they may grant you permissions on just that Resource Group (including read-only permissions). This would allow you to have access to needed resources, without having access to other areas of their subscription.