What are the best practices for accesses permission for programmers working in Azure DevOps? I would like the programmers to be able to use it, by for example having the possibility to create branches.
As far as I can understand by reading documents such as
https://learn.microsoft.com/en-us/azure/devops/organizations/security/set-git-tfvc-repository-permissions?view=azure-devops#git-repository
The only permission needed is a contributor? Is this correct or have I misunderstood the whole thing? The organization I’m working for have for example set the contributor to be a member of :
Build Administrators, Endpoint creators, Release Administrators
Creating users is different thing and assining rights is different thing. Your are looking for something named Policies.
Check for Branching policies in this case.
EDIT:
I was confused with the branching rights, however you can follow the Repository Permissions and Branch permissions to find how you can give permissions on your projects to users
You need to navigate to project settings and then to repositories. there you will find list of repositories and each repo can have certain rights assigned to it. some are inherited, some assigned. You can modify those to fit your likings.
this is the url: https://dev.azure.com/org_name/project_name/_settings/repositories
For more details, follow this link: https://learn.microsoft.com/en-us/azure/devops/organizations/security/set-git-tfvc-repository-permissions?view=azure-devops
thanks for you quick answer. Have digged into the documentation and repository permissions. I gave definitely som insight. My concern is that I want a predefined setting for managing the code repository on a team level, thus would no want to give project permission to the programmers. In my azure devops setup I have only on organization with hundreds of teams.
As I understand it, the permission for the repos are set at the project level. I would like to minimize the project level access since it gives to wide accesses in other cases and other teams. So my hope was that giving programmers contributor access would give the more or less all needed access for the repos out of the box. Such as:
1. Clone, fetch, contribute to pull requests, and explore the contents of a repository
2. Contribute to a repository, create branches, create tags, manage notes
Do not really understand why more access are needed. But could for example give the security control to the build admin role by granting the access to change permission. In this case the ones with build amdnin could adminitrate the security for its own team repos.
Any thoughs on this? Apologize if I have misunderstood you answer...
Related
I want to give a frontend developer rights only to pull/read from the GitLab container registry. In order to test some things in the frontend he needs also the backend container.
But I dont want to give access to the full gitlab project, so that he can clone the whole repo. I only want to give him access to pull the container from the registry (because how I understand it, he wont have the possibility to access the code then).
Is this even possible with GitLab? Seems like Container Registry access needs whole project access?
If this is not possible with GitLab it should somehow be possible with AWS Registry instead or? (Any suggestions for this usecase I would be very thankfull for.)
While GitLab's user permission scheme lacks some granularity, you might be able to workaround this limitation.
One would be to make the project publicly/internally accessible through its visibility settings. Users only need read ability in order to access the container registry. Obviously, this may not be acceptable if your images are intended to be more private/secret.
One other possible mechanism for granting access to container registry might be to create a project access token with just read_registry scope and distribute that token to your users that need to read the image registry for the project.
The same could be done with group access tokens, too. This may be useful to reduce management overhead if you have many projects with this need.
I am a Solution Architect responsible for setting up a project's infrastructure on Azure. The project should be running in multiple environments (dev, staging, prod). As far as I learned the best practice regarding environment separation in Azure is to use Resource Groups. That's what I did.
However, this is where things start getting tricky. Our application will use Azure AD as OAuth Authorization Server. I want to have my AD isolated, like everything else in my infrastructure. I don't want to accidentally modify a production user from the dev environment and for the dev environment, I want to be able to create a ton of test users which I don't want to see in production. So, isolation.
The problem is I don't see any option on how to do this. My first instinct was to create multiple ADs. But when I do that, they actually need to create a completely new tenant for each of these environments. This seems really messy to me. Have to support as many (almost empty) tenants as I want to have environments.
Please, what is the right way how to do this?
Does Azure AD have some kind of support for isolation I require?
Am I missing something?
Note: this question was also asked in MS Q&A.
You're correct that a tenant is equivalent to a directory and a user is either in the directory or it's not. However, using RBAC, you can restrict the permissions on users so that they can't access particular services. It would be good if you separated permissions by subscription which is what a lot of major companies do and that's how they know which workload a subscription handles.
Is there a way to grant permission in Gitlab so that a person or role only has access to a Wiki? No issues, no source, etc.
Not quite.
See the GitLab permissions docs.
The lowest level you can assign is Guest, which can:
Create issues
Download and browse job artifacts.
View wiki pages
But guest cannot access source code.
We're using Azure to maintain our development and QA servers.
One of the needs we have now, is to provide our QA members access to update web.config file on the server, which can be achieved via Visual Studio Server's Explorer (with the right configuration).
The problem is that you need a user with a subscription as a co-administrator within Azure (at least as far as I managed to understand), but obviously we'd like to allow our QA members only to maintain the files, with limited access via Visual Studio.
Is there any way to do it?
Following Brendan advice, I've granted the QA members FTP access. This should do the job for now, until Microsoft will come up with something better :)
Thanks Brendan!
I am trying to give a designer access to specific folders within an Azure website I have. I would like for the designer to have access via FTP. However, according to this post, having multiple FTP user accounts on the same Azure website is not possible and the accepted answer suggests coming up with a "different way to manage" the website. This means that if you want collaboration on an Azure website, you have to share the entire directory structure. Please correct me if I am wrong.
I know you can download the Publish Profile settings from Azure as seen on this post. This does not solve the issue as the publish profile simple gives you the FTP credentials for a specific website (instead of all of your Azure websites) but still does not provide the option to create new FTP users with limited directory permissions.
So, my question is: is there some way to edit the Publish Profile settings when they are downloaded so folder access is limited? If not, what methods have you used for website development collaboration on Azure where certain folders should be hidden and protected?
For collaborative work with Azure Websites, you can enable source control. This includes tfs, git, dropbox, bitbucket, and codeplex. Dropbox is not the best collaborative tool, as it's not designed to be a version control system, but it's very convenient.
If you have a repository with any of the abovementioned providers, you can now give your designer their own account with the version control system.
You guys are right about using a source control system like GitHub instead of trying to provide access by creating a second FTP user.
Others have asked this question - not in the context of azure though.
This post talks about using submodules on github to give a contractor access to a subfolder and all folders / files under that sub folder.
SO - I believe linking azure to github would be necessary and then from there, creating and managing submodules from github would allow for collaboration. I believe a required aspect of this would be to have a private repo on github for the main repo. All of the files in the repo would otherwise be available for forking which would defeat the entire purpose of maintaining some discretion on access rights in the first place.