How to use external CyberArk vault to store credentials in free version Jenkins?
Here you can find info regarding the standard jenkins credentials plugin - that provides an API for external storage.
But after digging a while on the net, I’ve found that:
1. Cyberark vault is available on Cloudbees Jenkins only
2. HarshiCorp vault plugin is available for free
3. Here is a nice example how wrong permissions policy can lead to exposing all credentials. I tried it, works like a magic! :)
You really don't want to store credentials (or any sensitive secret, really) in Jenkins. It's not a vault and should never be used as one. Otherwise you'll end up with your Jenkins servers becoming a major target for attackers.
Instead, integrate your Jenkins pipelines to pull secrets securely into executors only when needed, and discarded when the build/test job is done. This is easily done with something like Summon, which is integrated with many vaults already, including Conjur (which is a CyberArk product, too). Both are open source offerings.
This blog post describes an approach to integrating Jenkins with a vault along the lines of what I've described above.
Appears that CyberArk released Jenkins plugin which supports that scenario:
https://docs.cyberark.com/Product-Doc/OnlineHelp/AAM-DAP/Latest/en/Content/Integrations/jenkins.htm
You might want to look at https://github.com/tmobile/t-vault .
This will eliminate the need to manage policies. You could create one safe per project folder or job in jenkins.
You can create approles and grant access to safe for the approle. Each project can use corresponding approle. You can grant access to individuals to the safe as well. Users can then use the webui to author and update the secrets.
Related
Pub/Sub is really easy to use from my local work station. I set the environment variable GOOGLE_APPLICATION_CREDENTIALS to the path to my .json authentication object.
But what if you need to interact with multiple different Pub/Sub projects? This seems like an odd way to do authentication. Shouldn't there be a way to pass the .json object in from the Java code?
How can I use the client libraries without setting the system's environment variable?
Thanks
You can grant access for PubSub in different project using single Service Account and set it as env variable. See PubSub Access Control for more details.
A service account JSON key file allows to identify a service account on GCP. This service account is the equivalent of a user account but for the app (without user, only machine).
Thereby, if your app need to interact with several topic from different projects, you simply have to grant the service account email with the correct role on each topics/projects.
Another important thing. The service account key file are useful for app outside GCP. Else it's bad. Let me explain this. The service account key file is a secret file that you have to keep and store securely. And a file, it's easy to copy it, to send it by email and even to commit it into public git repository... In addition, it's recommended to rotate this key at least every 90 days for security reasons.
So, for all these reasons and the difficulty in security that represent the service account key files, I don't recommend you to use them.
With your local environment, use your user account (simply use the gcloud SDK and perform a gcloud auth application-default auth). Your aren't a machine (I hope!!)
With GCP component, use the component "identity" (load a service account when you deploy a service, create a VM,..., and grant the correct role on this service account without generating JSON key
With external app (other cloud provider, on premise, Apigee, CI/CD pipeline,...), generate a JSON file on your service account, you can't avoid them in this case.
I'm working on a project with Google App Engine. I am using continuous integration via Travis, and wish to be able to deploy directly from it. Due to a bug that will not be resolved directly, I can't rely on Travis' built-in GAE deployment, so I basically have to use mvn appengine:update manually. This requires me navigate to a generated URL and manually paste to the terminal an authentication code, which I can't do in automated builds.
It was suggested to me, however, that I do some Unix magic instead. While I can easily pick out the URL I need to navigate to from grep, I still need to log in to Google with my credentials in order to actually get the authentication code (which I can then grep out and pipe to the deployment program).
Given that, how do I log in to Google with my credentials, using only curl or similar command-line utilities?
I've accomplished similar things in the past using Service Accounts. These are likely a good fit for your problem.
Service Accounts will allow you to authenticate and upload your app without manual intervention.
Overview
A Service Account will allow you to do "passwordless" authentication like you may already do with ssh, and git, etc. by setting up your keys. This will remove the requirement that you log in manually, or follow the road to madness by trying to do a "manual" login automatically.
There are basically two steps:
Create your service account and key (with the right permissions)
Use that credential instead of what you're doing now
Resources
I think it's better to give a list of resources than concrete instructions since it's basically impossible to express concisely (even though it's a simple process, there's bound to be a lot of little things that annoy), everyone's requirements will be slightly different, and Google is likely to change the process at some point.
Using the Google Cloud Platform Console for App Engine | Permissions
Using OAuth 2.0 for Server to Server Applications
Setting up OAuth 2.0 | Service Accounts
gcloud auth activate-service-account
Hopefully that's enough to get you headed in the right direction.
Note
You'll likely have to spend some time looking at your .appcfg_oauth2_tokens_java and sorting out a variety of other annoyances, but I believe that this approach is the best way to solve your problem.
It sounds like you have a pretty straight-forward setup and that a Service Account alone will get you there, but if you need to get a little weird, the App Engine Admin API is always there.
With the release of sonarqube 5.2, the decorator and batch components have been deprecated. Going through the code I found that they want us to use MeasureComputer instead.
Now, I had a plugin which needs the email settings of the sonar setup, fetch some basic user information and the assignee of each issue.
How do I access the email settings and user information?
Update
As per this JIRA ticket, the data associated to the analysis is sent to some compute engine which resides at the sonar server. This is where the issues are created, assigned e.t.c. So, the information regarding the issue will no longer be available even in some PostJob.
User finder alternative: I am now using the user web service to fetch information I require as far the author of the issue is concerned.
IssueFilter helps me lay my hands on each issue that is reported.
My purpose here is to create a custom report immediately after the analysis where a link to each issue is shown. I don't think I'll be able to achieve this using the sonar plugin.
I've created a website within the company that utilizes our active directory server to authenticate. I am concerned about security surrounding setting up relying parties with "localhost" domains.
I've pretty much followed this guide on setup. You'll notice about halfway down the page, there is a step to set up the development environment, localhost:44336 as a relying party.
I am concerned that someone could easily get the location of our federation metadata document, and simply roll their own project utilizing the same port and get access to our active directory. Is this a valid concern, or am I worrying over nothing? What would be a better alternative to having to use localhost in this configuration?
Yes it's safe. The metadata document only describes information about endpoints and about the token that active directory is issuing. It doesn't inherently have anything sensitive about it.
The actual authentication is still going to be handled by AD and unless the curious user already has a way to successfully authenticate against your AD then it's rather useless for him to hookup into that document.
Could they potentially create an app that uses your authentication protocol? Sure, but what would be the point if nobody can actually authenticate against it. Allowing this sort of behavior to happen is one of the points of ADFS.
I have a google app engine application which needs to be given a public-private key pair. I don't want to check this into source control because it will be accessible by too many people. Since this is GAE I can't use the build system to write the keys to the file system of the server.
Is there a known best practice for this?
My first thought was does Jenkins provide a way to manage keys securely? I know I can just copy the keys to a location on the jenkins server and copy them into the build but this project will be used by third party teams so I need to provide a UI based solution in jenkins. I did not find any relevant plugin but I would like to make sure there isn't a better way before writing my own.
There are of course several approaches to this. I believe certificates are a concern of admins, not developers.
What we do is have custom admin pages where we upload certificates to blobstore under separate namespace. Then we have an internal "service" (just a simple factory) so that other pieces of code can retrieve certs.
If you are happy to use a cloud based Jenkins, we (CloudBees) have an oauth based solution at appengine.cloudbees.com
You could roll your own. It is not excessively tricky. You will need to
Register with google's api console to get a client key and secret and define the endpoints that your app will show up as
Write some way if feeding those credentials to your Jenkins build. I would recommend using the credentials plugin
Either write a build wrapper that exposes the refresh token to your build (python sdk deployment) or exposes the access token (java sdk... Got to love that the two sdks do the same thing in different ways)
Or use our free service ;-)