As part of automating my jenkins setup I need to add credentials for use with any svn configuration in my build jobs.
Manually you would add a domain to here
http://< your server >:8080/credential-store/
Then add credentials here:
http://< your server >:8080/credential-store/domain/< your domain >/newCredentials
Has anyone managed to automate this? There doesn't seem to be a usable api and the xml files contain hashed passwords which stops me from just copying
files around (plus i worry about security with this)
Related
I want to save and use the allure report from amazon S3 (not in-home workspace), so used S3 publisher plugin
target/allure-results and allure-report folders with files were published into amazon S3, but I can't take allure form S3
How I can do that?
If you really want to enable public access to your Allure reports from within S3, you can follow the official guide. In this case, a custom domain name is used. However, you can do the same w/o it just by enabling website hosting and relaxing bucket restrictions.
Note that it's not a secured way to access your reports, as they become visible to the outside world. Even if you use a CloudFront to restrict access to your bucket, it won't solve the visibility problem. It's a critical security issue, as you usually expose different URLs and credentials in test reports.
On one of my projects, there was a GitLab, and we created a simple html page with links to build logs and Allure / Swagger coverage reports. This page was registered to a customer's subdomain and accessible by authorized GitLab users only. Everything else (results aggregation, report generation, copying history, etc.) was handled from within GitLab pipeline.
I'd recommend talking to your DevOps and explain what you are trying to achieve considering all the security concerns. It's basically a one-day job for them.
I use Microsoft Team Foundation Server (TFS) for most of my software deployments. TFS allows me to dynamically replace text within specific configuration files during the release process to specific environments (dev, test, prod).
The text it replaces are placeholders called "tokens". For instance, during my automated deployments, TFS will allow us to replace tokens found within configuration files with pre-defined values saved in the build administration for each environment. This way, I don't store any real credentials in source control for any environment. I also don't store any script in source that would hold these sensative credentials. The credentials are dynamically inserted over top the tokens during the release, and the credentials are hosted/saved/configured inside of the release system (not in a script).
For example, I have a configuration file (web.config) that has tokens. A token looks something like this:
MySettingName=${MYSETTINGVALUE}
During the release to DEV, I want the text ${MYSETTINGVALUE} replaced with the word TEN. During the release to PROD, I want that same ${MYSETTINGVALUE} text replaced with the word ORANGE. And I want to store those two values (TEN and ORANGE) in the release administration system, and not in a script.
How do I configure Jenkins to do this same thing?
I have searched up-and-down for this specific answer. While many blogs, articles, documentation exist, none of them speak directly to this issue.
I would prefer NOT to use some additional 3rd party software to do
this.
I would prefer NOT to kick off some manual build and supply these
values each and every time.
I would also prefer NOT to use an Operating System level system
variable (aka evironment variable). In case that server dies, I
would rather not have to remember to setup those OS environment
varialbles on the next server.
Jenkins has a built-in credentials plugin for handling secrets in builds.
See this article on how to use them: https://support.cloudbees.com/hc/en-us/articles/203802500-Injecting-Secrets-into-Jenkins-Build-Jobs
Basically it stores credentials securely and injects them into your jobs as variables which can then be used like any other.
A configuration file (.yml) is being used for a rest api developed with Dropwizard (0.9.2 - latest release). Most of the credentials needed by the api such as database password secret key etc., are stored in the configuration file.
We have implemented most of the things based on the items mentioned in the reference found at dropwizard configuration reference .
The question is clear. How secure is it (storing these information in a configuration file as plain text.)? If not, what is the proper way of doing this?
Yes, it's not secure indeed. Even worse if the configuration file is committed to a public repository or for that matter any repository (version control). One way which I follow is to maintain a local copy (not to be committed to any repository) of the config (.yml) file which has all the sensitive keys & details etc and maintain another example config file which has the sensitive details masked (some dummy strings instead of actual values). This example config can be committed to your repository as it has sensitive details masked.
For all purposes of running your code locally or elsewhere use the local config file. This way you don't risk it to exposing sensitive data on a repository. There is an overhead though in keeping your example config in sync with your local copy whenever you make any modifications.
I just looked for the solution for the similar issue. I want to find an solution to not include the keystore password in the config file. Finally I got an solution for it.
Just stored credential keys in the config file. And then use a substitutor to replace the keys with it's related values. But this need a secure key value services to get the values of the keys.
Overriding server connector config with env variables with dropwizard
Is there a way to use the credential store with the CVS plugin to access a CVS repository? Looking for a way to store credential once and have one place to change it, despite many jobs making use of it.
The CVS plugin doesn't use the credentials store directly (although there are potential plans to move to this in a future overhaul of the plugin), but it does have a concept of global credentials which should provide what you need. The reason for having something separate from global credentials was that CVS introduced this prior to the credentials plugin being available and the steps have never been taken to try and perform a migration.
To use this credential feature, ensure you have version 2.4 or above of the CVS plugin, goto your 'Manage Configuration' screen, scroll down to the CVS section and click the 'Add' button next to the 'Authentication' option. Once you've added any credentials in here, go back to the jobs you're wanting to use the global credentials on, check the CVS root matches what you put in the authentication section and that it doesn't contain a username and then run your job. When running, the console should then show 'Using globally configured credentials for...' when trying to connect to CVS.
I am creating files with a custom version number during the build that I want to be publicly available through http.
Assuming I am building the project "MyTestApp", I want the version number text file I created to be available at a location like http://jenkins.company/job/MyTestApp/revision.txt
Any idea how to achieve this?
David, this depends on what you mean by "publicly available". If your Jenkins instance is secured (jenkins.company/configureSecurity/), then access to artifacts requires that your http session be authenticated. If all users who need access have accounts on the Jenkins server, then you just need to use the post-build action "archive the artifacts", and your text file would be available here:
jenkins.company/job/MyTestApp/jobnumber/artifact/revision.txt
Or here:
jenkins.company/job/MyTestApp/lastSuccessfulBuild/artifact/revision.txt
See this screenshot: http://note.io/17oiykI
If you need unauthenticated access, you could publish your artifacts to another web server on the same or a different host. Or you could upload them to an Amazon S3 bucket.