I'm managing a project running in the google cloud and have a team working on it. The team-members are organized in a google group, that has the permission to edit the project. Each team-member can start instances, create container-engine cluster, etc. but it's not possible to create datastore entities.
When I add the team-member directly as editor to the project (not via the google group), he is able to create datastore entities. But I like managing members via the google group, because I can give selected team-members the permission to add team-members without giving them the owner-role of the project.
Is there anything I missed? Or is it just not possible to give project editors added via google group the permission to create entities in the datastore?
Related
I building a new course-like web application. There will be plenty of images, video and sound files.
I am wondering about possible strategies for static file management between app environments.
My current approach is to use SQL database to store image urls, which will be uploaded via admin panel on the website. The images are to be stored in a blob-like storage (AWS S3 bucket).
This however, when doing changes, requires to upload the image to each environment or create a data migration dev -> staging -> prod in a deployment pipeline.
Am I missing something here? Even if I store files in a single place (single storage account) for all environments, I still need to migrate the database records when making changes to the course.
Should I just apply the changes in prod and create some basic migration data for dev/uat course testing?.
To emphasize, files will only be uploaded by an admin, not by a user. For example, admin uploads the image via admin panel and the image will be automatically included in the course.
I am not sure what's the appropriate way of doing this to manage and test changes properly. If I allow to do this on prod directly without migration, then I'm running the risk of uploading something invalid into the course with untested changes. On the other hand , I am not sure if it's common to migrate SQL data between databases and it will also have it's own pitfalls.
can you help to find the list of Azure applications where Application permission named Mail.* (it could be any permission Mail.Read/Mail.ReadWrite/Mail.Send/or any other)?
should use Powershell for this activity.
Note : Certain applications can have Delegated Mail.* permission (which we do not want).
Thanks
We have some old ADO/VSTS projects that we want to archive and make read only. Each project has work items, builds, git repos, etc...
at the moment the only methods I have found are painful.
Remove all groups except read only group and add users in there. this is too painful and long, we have over 300 projects to make read only
Create a new group and then add in other groups (e.g. proj admins, contributors etc..) and then add this group to the top level area/git repo path and set all to DENY. *
I tried this with git repos and There is some issues with this as some
permissions are not inherited down to individual users who created the
git repo and they are still able to checkin.
Here you can see I created a READONLY group and set everything to DENY except Read permissions. (The members of this group are the default groups e.g. contributors, build admins, proj admins)
However, I had a repo created by a test user BEFORE i created the readonly group and it seems that user still has permissions to that repo
ok ok I understand that if the permissions are set at the lower level, then they won't be inherited down from the top level parent. I could create a script that checks the users of every git repo and sets their check-in permissions to deny but that is painful and i would prefer not to do that. Likewise, some projects have over 300 git repos.
FYI I want to make the whole project read only not just git repos.
Azure DevOps now have a feature called: "Disable Repository".
Disable access to to the repository (including builds, pull requests,
etc) but keep the repository discoverable with a warning.
It means your repo will not allow commits, even builds and pipelines cannot use it. Just go to your Devops "Project Settings". Scroll down to "Repositories" menu and select which Repo do you want to disable.
Yeah, you've found one of the nasty features of the Azure DevOps permission model. More specific ACLs trump less specific ACLs. Even for DENY rules.
When there is an explicit ALLOW rule on a more specific ACL, it will override the DENY on a less specific ACL.
Specificity for git is based on:
Server (TFS only)
Organization / Project Collection
Project
Default repo settings
Specific repo settings
Branch folder settings (only settable through API)
Specific branch settings
Similar hierarchies exist for other securables.
There is no easy way to strip these all, apart from scripting the action.
The Azure CLI has a devops extension which will allow you to script out what you want and can output JSON to make it easier to script.
You can use az devops security permission list to list all permissions defined for a identity (group or user) and az devops security permission reset or az devops security permission update to unset or override the given permission.
Other probably needed calls:
az devops security group list
az devops user list
az devops security group membership *
You can use the Azure DevOps disable repository option, which has the disadvantage that the repo is not showing up in the list of repos under the project anymore. This might not be desired if the code should still be readable for reference purposes.
The other method explained in one of the answers is to manually remove any write permissions using the repository settings UI. If you have a lot of access control lists on your repos or even need to do this on multiple repos, the manual approach can become time consuming. Therefore I wrote a script to automate this: https://github.com/ckadluba/RemoveAzureGitRepoWritePermissions.
It basically works like this.
.\Remove-AzureGitRepoWritePermissions.ps1 -OrgName "myorganisation" -ProjectName "MyProject" -RepoName "MyRepo"
It sets an explicit deny for the permissions: GenericContribute, ForcePush, CreateBranch, CreateTag, ManageNote, PolicyExempt, PullRequestContribute
and PullRequestBypassPolicy.
Question regards Gerrit 2.14
Goal
I want to have projects visible only to Registered Users, and also I would wish that 'owner' of project can set it's visibility, share, hide etc without admin rights, or involving admin to set those rights for him/her per project. For example I want to have projects A, B, C, D, E with B, C owned by p1, and C shared between p1, p2. So user p1 would see B, C, and user p2 would see C.
What I've checked
I believe that there are 3 ways of achieving something described above:
user has admin rights - can set parent of project other than All-projects: I don't want that
admin can set per project ACL for user/group: I don't want that
user becomes Project Owner of projects s/he created
By default "Create Project" is not granted for Registered users and "READ for refs/*"
I have tried
Setting permissions in All-Projects.git that all project inherit
Create Group
Registered Users
Create Project
Registered Users
Reference: refs/*
Allow Administrators
Allow Project Owners
Deny Anonymous Users
/* IF I add ALLOW Registered Users here -> see bottom of question */
and all remaining permissions unchanged, I expected to be able, as registered user:
Be sure that anonymous (not registered/logged on) users cannot view projects
Create project using both GUI and SSH
Be assigned as Project Owner to that project - have full control over this single project
Result
Unfortunately, registered user can create project (if user does not select previously prepared parent All-public-projects - which grants multiple other permissions - default All-projects is assigned as parent) BUT user, who is supposed to be Project Owner cannot access this project.
Ideas what is wrong
I'm aware that Registered Users are members of Anonymous Users group as well, but documentation states
Inherited access rights can be overwritten unless they are defined as BLOCK rule. BLOCK rules are used to limit the possibilities of the project owners on the inheriting projects.
Changing the parent of a project is only allowed for Gerrit administrators. This means you need to contact the administrator of your Gerrit server if you want to reparent your project.
and also
[READ] This category has a special behavior, where the per-project ACL is evaluated before the global all projects ACL. If the per-project ACL has granted Read with 'DENY', and does not otherwise grant Read with 'ALLOW', then a Read in the all projects ACL is ignored. This behavior is useful to hide a handful of projects on an otherwise public server.
For an open source, public Gerrit installation it is common to grant Read to Anonymous Users in the All-Projects ACL, enabling casual browsing of any project’s changes, as well as fetching any project’s repository over SSH or HTTP. New projects can be temporarily hidden from public view by granting Read with 'DENY' to Anonymous Users and granting Read to the project owner’s group within the per-project ACL.
Now since I do not want to set permissions per project basis, am I correct to think that reason for this to fail is
For the All-Projects root project any Owner access right on 'refs/*' is ignored since this permission would allow users to edit the global capabilities, which is the same as being able to administrate the Gerrit server (e.g. the user could assign the Administrate Server capability to the own account).
Questions
If my reasoning is correct, how do I achieve my goal?
Also, granting READ refs/* to Registered User makes project to be accessible, but also all others too. How would I then be able to hide some projects from other Registered users? Or if that is not possible - how do I configure permissions in order to prevent other registered users to commit, and possibly even clone other projects?
Additional question.
How do I quickly see who is set as project's Project Owner?
I'm glad to see not beeing the only one with such a requirement. For me everything would work just fine if the user who creates a project via Gerrit's Web UI would be automatically the project owner (only if the user is not and Admin User). However, as you know the current Web UI does neither pass this information to the Gerrit backend nor does it allow to assign project owners when creating a new project. I see the following options:
Open a feature request for the Gerrit dev team hoping they will consider the idea
Use the create-project REST API and pass the project owner(s) for creating projects, i.e. using an own app
Use the create project CLI and pass the project owner(s) for creating projects
Implement an own Gerrit Plugin - see 2. Plugin Development which would make the current user creating a new project a project owner
For me only option 1 or 4 is viable because the other mean way too much overhead. I'm thinking about writing such a plugin, and I would make it opensource... About 2 months ago I was hoping there's aready something available I could use, but I couldn't find anything.
To your second question: I typically us the Web UI for this by going to the project's Access tab and then checking the who has the permission "Owner" for the branch refs/*.
I've a very simple application built in MVC4. This application allow the users to upload a file, and the application generates an output.
This app works great locally, but when I publish to azure (by right click -> publish), I get a less descriptive error. I've figured out that the error was because in the code, we accessed to a server relative path, and that is not possible in azure. So I've found a way to solve that in this link, that says that I should use LocalResource, rather than Server.MapPath. That make sense for me, but so far, I'm struggling with the suggested line.
LocalResource localResource = RoleEnvironment.GetLocalResource("DownloadedTemplates");
I'm not able to get it working, and also can't get a proper error. BTW I'm not sure how to enable the error log in azure :(
So, after going deeper in MSDN, I've seen that I should configure the Local Storage Resources, but as I've created a local MVC4 project, I can't find where I should configure this.
I need to be able to store a temporary file in the application (hosted in azure).
Did someone faced with this problem?
Anybody knows how to enable the Local Storage Resource in a project like that?
TIA!
Milton Rodríguez
Well, after struggling a while, I've ended up using Windows Azure Tools.
The steps:
Add a new project
Under Cloud category, select Windows Azure Cloud Service.Note that if you don't have this option, an option to install the needed SDK will be shown. Install it first.
Name it properly :)
New Windows Azure Cloud Service window will appear, select the role that fits your needs. In my case, I choose ASP.Net MVC4, and then removed it.Note that you can edit the name of the created role at the right.
In the Roles folder of your new project, select Add, and then Web Role Project in solution. Your project will be an option to add.
You can remove the other role in the folder, the web project created in step 4, and also the folder ending in Content (ie. WebRole1Content). Basically, you can remove the created assets, but the Azure Service, and link the service to your project.
You're almost done. Follow this link to configurate your local storage :)
Now you're done!