We use thycotic to manage the secrets.
I want to access thycotic secrets in the gitlab ci yaml file.
While referring the docs, gitlab supports the Hashicorp vault to store the secrets and access them in gitlab CI job.
Same way: I need it for Thycotic
Is it possible?
This is currently not supported, but actively requested in gitlab-org/gitlab issues 291072
Only alternative, not yet released:
We will soon release an upgraded CI_JOB_JWT token that should support various hyperclouds, including their secrets managers.
If one can use a JWT token to authenticate with Tycothic, I'd recommend to go in this direction.
Could you check for me of OpenID Connect is an option for Tycothic?
But:
Thycotic does have OIDC support (among others) for their dsv product, but not the on-premises one
Related
I have created a Github OAuth app and I am trying to add the app as an OIDC application to AWS Cognito.
However, I cannot find a proper overview about the endpoints and data to fill in anywhere in the Github Docs.
The following fields are required:
Issuer -> ?
Authorization endpoint => https://github.com/login/oauth/authorize (?)
Token endpoint => https://github.com/login/oauth/access_token (?)
Userinfo endpoint => https://api.github.com/user (?)
Jwks uri => ?
I couldn't find the Jwks uri anywhere. Any help would be highly appreciated.
Seems like there is no way to get this working out of the box.
https://github.com/TimothyJones/github-cognito-openid-wrapper seems to be a way to get this working.
If any Cognito dev sees this, please add Github/Gitlab/Bitbucket support.
GitLab 14.7 (January 2022) might help:
OpenID Connect support for GitLab CI/CD
Connecting GitLab CI/CD to cloud providers using environment variables works fine for many use cases.
However, it doesn’t scale well if you need advanced permissions management or would prefer a signed, short-lived, contextualized connection to your cloud provider.
GitLab 12.10 shipped initial support for JWT token-based connection (CI_JOB_JWT) to enable HashiCorp Vault users to safely retrieve secrets. That implementation was restricted to Vault, while the logic we built JWT upon opened up the possibility to connect to other providers as well.
In GitLab 14.7, we are introducing a CI_JOB_JWT_V2 environment variable that can be used to connect to AWS, GCP, Vault, and likely many other cloud services.
Please note that this is an alpha feature and not ready for production use. Your feedback is welcomed in this epic.
For AWS specifically, with the new CI_JOB_JWT_V2 variable, you can connect to AWS to retrieve secrets, or to deploy within your account. You can also manage access rights to your cluster using AWS IAM roles.
You can read more on setting up OIDC connection with AWS.
The new variable is automatically injected into your pipeline but is not backward compatible with the current CI_JOB_JWT.
Until GitLab 15.0, the CI_JOB_JWT will continue to work normally but this will change in a future release. We will notify you about the change in time.
The secrets stanza today uses the CI_JOB_JWT_V1 variable. If you use the secrets stanza, you don’t have to make any changes yet.
See Documentation and Issue.
We are using vault to get rid of all secrets from our codebase and config servers. Vault aws auth with its secure introduction seems like the perfect fit for this. However our dev environment is not on aws and vault cannot work with config server to fetch different configurations per environment.
Do you guys see a way out where I could still use the aws auth for staging and prod and a different auth for dev?
Thanks,
Chris.
Authentication methods can be configured via bootstrap.properties so ideally have multiple profiles, one of them to use AWS authentication and the other one for dev.
We would like users to use their username/password along with another form of Multifactor Authentication, such as Google Auth (or Authy), to log into Jenkins.
We did not find any plugins that support this.
We are using AWS, so one of the things we looked at was putting an ALB in front of Jenkins and then putting, but this may interfere with getting POST requests from github to trigger builds.
Any ideas/plugins/suggestions on how to enable MFA on Jenkins?
Thanks!
I believe it is recommended to use SSO (something like SAML: https://wiki.jenkins.io/display/JENKINS/SAML+Plugin) and then as part of the SSO you can implement MFA. The problem with doing MFA directly with Jenkins is that Jenkins has pretty rudimentary user management.
What would I need to do in terms of setup and configuration if I want to build an API that I plan to deploy and host on a virtual machine in azure. That Web Api would make calls to our on premise TFS instance to perform continuous integration processes such as creating, getting, and kicking off builds and releases? Do I need a token, some special permission, etc..
You can use TFS REST API and use Personal Access Token (PAT) to authorize. When defining PAT you can decide scope based on the request that you are going to make.
Also you may try build and release integration for DevTest labs: https://marketplace.visualstudio.com/items?itemName=ms-azuredevtestlabs.tasks
Goal:
I want do write an application that can trigger Jenkins jobs and itself also authenticates users against the Crowd server. The users must be in a separate crowd group to be authorized to act on Jenkins.
Setup:
I am using the Crowd2 plugin to authenticate Jenkins users against an Atlassian Crowd 2.1 server.
My thoughts:
Now, Jenkins has two types of remote execution:
Jenkins REST API (uses a per-user Token for authentication)
A build can be triggered through this call using a "TOKEN" in a way like this:
JENKINS_URL/job/JOBNAME/build?token=TOKEN
Jenkins CLI (uses an SSH key for authentication)
A build can be triggered through an command line tool using the SSH private key to authenticate the user.
The token-approach (REST API)...
... requires my application to know the API token.
How could I bypass the API token limitation?
Storing the API token within Crowd?
The Crowd2 Jenkins plugin could store the Jenkins API token as an crowd attribute (user-defined properties which can be stored within the crowd user directory), is one way. Even though I think this could be a security flaw, as the attribute might be retrieved from all other applications registered at Crowd (which would enable them to execute Jenkins jobs on the users behalf).
Q: Good approach and secure enough? In my opinion, this is not secure enough.
Authenticating with my applications crowd token against Jenkins?
I've also tried generating a crowd-token through Crowd's API and then requesting the Jenkins REST API with that token as Cookie in the hope that the Jenkins crowd2 plugin validates the passed Crowd token against Crowd. But it does not work (when using the crowd token from my browser, by examining the page information in Firefox, it works, of course).
I am not sure if this approach (if the crowd2 plugin would check the passed token) has security flaws in it and if the crowd-token mechanism is designed to work in that way. I am sure though, that it might negatively affect Jenkins' performance as every API request has to check if the token is valid.
Q: Good approach and possible?
The CLI-approach...
...requires my application to know a SSH private key registered at Jenkins.
It would be good approach, if Jenkins would support adding SSH Keys. My application could generate a SSH key pair (with random) password and automatically store the public key on the users behalf within Jenkins.
I think this is the right way, even though it requires to extend Jenkins and maybe the authentication plugins.
Q: Is this approach possible and secure enough?
Q: Are there other approaches?
I think Jenkins should implement an OAuth endpoint for authorization (in case of the crowd plugin, it then has to delegate the authorization to Crowd) or completely detach user management from its core. Am I wrong?
Please help me improving this question, if neccessary. I can imagine that I've mixed two problems and didn't described by goal clear enough.
Note: Edited this question ~1 hr after creation (see my 1st comment).