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.
Related
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
I have deployed the Spinnaker services and set its authentication by using google oauth2.0 services.
Now I wanna access the gate api by writing custom nodejs javascripts.
So the question is I donnot know how to let my request/http scripts access the gate apis without interactive google auth actions, like using something like setting a token in the request's header?.
I have read the docs about IAP part, but I really do not quite understand what I need to setup in Spinnaker and how can I write my request scripts.
Any help would be very appreciated.
Thanks in advance.
since you have already integrated OAuth in Spinnaker, verify if your Gate services open. Spinnaker Gate would open on port 8084 by default. The Spinnaker Gate url would be something like this https://:8084/swagger-ui.html#/ or use "http>://" if you are on http.
It would ask you to login. Try opening it and if it opens your Gate is working fine. you can try out any Spinnaker API too from this swagger page. It should work without any re-login as you are already logged in.
now, to run APIs from code (or any script) you need to have an access token passed in the header. follow any standard oauth 2 document to see the procedure. you can take cues from here. https://www.jhanley.com/google-oauth-2-0-testing-with-curl/
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.
I just successfully went through the Cognito setup through AWS console, which is a manual process. I wanted to code it up next, i.e.,
I wanted to setup and configure my Cognito with Cloudformation config file AWS AWS::Cognito::UserPool. However, I don't see a field that define the open id connect providers (i.e, the Facebook and Google as identity provider).
Is there a way to do so?
I am on the Cognito team and this is not possible at this point. However, it is on our roadmap to bring CloudFormation support up to speed to all the features we have launched recently.
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).