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.
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?
I have a series of jenkins pipeline jobs to move Apps to Cloud Foundry. My client application need to be able to listen to all the updates of a push. I.e. apart from getting text logs, i need other events like Git repo cloned, cloud foundry logged in, App pushed.
One crud way of doing this is to submit POST requests to an event server from a shell script(Curl). However, I think it is unlikely that such a functionality does not exist already on Jenkins(either through a plugin or something like that).
I need an advice from best practices point of view.
Thanks.
As commented by mdabdullah. But this needs a person to set up kibana or splunk. (I did not try this).
Statistics gatherer plugin
https://plugins.jenkins.io/statistics-gatherer/
Jenkins notification plugin
https://plugins.jenkins.io/notification/
Both 2,3 are available plugins in the Jenkins community. They need to configured for server endpoints before use.
We're using Jenkins (and precisely Cloudbees) for couple years. Well, it works.
Not I have new use case when I would like to allow trigger build remotely (w/o user account in Cloudbees).
Looks like it's impossible (standard token trigger mechanism requires an account in Cloudbees).
The only one way that I see it to set-up instant message integration (e.g. Jabber) and trigger builds in chat. It's nice solution that I would like to have, but ... it doesn't work for me. No errors and no messages (I tried different jabber servers).
Because I have only one such weird user I don't want to install special software (like Jabber/IRC server) and wanna use existing (like Gtalk or similar).
Any thoughts will be welcome.
standard token trigger mechanism requires an account in Cloudbees
You can use the Build Token Root plugin to bypass authentication long enough to check the token.
In the long term it would be desirable for Jenkins to let users create non-user principals that would have their own API tokens and SSH keys (but no UI login) and a restricted subset of permissions, so you could freely create a one-off principal for a specific purpose such as triggering builds. The infrastructure for such a feature does not exist today, however.
From https://groups.google.com/forum/#!topic/cocoapods/i7dwMV4EqZ8
I'm a bit of a CocoaPods newbie and have never created a Pod before, but I'm looking into how one would be able to automate publishing of public podspecs from within my organization's continuous deployment infrastructure, which has some properties about it that makes using Trunk difficult. They are:
The account/owner that does the publishing is a non-human system account.
The aforementioned system account does not have a home directory on the machine that it runs on, which will hamper usage of a .netrc file (what Trunk uses for storing session tokens). This should be able to be worked around by creating a fake home directory and setting the HOME environment variable to it, since that's what the netrc gem looks for.
The machine that does the publishing is assumed to have "no state," meaning the publish could always occur on a different machine that has never been registered.
I've thought about creating the initial .netrc for this account, storing the token from that in our secure storage, and retrieving it to build a .netrc file when publishing. There's a few things about this that I don't think work well:
The tokens returned by Trunk appear to expire, which would mean having a human to periodically create a new token and update our secure storage.
Trunk sessions appear to be tracking the IP address of the machine they were created from, which I assume publishing requests are validated against and fail if the IP addresses do not match. Because publishing takes places on different machines, this would imply requiring to create a new session every time this publishing automation is ran. Practically speaking, I would hope that the IP addresses for these machines would come from the same external IP address, but that's not an assumption I can live with.
The next alternative I would have is much more complex: having the publish automation register a new session, wait for the registration email, then verify the session with the link in the email before proceeding with the publish. I don't know how to actually accomplish this off the top of my head, but I think it's a viable, if not time-consuming to implement, solution. Any suggestions on how to accomplish that are welcome.
Are there any alternatives for publishing public podspecs? It seems to me that Trunk doesn't really support this use case; it'd be great if there was a way to accommodate for it in Trunk.
No until now.
But I issued Question to be possible to automate pod trunk push with CI service like travisCI.
And then, a developer merged the commit (Allow specifying a Trunk token via the COCOAPODS_TRUNK_TOKEN environment variable) that will allow to automate publishing.
I don't try it, but maybe can push automatically.
[Added] After I wrote above, I tried it and it worked well.
I downloaded Gerrit, unpacked it and started the server with bin/gerrit.sh start. Then I noticed that I cannot log into the web frontend and looked for my options. Since all I would like to do is add a test project and play around with it to explore the features, I would actually like to avoid authentication at all.
Is there a way to get this going without openid or ldap. auth.type=http would be just right, but this again requires an apache in front. Or can I just configure jetty to do it. If so, how?