My team is attempting to move towards templatization of our services and their infrastructure.
We have found it to be extremely time-consuming to determine the set of permissions required to execute or update a given Cloudformation template. Our process is:
Create a user with permissions cloudformation:CreateStack and/or cloudformation:UpdateStack
Have that user attempt to create/update the specified stack
Observe which missing permission caused the stack operation to fail
Add that permission to the user
Go to 2.
The alternative to this would be to create a "God User" who has unlimited permissions and have that user execute the create/update - which seems to violate the Principle Of Least Privilege
Alternatively, is there a tool that can list "what permissions have been exercised by a given user in the past N minutes?". If such a tool existed, we could create the "God User", have them execute the template, and then create a more limited-scope user that has precisely the permissions that the God User had used.
There is no simple way/tool to do this.
Here are a couple of approaches you can try-
Using an User that has Admin priviledges, create the Stack. Once done, wait for 15-20 minutes for CloudTrail to populate. Now in CloudTrail list the API calls made by the 'Event Source' - 'cloudformation.amazonaws.com'. That should be roughly all the API calls required. There can be a few more calls required, for other operations as you keep on adding functionalities to the Resources. Again, you would need to figure that out this way.
Create a CFN service role , and add admin privileges to this Role. Use this Role to create/update/delete the Stacks. Allow the IAM users only iam:PassRole and cloudformation:* . However, users will be able to create different resources using CFN.
Use Service Catalog and create Products. Service Catalog Products are CFN Templates which can be launched by a specific user/Role/Group. The user does not need permission to create/modify the Resources in a Stack/Product. Also the end user cannot change the Product to add more Resources. Here's a great video that explains this stuff : https://www.youtube.com/watch?v=A9kKy6WhqVA
Hope this helps...
Related
I'm quite new to the entire auth design and am still trying to understand how to use keycloak for authentication and authorisation.
Currently from what I understand in order to have authorisation enabled for a client you will need to have it in confidential.
After which I am kind of stuck in terms of how to set which policy for which permission.
I have a few types resources but currently placing them all under a single client for simplicity sake.
For my use case I have a workspace for users. So each workspace can have multiple users with different roles of owner,editor,viewer. And within the workspace there are artifacts. So it is some what like designing an authorisation for Google drive.
Would like some advice on how best to design it.
One way I have thought of is using groups and each workspace is a group. Using it to assign users to each group as a way to use the group policy for permission.
The other is really by creating multiple policy and permission for each artifact/resource and adding user to each policy for each workspace.
Would like any advice on authorisation design or even where to begin reading.
After some research I have come to these conclusion.
Yes these can be done by keycloak though most likely shouldn't be done in keycloak itself for its design.
Keycloak itself will most likely be more suitable in terms of authenticating/authorising on services or infra level. So this use case of having user be able to access workspaces or artifacts will be better done in application level having a separated service to handle the permission itself.
That being said if it really needs to be done in keycloak the design that I thought of that is not so scalable is as follow.
Create a policy/user and each workspace/artifact as a single resource. Depending on how many types of access/fine grain control is needed for each type of resource create the scope for each (e.g workspace:view, workspace:edit...). Then create a permission for each resource&scope. This allows fine grain access of basically assigning user to permission of each resource through the user policy.
But of course this design has its flaws of the need of too many policies, permissions and resources so it is better to have keycloak just handle the authentication part and authorisation is just giving users the role to be able to access a service and through the service check if the user is authorised for a certain action.
I have developed a pretty standard and common authorization permission system for an internal business web application.
There are some roles with permission sets; system administrator can create new roles and assign permissions to them; every web controller method has an attribute to check for specific permission. So far so good.
But then I have the following conversation with the customer:
Customer: "Please, make it possible to hide specific form fields in specific forms for a specific role".
I: "Ok, so the users of this role shouldn't have permissions to modify these fields, right? I can also add a permission check to the method that saves the data."
Customer: "No, no, it's not a permission issue as such, it's just about convenience - this role doesn't need to work with these fields and we want to make the UI less cluttered. The users of this role shouldn't see these fields in this form only; however, there are other forms where it's totally OK to see these fields. Of course, we might later create new roles that will need to see these fields in this form, but by default the fields should be hidden."
And so the permission system gets cluttered with "pseudo-permissions", such as "See field X in form Y". They exist for UI convenience purposes only and have nothing to do with authorization for performing activities on data.
Is it a good practice to control UI through roles & permissions, even when the specific permission has nothing to do with data processing authorization? Is there a clean solution to avoid cluttering the permission system implementation with such UI-only pseudo-permissions and still provide the customer with granular control to achieve cleaner UI for specific roles?
I have a question regarding Cumulocity. I want to create a site hierarchy in Cumulocity, we can go up to sub-tenant level only but I want to create a hierarchy up to 2 level.
Let's take an example of schools, its locations, and different branches. Here I want to attach an owner with each branch and that owner should be able to register only their own users and devices. I was trying to achieve it using groups, roles etc but was not able to do it. If anyone can suggest how to proceed for this use case.
I can see two possible options using which this can be tried:
Groups
Custom Apps (Angular apps)
But I am not sure how to proceed as there is no direct UI for the user to group assignment and REST API for this assignment is giving me errors.
You can use the inventory permissions for configuring access rights that are limited to a certain group see documentation
The managing of only your own users can be achieved by giving a user the global permission for USER_MANAGEMENT_CREATE. Make sure to revoke the ADMIN and READ role as well.
I would not recommend to solve this with apps on the UI side. That way you can of course hide information from the user but he may still be access it via API. Only with the RBAC you can really ensure on API level that the access is managed correctly.
I have an open source project with several contributors. The project's home page is hosted on Amazon S3. At the moment, the S3 bucket is on my personal account. Only I have access to it, and I pay the hosting (~$5 a month). There are other personal buckets on my account that contributors should not have access to.
I'd like to allow other contributors to modify the site. I'd also like to enable e.g. TravisCI to deploy to the site, which requires extending some credentials to third parties.
Is it necessary to set up a separate Amazon account entirely, or is IAM sufficient for my needs?
If IAM is the way to go, should there be a single IAM user shared among all contributors, or should I create a separate one for each contributor?
Do I need MFA? If so, how to safely distribute TOTP keys?
Any provisions I should make for succession (i.e. bus factor)?
Anything else I should know?
Thanks for any ideas or experiences here.
Is it necessary to set up a separate Amazon account entirely, or is IAM sufficient for my needs?
You should probably have an account for this project that is separate from any accounts you use for purposes unrelated to this project, for clean separation and in case you want to hand over control. What isn't in the account doesn't need to be protected from users who shouldn't see it.
Cross-account privileges are possible, so if others already have accounts, it's possible for you to authorize their existing credentials without knowing their secrets, but it's more complex.
If IAM is the way to go, should there be a single IAM user shared among all contributors, or should I create a separate one for each contributor?
You should absolutely create one for each contributor. That's kind of a no-brainer. Accountability.
Do I need MFA? If so, how to safely distribute TOTP keys?
It depends on your need for the added security. MFA is great and it's also a hassle. But you don't have to (and shouldn't) distribute the MFA secrets for virtual MFA. The user can log in with his/her credentials and create and download that themselves if you allow it.
Any provisions I should make for succession (i.e. bus factor)?
Heh, bus factor. Yes, you probably need a trusted adjutant with a high privilege level. In my accounts we don't actually use the root credentials, ever, but typically two people have a physical copy of the root credentials, though we do sometimes ride together in the same elevator, and we really shouldn't do that.
Anything else I should know?
Read the documentation. It takes a bit of time to sink in, but it takes less time if you get your hands dirty and play with it. Be sure when granting privileges that you verify that things which should not work do indeed not work, not just verify that things which should work indeed do work. But that applies to any authentication and authorization implementation.
Use IAM instance roles in EC2. Even if you can't think of a reason why an instance needs a role, give it one with no permissions anyway, because an instance can only be given a role at launch... yet Formerly, you could only add an IAM role to an instance at launch, but AWS announced on 2017-02-09 that you can now attach an IAM role to an instance after launch. As always, you can change the permissions granted to a role at any time.
Read about user groups. Attach users to groups and policies to groups to simplify granting the same privileges to multiple users.
Unrelated: activate billing alerts for your account to notify you when costs exceed thresholds you select.
I am developing a POC (SahrePoint 2010) where I can demonstrate that the users can be granted certain permissions on a list for a Date range (for example contribute access for a selected week). I will be breaking permission inheritance and create unique permissions for a list.
I would like the permissions to be revoked automatically after the expiry date. Also, I would like to do this using the Manage Permissions list (_layouts/user.aspx) so that I don't have to maintain a separate list.
I have a couple of questions regarding this:
1. I assume that the custom permissions for any list must be stored n some list. How can get to know in which list the permissions are getting stored?
2. If at all I get to know in which list the permissions are getting stored, will I be able to add columns to that particular list?
I hope that the question is clear.
Permissions are not stored in any list. Rather, every securable object (including sites, lists, folders, and items) has a Role Assignments property that indicates what groups/users currently have access, and what their permissions are (if not inherited).
See the SPRoleAssignment class documentation for more information.
Note that the User Information list is not a "Manage Permissions" list; it stores profile information about users who access the site, but does not store any permission-related information. Further, it's not a typical list at all, in that it does not show up in the SPWeb.Lists collection for a subsite, and its fields are automatically populated by SharePoint's User Profile Service. While you could potentially add more columns to it, you'd be better off using a separate list to store and track your permission information instead of contaminating the site collection user info list.
To have permission changes take place based on an expiry date, you'll need to implement a time-based solution that runs on a regular basis to see if any changes need to be made, such as a custom timer job, a custom site workflow that runs on a schedule, or a Windows scheduled task.