Can we assign role based access control (RBAC) rules to control which users can access and run which pipelines?
RBAC for JFrog Pipelines is integrated with JFrog Access. Pipelines sources can be attached with various permissions to allow admins to control access.
Refer documentation here
Related
we use a devops artifact feed to store our packed/shaded java binaries inside a private project. Now we would like to allow access to certain artifacts for externals.
We will promote these artifacts to a custom view (#public-releases) and want to allow access to this view for certain customers only (s.t. they can use it in their automation).
Is it possible to have some kind of service-account/service-principal to assign read-permissions in devops?
I know it the other way round (give devops access to azure ressources via service connections), but now I want to permit access to Devops Feeds.
How would I create such a User? We have azure AD connected, so maybe that is an option?
Is it possible to have some kind of service-account/service-principal
to assign read-permissions in devops?
No, no such design.
Service principal of Azure Active Directory concept can not be managed as an account in DevOps side(DevOps doesn't have such account type, only internal service principal, no AAD service principal).
As you know, service principal of AAD can manage access to services in azure portal. This is the usual usage. Another usage is Authenticate with Azure Active Directory (Azure AD) tokens, this approach can be used to manage PAT of DevOps, but anyway you end up needing to access the feed based on a legitimate account under the DevOps concept.
We've been told by Microsoft support that Azure DevOps Services supports tenant restrictions. While we have tenant restrictions enabled on a number of other services, it does't seem to apply to DevOps. Not only can we still log in to organizations outside of our tenant, we can also log in to our own organization and, if our corp email is added as a user in that org, the organization also shows up. I'd expect that our users would be blocked from logging into or accessing any external orgs.
I'm a little confused about why this isn't just working as expected and despite them saying Azure DevOps Services supports tenant restrictions, I'm not finding much documentation to back that up.
Have you been able to migrate to Azure DevOps Services and ensure that your users are only able to access orgs within your own tenant? How?
Azure DevOps Service supports the Azure Active Directory (Azure AD) tenant policy to restrict users from creating an organization in Azure DevOps. This policy is turned off, by default. You must be an Azure DevOps Administrator in Azure AD to manage this policy.
Check following link for more details:
https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/azure-ad-tenant-policy-restrict-org-creation?view=azure-devops
Notice:
This policy is supported only for company owned (Azure Active
Directory) organizations. Users creating organization using their
personal account (MSA or GitHub) have no restrictions.
https://devblogs.microsoft.com/devops/policy-support-to-restrict-creating-new-azure-devops-organizations/
We finally received a more concrete answer to this question from Premier Support. Sounds like this wasn't entirely clear internally either. Azure DevOps Services supports TRv1 which provides tenant restrictions from client to proxy, but does not support TRv2 tenant restrictions which provides server to server restrictions. TRv1 will prevent you from authenticating against an org outside your tenant directly but does nothing to prevent the background authentication that happens if your account is configured to be able to access a secondary tenant's org. The server to server connection strips off the header information necessary to restrict you from accessing the secondary tenant. While this feature may be on their radar there is no expectation or firm timeline for it's release at this time.
Is there a way to require that Azure Functions be updated through an Azure pipeline, and not someone using the VSCode integration or azure functions core tools CLI?
I don't believe that there is a direct way to restrict deployment by method (AZ CLI, Az Powershell, Azure DevOps, Azure Portal, etc.), as ultimately most everything in Azure goes through REST APIs, ARM templates, etc.
What you can do is to organize your functions into a resource group or groups, to which you limit Contributor/Administrator/Owner access to the service principal associated with your Azure DevOps service connections. Allow other users the ability to read/inspect resources in that group, but only allow the service principal the right to create objects there. You may also need to allow the managed identities greater privileges to operate within that space, but the concept remains the same - limit the autonomy of interactive users in the space where your Azure Functions live.
In my project, I want to create a few AzureRM service connections with different levels of access. I want to allow only certain pipelines to use the service connections. And I am aiming to use API or az devops extension to do this. Portal already allows to choose which pipelines are allowed to use the service connection through service connection security settings.
So far I was able to find the relevant permission in the ServiceEndpoints namespace
Name Permission Description Permission Bit
Use Use Service Connection 1
However, I do not know how to grant the permission to the pipeline. I think i should use 'az devops security permission update' from the extension however can not figure what the subject should be in case of a pipeline. Looking at the output of 'az pipelines build definition show' i do not see any unique identifier for a pipeline and documentation for security permission update says subject should be a user of group.
If i want to use the API, i will need to know how to create the descriptor to pass to Set Access Control Lists.
Any hint is appreciated.
Grant permission to pipeline to use a service connection
According to the document az devops security permission, we could use az devops security permission update to update the azure devops security permission:
az devops security permission update --id
--subject
--token
[--allow-bit]
[--deny-bit]
[--detect {false, true}]
[--merge {false, true}]
[--org]
however can not figure what the subject should be in case of a
pipeline.
As the statement for the Parameters, we could to know:
--subject
User Email ID or Group descriptor.
So, if we update the permission to given user, we just need provide the User Email in above command. If we want to update the permission to given group, we need to provide the Group descriptor.
To get the Group descriptor, we could use the az devops security group list.
You could check this thread for some details.
I have a pipeline with the following:
resources:
repositories:
- repository: repo
type: git
name: TEST-staging
steps:
- checkout: repo
When the pipeline runs I get this warning:
This pipeline needs permission to access a resource before this run can continue
Which prompts me to grant access:
Granting permission here will permit the use of Repository 'TEST-staging' for all waiting and future runs of this pipeline.
I would like to be able to audit and modify which pipelines have access to which repos. Where are those permissions listed?
EDIT: User is prompted to permit access when the pipeline names the repo e.g. - checkout: repo however, user is NOT prompted to permit access when using -checkout: self even though it's the same repo.
EDIT: The organization settings for Limit job authorization scope to current project for non-release pipelines and Limit job authorization scope to referenced Azure DevOps repositories are currently and have always been disabled.
EDIT: This FAQ question is similar to my question: Why am I am prompted to authorize resources the first time I try to check out a different repository?. That FAQ leads to this documentation: Troubleshooting authorization for a YAML pipeline. That documentation contains:
When you create a pipeline for the first time, all the resources that
are referenced in the YAML file are automatically authorized for use
by the pipeline, provided that you are a member of the User role
for that resource. So, resources that are referenced in the YAML file
at pipeline creation time are automatically authorized. When you
make changes to the YAML file and add additional resources ... then
the build fails with a resource authorization error ... In this case,
you will see an option to authorize the resources on the failed build.
If you are a member of the User role for the resource, you can select
this option. Once the resources are authorized, you can start a new
build.
EDIT: This seems to be the work item for the change that is causing us to be prompted to permit access.
So, I am being lead to these conclusions:
#Leo had the correct answer to the question "Where are those permissions listed?" except when a YAML resource is added to an existing pipeline
When YAML resources are modified or edited, the user is prompted to authorize that access even when that access is already authorized via the user's role
I have re-titled this post in the hopes that it more clearly asks the question, because as of now there does not seem to be any place in which ad-hoc authorizations are listed
I would like to be able to audit and modify which pipelines have access to which repos. Where are those permissions listed?
According to the document Pipeline permissions and security roles, we could to know:
For permissions, you grant or restrict permissions by setting the
permission state to Allow or Deny, either for a security group or an
individual user. For a role, you add a user or group to the role.
Therefore, the permission of the pipeline is associated with the user executing the pipeline.
To be able to audit and modify which pipelines have access to which repos, we could use a higher authority account to give the current user permission to access the TEST-staging repo:
Organization Settings->Users->select the current user->Three dots->Manager User:
If the current user has permission to directly access the repo, then when this user executes the pipeline, the pipeline will have the permission to access the resource repo.