Im using gitlab, and I am wondering, is there a simple way to restrict access to a branch to only certain developers? This has to do with time varying disclosure and the ability for certain developers to see some objects models, while other cannot? Ideally this would happen in one repository, without a proliferation of forks.
No, it is not possible to have a read protection to certain git branches. That would also defeat how git works.
What you could do is forking a repository, creating a branch here and only grant restricted permission to the entire repository. Later it would always be possible to merge changes from this forked repository to the original repository.
You can only change read access to the entire repository as well as write permission to branches.
Related
I am using KeyCloak as my user management tool, and love it.
The data of Keycloak is stored for me on a Postgres database. Over time, more clients are being registered, and other alterations to the realms may be done. My question is: How do I properly keep track of that, and propagate automatically changes between my different environments? For databases, I use liquibase for a purpose like this. I couldn't find anything similar for the Keycloak case.
So, I wanted to ask: How are you folks out there handling this? What am I missing?
It depends on how you're doing the management of those changes. There are generally two approaches:
Using the Keycloak admin console
Using the Keycloak CLI
If you're applying your changes via the admin console, then you can either rely on the database backup or setup a scheduled pipeline in your CI tool to make an export of the Keycloak realm into a file and archive it somewhere.
In case you're using the second approach, then you can have a git repository containing all the Keycloak CLI scripts that you run on your server (e.g. to add a client, to update a realm config, etc.). In that case, you can have them reviewed, versioned and then run as part of an automated pipeline. This will also allow you to run a script on different environments. But of course it comes with a price which is to write a script for every single task that you can typically do in admin console with a couple of clicks.
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.
Setup:
Private master repo and every developer has their own private fork.
Currently using CircleCI, but we'd be happy to switch to satisfy requirements
Branches on master repo are protected with merge restrictions
Requirements:
Build + test on forked pull requests
Deploy to different environments based on master repo branch updates
Not all developers can be fully trusted with production credentials
Partial Solution:
Enable building and passing secrets on forked pull requests (Reference)
Use CircleCI contexts to set environment variables per branch. This allows different deploy targets.
Problems:
All repo specific secrets as well as all global contexts are now accessible by anyone who can open a PR.
Even if we disable building on forked pull requests, anyone with write access to at least one repo can access all global contexts.
Question:
This would seems to be a very common use case. How do other companies solve it?
Is CircleCI not the right tool for this? - No, it is not (see below).
Should we build a custom solution?
Edit1:
CircleCI got back to me and surprisingly this is not a use case they support. Looking into other providers now. Above questions are still unanswered.
Edit2:
I've also contacted TravisCi and SemaphoreCi and it appears that only TravisCi supports building forked PRs and not leaking secrets into them (Reference).
SempahoreCi is missing (1) building forked PRs and (2) hiding secrets from the deployment phase in non-master workflows
CircleCi has restricted contexts, but they would require manually changing workflows. Definitely not easy to set up and I don't fully understand how they would work.
I want information about all commits done on my BitBucket repository.
I dont need an XML Feed. I want just a list of commits and the order in which they are committed and possibly information about merging.
On bitbucket websites information is shown in paginated form and is not sufficient for me. It would be nice if could obtain a pdf or something listing all my commits.
Is there a way to do so ?
Any help would be appreciated.
Thanks,
Pankaj.
You should make a local clone and then access the local repository using whatever tools you have that can generate such a PDF. That way you'll have full access to the information you need about commits and merges. Since Mercurial is a distributed version control system, this is really the way you're supposed to access it: locally, not via screen-scraping on Bitbucket.
If you're using Java or Python, then you can use JavaHg or python-hglib to access the repository. See the full list of libraries.
I have a "central" Mercurial repository, which configured to use HTTPS and requires authentication to clone-pull-push changes. Developers has their own repositories on their computers. They configure their local settings freely, and for example add section like
[ui]
username = anyname
to their local mercurial.ini file.
When a user try to push his changes to the "central" repository, he authenticates, but authentication info is not stored in Mercurial. Mercurial store locally configured username as revisions author in central repository. So I cannot find who really made changes in central repository, but I strongly wish to do it. Mercurial developers does not care about it and consider this behavior to be correct.
But I want to keep authentication info near changesets. I think the best way to do it is add one more additional field in revision description, like "pusher id" and store there authentication data.
Extensions I found do not implement similar functionality. Can you give me info about some third-party extensions, hooks, or just code templates or ideas how to do it? (I'm absolutly new in Python)
The fundamental problem that makes Mercurial developers (like myself) reject this is that changesets are immutable. It is impossible for a server to add extra information to the changesets when they are pushed.
More concretely: a changeset is identified by it's changeset hash. This hash is computed based on all the information the changeset contains, such as username, date, commit message, and the change itself. You cannot change any part of this, without also changing the changset hash — otherwise the integrity of the repository is destroyed.
This gives you security against accidental (or malicious!) changes made on the server: if Alice and Bob talk about "changeset X", then they can be sure they really mean the same thing. If the server (or someone else) could change the content of a changeset without affecting the ID, then Alice and Bob would not be guaranteed that "X" really means the same
thing in both their repositories. This property is of course also fundamental to the way Mercurial works when synchronizing repositories.
You have two options here:
You can let the server reject a push if Alice tries to push a changeset with Bob's name in it. This is can be done with a pretxnchangegroup hook on the server. It will inspect the HG_SOURCE environment variable and verify that the user listed there is also the committer of all pushed changesets between HG_NODE and tip.
You can let the server log the pusher. This is called a "pushlog". The Mozilla project uses one and the source appears to be here. There you make your server store information about who pushed what. This is done in a changegroup hook that logs the necessary information in a small database.
If you want a push log, then take a look at Kallithea, which has this functionality built in. Kallithea is in general a great way to host Mercurial repositories! It has much more functionality than the normal hgweb CGI script.