I want to disable write access or any direct commit on release/* and main/master, the only way for these branches to get update is via merge/pull request coming from feature, hotfix, bugfix, or develop branches to avoid trouble. How can I enforce such rule? Currently exploring Branch permission.
While allowing everyone that has access to the repository a pull from release and main/master and direct commit only on feature, hotfix, bugfix, or develop branches
Not sure if my understanding and what I am doing is correct as other user aside from Bitwise can still direct push to master branch.
Related
This model looks good: https://cloud.google.com/architecture/managing-infrastructure-as-code-with-terraform-jenkins-and-gitops#infrastructure_proposal
However it's possible for anyone with repo access to create a feature branch, put any old content into a jenkinsfile, and create a PR - at which point Jenkins will run whatever's in the jenkinsfile. To me this kinda negates the controls to enforce peer review of code, or stops you allowing certain individuals only permitted to deploy changes to dev etc.
I'm not aware that you can "protect" the jenkinsfile and stop this happening (at least not in github).
Best solution may be to enforce controls at the cloud access key credential level (I'm an AWS user so I think in terms of secret access key) - so only certain jenkins (or github) users can pull the creds to make infrastructure changes?
What's the difference between hooks and webhooks in BitBucket? I've read the documentation for both but I can't seem to understand when you would use one over the other.
Edit: Documentation that I read.
https://confluence.atlassian.com/bitbucket/manage-webhooks-735643732.html
https://confluence.atlassian.com/bitbucketserver/using-repository-hooks-776639836.html
As ben5556 mentioned, you're comparing Bitbucket Cloud documentation to Bitbucket Server documentation. There's another important distinction here, though: the Bitbucket Server docs you linked refer to git hooks, which are a native part of Git, and the Bitbucket Cloud docs refer to webhooks, which are an HTTP-based callback mechanism. (In the interest of full disclosure, Bitbucket Server can send webhooks as well: https://confluence.atlassian.com/bitbucketserver/managing-webhooks-in-bitbucket-server-938025878.html)
You can't currently control git hooks on Bitbucket Cloud, but on Bitbucket Server (where you'd only break your own stuff) you can use those to control different parts of the git workflow. For example, on BB Server, you can use a pre-receive hook to reject pushes if some commits don't have a ticket number in the commit message, or you can use a post-receive hook to notify your (human) users about upcoming maintenance.
Webhooks are typically used more as a notification method - you can have Bitbucket notify Slack about pull request merges, for example, or have Bitbucket notify your CI/CD system that there are new commits to test.
Both are same from what I understand. One refers to Bitbucket server while the other refers to Bitbucket cloud but in essence their purpose is same.
In our GitHub we have around 20 repositories. For the CI Build we have enabled Git polling option.
Our Jenkins master has attached with multiple nodes. For Git Polling we usually add our Jenkins Master ssh key to repective user's GitHub under settings SSH key section. While adding the key getting Error: Key already in use. Let me know to add the same.
As per error message for other repository build we have already added our Jenkins Master key with different user's
account.
A SSH key can only be attached to a single user on GitHub, since it is used to authenticate and authorize this user. There is no way to add to multiple accounts.
GitHub provides a guide about dealing with SSH keys for automated scripts here: Managing deploy keys. The two interesting options are:
Typically, you would use deploy keys to gain access to a repository from a server. Deploy keys have a similar restriction as a user's SSH key though, and can only be attached to a single repository. This reduces the potential damage that can be done if the key is compromised. For build servers they are often not well suited, because it is often not possible to configure authentication per repository.
For your use case, a machine user seems to be the best option. This is a dedicated user account that is only used by your build server. Make sure to use a strong password and two factor authentication for this account, and add Jenkins' master key to it. You can then add the machine user as a collaborator on the repositories you need in Jenkins.
With regards to security, be as restrictive as possible: only the repositories that are required, and only with read permissions. This is also the reason why you should use a machine user instead of an actual user account. For Jenkins, you (usually) don't need write access to a repository. By limiting the access rights for the server key, the impact of a compromised key is reduced.
There are so many posts about this, and being inexperienced in Git doesn't help to get a good grip on this.
I just joined a new company that dont have CI at all, so jumped on the opportunity to create a proof of concept (using Jenkins locally on my Windows box for now, until I get a dedicated server for it). I've used and semi-configured Jenkins in the past, using SVN, and it was so simple and fast to get it working. In this company, they don't use SVN, only GitLab (I believe its private - we have our own site, not .gitlab.com), and nothing works for me.
I followed a few turorials, but mainly this seemed like the one that meets my needs. It didn't work (the reasons and symptoms are probably worth a post of its own).
When I look at Gitlab Hook plugin in Jenkins, I see a big red warning saying it is not safe ("Gitlab API token stored and displayed in plain text").
So my question, for this POC that i am working on, how serious is this warning? Should I avoid this plugin and then this method altogether because of this?
And while i'm at it, I might also throw an additional general question to open up my options here ... If I want Jenkins to work with Gitlab (meaning, I checkin something and it triggers a build), do I absolutely need to use the SSH method, or it could work with HTTPS as well?
Thank you.
This is indeed SECURITY-263 / CVE-2018-1000196
Gitlab Hook Plugin does not encrypt the Gitlab API token used to access Gitlab. This can be used by users with master file system access to obtain GitHub credentials.
Additionally, the Gitlab API token round-trips in its plaintext form, and is displayed in a regular text field to users with Overall/Administer permission. This exposes the API token to people viewing a Jenkins administrator’s screen, browser extensions, cross-site scripting vulnerabilities, etc.
As of publication of this advisory, there is no fix.
So:
how serious is this warning?
Serious, but it does require access to the Jenkins server filesystem, or it requires Jenkins administration level. So that risk can be documented, acknowledged and, for now, set aside, provided mitigation steps are in place, ie.:
the access to the Jenkins server is properly monitored
the list of Jenkins admin account is properly and regularly reviewed.
do I absolutely need to use the SSH method, or it could work with HTTPS as well?
You can use https for accessing GitLab repositories in a Jenkins job.
But for the GitLab hook plugin, SSH remains the recommended way, considering you would use a token (instead of a user account name/password), that you can revoke at any time.
I'm a collaborator with https://github.com/martinh/libconfuse/, so I can
push and tag stuff. Most references on the Interwebs is for this URL, so
it would be convenient to be able to set up Travis-CI (and more) for this
repo, not my own fork. Is this possible? (The original maintainer can no
longer spare the time.)
Considering my options, maybe the simplest way to go about this would be to
maintain everything in my own fork? (https://github.com/troglobit/libconfuse)
You're required to have Github admin access for setting up the hooks, so yes use the simple way and fork it or see that the owner gives you the required access.
Alternatively he might be convinced to transfer ownership but github does not do redirects for repo's (they do for hosted sites), which would defeat the purpose (https://help.github.com/articles/transferring-a-repository/)