You can see Table A of permissions in GCP's IAM and Administration > IAM page.
Table A has an item called Analyzed Permissions (Extra / Total).
You can see more detailed Table B for that role by clicking on a value such as 2/4 of this item.
Normally this is fine, but the information in Table B appears to be inverted when all permissions for a role are extra or when there are no extra permissions. Is this a bug? Or is it my misunderstanding?
(I use the GCP management screen in the Japanese version, so it may not be reproduced in the English version.)
The explanation may be difficult to understand because it is abstract, so I will give a concrete example.
Suppose the role "Write Log" for a service account is listed as 0/1 in Table A.
This indicates that "Write Log" has no extra permissions (all permissions "Write Log" for that role have been used in the last 90 days).
However, all permissions are displayed in the "Extra Permissions" column on Table B, which is inconsistent (inverted) with Table A.
Conversely, if the permissions for a role look like 6/6 in Table A, it means that none of the permissions for that role are used,
If you open Table B for such a role, it will be treated as if there is no "extra permissions" field and everything is in use (inverted to Table A).
However, roles that are used halfway, such as 3/7 in Table A, are displayed correctly in Table B.
screen shot:
IAM recommender analyse the usage of permission over the last 90 days. It shows X/Y where X is the number of unused permission, and Y the total number of permissions granted.
If there is X=0, the table B show you only the current used permission, not the ununsed, because they aren't
If there is X=Y, the column for the "currently use permission" is empty and all the existing permissions are in the unused column
If there is X>0 adn X<Y, the table B show a mix between the list of currently used permission, and the unused.
If you have a light bulb, it's because IAM recommander has found better roles, and you have propositions to increase your security.
Related
I'm pretty new to the cost explorer and looking at this scenario:
There's a root(organization) account which has multiple linked accounts like this:
Root Account
- Account B
- Account C
- ...
When I filter a specific Account (AccountB) from the Root account, I see a cost discrepancy comparing to the view from AccountB itself.
here's the image to demonstrate the issue better :
Root account view, filtered by Linked AccountB:
View from AccountB itself:
Any idea/suggestions why I see this discrepancy ? (anything else I need to do to get the same cost for AccountB and root->AccountB ?)
So Saving plans are actually shown in both views, but EDP and Private Rate card discounts are only shown on the root account.
It is my first expirience in Google Cloud Platform and I'm confused.
I've got an access to a resource:
xxx#gmail.com has granted you the following roles for resource resource_name(projects/project_name/datasets/ClientsExport/tables/resource_name) BigQuery Data Editor
But if I open BigQuery Data Editor, I don't see project_name and resource_name. Search by resource_name also returns no result.
Is it only access that I have in the project (I didn't get another accesses and mails).
Could you please help me with this? Maybe should I get some additional access to resource_name will be available? If is there another way to find the resource?
Thank you in advance!
In the message you have access to BigQuery data inside a table. You can query them from your project, you are autorised to access them (and to write also, because you are editor).
However, this table isn't in your project, it's in another project that's why you don't see it directly in the BigQuery console. In addition, you haven't the right to read the metadata (roles/bigquery.metadataViewer) on the dataset of the other project. Eventually, you can't also view the table schema in the console, but the bq CLI allow you to view it.
I had some discussions with Google BigQuery team about that (because I got the same issue in my company), and updates should happen by the end of the year (or soon in 2022) to fix this "view" issue in the console.
It looks like you have IAM permission to access a specific resource in BigQuery but cannot access it from the GUI.
Some reasons you may not see access on your GUI:
You have permission to interact with BigQuery but don't have access to any of the data.
You aren't a member of the organization which provided the resources and they have higher level permissions (on the org level) which prevents sharing of resources outside of the org.
Your access is restricted to the command line/app level. (If your account is a service account then this is likely the case.)
I have an AWS Amplify application that has a structure with multi-organizations:
Organization A -> Content of Organization A
Organization B -> Content of Organization B
Let's say we have the user Alice, Alice belongs to both organizations, however, she has different roles in each one, on organization A Alice is an administrator and has more privileges (i.e: can delete content or modify other's content), while on Organization B she is a regular user.
For this reason I cannot simply set regular groups on Amplify (Cognito), because some users, like Alice, can belong to different groups on different organizations.
One solution that I thought was having a group for each combination of organization and role.
i.e: OrganizationA__ADMIN, OrganizationB__USER, etc
So I could restrict the access on the schema using a group auth directive on the Content model:
{allow: group, groupsField: "group", operations: [update]},
The content would have a group field with a value: OrganizationA__ADMIN
Then I could add the user to the group using the Admin Queries API
However, it doesn't seem to be possible to add a user to a group dynamically, I'd have to manually create each group every time a new organization is created, which pretty much kills my idea.
Any other idea on how I can achieve the result I'm aiming for?
I know that I can add the restriction on code, but this is less safe, and I'd rather to have this constraint on the database layer.
Look into generating additional claims in you pre-token-generation handler
Basically you can create an attribute that includes organization role mapping
e.g.
{
// ...
"custom:orgmapping": "OrgA:User,OrgB:Admin"
}
then transform them in your pre-token-generation handler into "pseudo" groups that don't actually exist in the pool.
I'm developing a huge application in django and I need a permission system and I assume that the native user/group permission within django is not sufficient. Here my needs:
The application will be available through multiple departments. In each department there will be nearly the same actions. But maybe an user will be allowed to add a new team member in department A and in department B he is only allowed to view the team list and in the other departments he has no access at all.
I though using a RBAC system would be most appropriate. Roles must also be inheritable, stored in a model an managable through an interface. Any good ideas or suggestions? Regards
What you are looking for is called abac aka Attribute-Based Access Control. It's an evolution of RBAC as an access control model. In RBAC, you define access control in terms of roles, groups, and potentially permissions. You then have to write code within your application to make sense of the roles and groups. This is called identity-centric access control.
In ABAC, there are 2 new elements:
attributes which are a generalization of groups and roles. Attributes are a key-value pair that can describe anyone and anything. For instance, department, member, and action are all attributes.
policies tie attributes together to determine whether access should be granted or denied. Policies are a human-friendly way of expressing authorization. Rather than write custom code in your app, you write a policy that can be centrally managed and reused across apps, databases and APIs.
There are a couple of ABAC languages such as xacml and alfa. Using ALFA, I could write the following policy:
A user will be allowed to add a new team member in department A
In department B he is only allowed to view the team list
In the other departments he has no access at all.
Roles must also be inheritable, stored in a model an managable through an interface.
policyset appAccess{
apply firstApplicable
policy members{
target clause object = "member"
apply firstApplicable
/**
* A user can add a member to a department if they are a manager and if they are assigned to that department.
*/
rule addMember{
target clause role == "manager" and action == "add"
permit
condition user.department == target.department
}
}
}
One of the key benefits of ABAC is that you can develop as many policies as you like, audit them, share them, and not have to touch your application code at all because you end up externalizing authorization.
There are several engines / projects that implement ABAC such as:
AuthZForce (a Java library for XACML authorization)
Axiomatics Policy Server (commercial product - disclaimer: I work there)
AT&T XACML
There are two components to this question:
First, role management. Roles can be achieved through group membership, i.e. departmentA_addMember & departmentB_listMembers. These Groups would have corresponding permissions attached, e.g. "Member | Add" and "Member | View". A department in this context may have more resources included, that require separate permissions. Django allows to extend Objects with custom Permissions.
Second, inheritance. Do I understand you want to have individual Groups being member of other groups? Then this is something Django would require you to implement yourself.
However, should you be looking for a really more complex authentication solution, it may be worthwhile to integrate with 3rd party services through, e.g. django-allauth. There are sure more/other solutions, just to throw in one name.
A user story has an Owner and Assignments. Trying to figure out the best use of Owners, Assignments and Roles.
When you create an entity, your user becomes listed as Owner. Any item can have only one owner at a time.
An owner can always edit and delete his items, even if his role doesn't have edit or delete permissions for this type of items. This allows every person to edit or delete items they created by mistake.
Not everybody can change owner for an item; there is a special role permission 'can change owner' in the roles settings. If you don't have such permission (even with Add/Edit/Delete permissions) you still won't be able to change the ownership.
Each entity can have unlimited amount of people assigned to it. Usually you assign a person to an entity, if this person is going to work on it.
Any user can always change the state of the items he's assigned to, even if his role doesn't have edit permissions for this type of items. This allows every person to mark their share of work as completed.
Role indicates what kind of work this person will perform (development \ analysis \ testing \ etc.). A set of available roles can be customized as described at https://guide.targetprocess.com/settings/how-to-customize-assignments-area.html
Role also affect what you'll see in your ToDo list: https://guide.targetprocess.com/filters/filters-for-personal-todo-list.html