create repository R1
create Repository Admin Privileges Priv_1 (repository name = R1)
Actions : create,add,browse
create Role Role1 with Priv_1
create adminR1 witj role Role1
but when i started Nexus under adminR1 i see only Welcome but not Browse, not Upload
p.s. it seems to me that only admin has permitions to upload something to ANY repository
Related
TLDR -
I want users of my employer's organization who install my CLI tool to be able to use it to run commands that use the GitHub rest api that require permissions the user doesn't personally have, while restricting the user from using the CLI tool to perform unintended actions with the elevated permissions needed by the CLI tool. Is there a way to create a CLI tool that 1. uses permissions the users of the CLI tool don't have while at the same time 2. prevents those users from using the CLI tool's elevated permissions to perform unintended actions?
Extended -
I'm building a CLI tool for my employer's organization so that the organization members can automatically create a new branch and simultaneously add branch protection and create a PR. As far as I know, updating branch protection with the GitHub API requires admin access. However, not all of the users who use this CLI tool will personally have those permissions for their user account. But a user in the organization should still be able to use the CLI tool (which uses permissions the user potentially doesn't have).
I thought about using a personal access token so that the users aren't using a single set of centralized credentials (github app creds), but then the CLI tool would have access to at least one of the user's personal repositories and potentially wouldn't have the required permissions required by the CLI tool.
So is there a way to build a tool as a package that can be installed on a users machine that...
has permissions that the user of the tool potentially doesn't have and
prevents the user from doing anything unintended. e.g. the tool (which has admin permissions) can add branch protection rules, but the user shouldn't be able to use the tool's elevated permissions for anything else - e.g. getting the interaction limits for an organization
prevents the user from using the tool in any organization repo they don't have access to.
Ok, that's the gist of it, but I will go into more detail in case that helps.
So currently I'm using a GitHub app and giving it the required permissions (e.g. admin read/write for branch protection rules). I'm using octokit to authenticate to the GitHub API with the GitHub App. To do this, I'm passing in the app id, private key, and the installation id.
package structure
- .env
- authenticate_and_do_stuff.ts
authenticate_and_do_stuff.ts
// authenticate with GitHub app creds
// see https://github.com/octokit/octokit.js#authentication
const octokit = new Octokit({
authStrategy: createAppAuth,
auth: {
appId: process.env.GITHUB_APP_APP_ID,
privateKey: process.env.GITHUB_APP_PRIVATE_KEY,
installationId: process.env.GITHUB_APP_INSTALLATION_ID,
},
});
// create branch, add branch protection, etc.
octokit.rest.do stuff ...
This isn't ideal because then the user who installs the package needs those environment variables to be authenticated. And once they have those creds, they would be able to use them to do other things they potentially don't have permissions for (e.g. with the admin read/write permission the GitHub app has permissions for). So my thought is to have the user provide the authentication credentials that aren't the Github app credentials. This way, each user is using different credentials they provide. As for the reasons stated above, personal access tokens cannot be used. So the ideal situation is as follows -
A user installs the package - npm i my-github-cli-tool.
- node_modules
|
--- my-github-cli-tool
|
--- authenticate_and_do_stuff.ts
|
- some_custom_app_file.ts
- .env.cli_tool
They generate credentials and put them into a custom env file e.g. .env.cli_tool.
They use the CLI tool to create a new branch in an organization repo they have access to, create the branch protection rules (with the admin read/write access that the user doesn't have, but the credentials in step 2 has).
If the user tries to alter the cli tool or use the credentials in step 2 to use it to access repos they don't have access to or perform other actions with the admin read/write permissions, they shouldn't be able to.
If I stick with using the GitHub app, the source code on the user's machine has to get the credentials somehow. And those credentials need to have elevated permissions that the user might not have. So if these credentials are exposed to the source code on the user's machine, doesn't that mean the user can just grab those credentials and use them for nefarious purposes?
We have lighthouse configured and I am trying to extract azure aks RBAC permissions information for a managing subscription from a managed tenant:
Get-AzRoleAssignment -scope "/subscriptions/0000000-0000-0000-00000000000000/resourcegroups/testrg/providers/Microsoft.ContainerService/managedClusters/testakscluster
Can we extract role assignments for a managing tenant's subscription while logged in a managed tenant cloud shell?
Thanks for your help
When using the Get-AzRoleAssignment command, it will call the Azure AD Graph - getObjectsByObjectIds meanwhile to validate the objects in Azure AD.
To solve the issue, make sure your user account logged in the cloud shell has permission to call the API, if your user account type is member, it will has the permission by default. So I suppose your user account is a guest, if so, there are two ways.
1.Navigate to the Azure Active Directory in the portal -> User settings -> click Manage external collaboration settings -> select the first option like below.
2.Navigate to the Azure Active Directory in the portal -> Roles and administrators -> search for Directory readers -> click it -> Add assignments -> add your user account as a Directory readers role.
Just select any of the options above, then the command will work fine.
For anyone coming to this thread after some searching: I had the same issue with this call across multiple versions of the AZ.Resources module: 2.5.0, 4.1.0 an 5.6.0. All my rights where setup correctly, both for an SPN and a user, both got the same error.
Changing the call to use the Azure CLI and that just works 😠.
az role assignment list -g [resource group name]
Trying to put together an Azure ARM integration, where my code uses the Azure API to retrieve the full list of VMs in the entire subscription.
Went successfully through all the (many!) steps here to get an API user ready with all relevant IDs needed for authentication.
Using the same set of instructions, we were also able to grant this user the Reader role, for listing VMs in specific groups (we did this through the Azure UI). However, we have been unsuccessful in implementing the instructions here for setting up Reader role for this user to the entire subscription (through the CLI).
Running this:
azure role assignment create --objectId app-oid --roleName Reader --scope /subscriptions/subscription-id
Or this:
azure role assignment create --objectId app-oid --roleName Reader --subscription subscription-id --scope /subscriptions/subscription-id
Yields this:
Principals of type Application cannot validly be used in role assignments.
So currently we have no way of programmatically browsing the full set of VMs without adding a specific authorization for each Resource Group.
Does anybody know of a way that actually works to assign this permission at the subscription level?
Found the answer in the comment area of the link in the question body:
In the new portal, edit the subscription and add the role, just like you would do with a resource group. Still curious as to why the CLI doesn't support this.
The steps to use the Azure CLI to create and authorize a service principal are documents here: https://azure.microsoft.com/en-us/documentation/articles/resource-group-authenticate-service-principal-cli/
Instead of using --objectId app-oid try using -ServicePrincipalName <appId>
https://github.com/Azure/azure-powershell/issues/4776
Had the same error for role assignment with terraform
Principals of type Application cannot validly be used in role assignments.
But as described here, using the Object Id that is displayed on the overview page of the app registration in the Azure portal resulting the above error.
The solution is to get the Object Id from azure cli:
az ad sp show --id [Application (client) Id] -o json | grep objectId
# and then using this objectId assign your role
az role assignment create --role contributor —-assignee-object-id [object id] —-resource-group [MyResourceGroup]
I'm using Liferay Portal Community Edition 6.2 CE GA3 and the Documents and Media portlet. I created several roles in Liferay, one named "Documents-Admin". What I want is that a user with this role is able to create folders and files etc. and can change the permissions of these so that only specific users/roles have access to them.
So I changed the permissions for this role under Control Panel -> Users -> Roles and granted everything in Site-Administration -> Applications -> Documents and Media.
With this setting, a user with this role is able to open the permissions configurations of folders (even when he's not the owner). But the table only shows the roles "Users" and "Documents-Admin" - but there are 30 more. What do I have to do to see the full list of roles?
In control panel > Roles
Click on Documents-Admin role which you created and select define permissions.
And in that for Role you try giving view permissions or try giving there different permissions.
I am having a problem with granting proper privileges to a server level role that I created. Whenever a user from the role tries to grant permition to other user I am getting an error like in the title. I did some research and add with grant option when I grant role priveleges but that not helped. I want to keep my role priveleges as low as it must be to perform the given script.
Here is how I create my role
CREATE SERVER ROLE [My_Server_Role]
go
GRANT ALTER ANY LOGIN
,ALTER ANY SERVER ROLE
,CONNECT SQL
TO [My_Server_Role]
WITH GRANT OPTION
go
now I have a user created like this (and a second one the same way)
CREATE LOGIN JohnSmith
WITH PASSWORD = 'MyPassword'
CREATE USER JohnSmith
FOR LOGIN JohnSmith
EXEC sp_addsrvrolemember [My_Server_Role], [JohnSmith]
Now, my problem is that whenever JohmSmith tries to execute
DENY CONNECT SQL TO [ThatOtherUser]
I have read to add WITH GRANT OPTIONS to CREATE ROLES statements but it didn't help. I can add CONTROL SERVER to MyServerRole but then users are getting too high privileges and are able co control other databases
Can anyone help? Perhaps i am messing something up with the idea. My point is to grant user (roles) priveleges to one database only plus I do not want to use build in server and database roles
You have two solutions for this:
1) Define the AUTHORIZATION for the role (See here)
CREATE SERVER ROLE role_name [ AUTHORIZATION server_principal ]
role_name
Is the name of the server role to be created.
AUTHORIZATION server_principal
Is the login that will own the new server role. If no login is specified, the server role will be owned by the login that executes CREATE SERVER ROLE.
The server principal will be able to grant the role.
2) Use CONTROL ON ROLE
You can add it within the list of the GRANTed permissions. Look at the Database role permissions section in this document:
From DENY server permissions:
Requires CONTROL SERVER permission or ownership of the securable. If you use the AS clause, the specified principal must own the securable on which permissions are being denied.
So, it would seem that because your server role doesn't have CONTROL SERVER, they can't deny connect themselves.