I followed the instructions given in the CloudBees documentation, but my git pushes (at Bitbucket) did not trigger new builds in Jenkins. Roughly,
In Jenkins, create a new build project, and select "Trigger builds remotely".
Generate an authentication token, then save the project.
Obtain API token at https://<account>.ci.cloudbees.com/user/<your-email>/configure
In Bitbucket, add a Jenkins service with the following options
Endpoint: https://<your-email>:<apitoken>#<account>.ci.cloudbees.com
Token: <from-step-2>
The documentation is probably outdated.
At the "People" section in Jenkins, it appears that there are two users, one named "user", and another named "user#domain.com" (where "user" and "domain" are replaced appropriately by components in your email address.) When I created the build project, it was created under "user", and so "user#domain.com" did not have the rights to trigger a build.
Thus, the correct endpoint should be
https://<the-user-portion-of-your-email>:<apitoken>#<account>.ci.cloudbees.com
Note that the api token should be obtained from
https://<account>.ci.cloudbees.com/user/<the-user-portion-of-your-email>/configure
Related
TLDR -
I want users of my employer's organization who install my CLI tool to be able to use it to run commands that use the GitHub rest api that require permissions the user doesn't personally have, while restricting the user from using the CLI tool to perform unintended actions with the elevated permissions needed by the CLI tool. Is there a way to create a CLI tool that 1. uses permissions the users of the CLI tool don't have while at the same time 2. prevents those users from using the CLI tool's elevated permissions to perform unintended actions?
Extended -
I'm building a CLI tool for my employer's organization so that the organization members can automatically create a new branch and simultaneously add branch protection and create a PR. As far as I know, updating branch protection with the GitHub API requires admin access. However, not all of the users who use this CLI tool will personally have those permissions for their user account. But a user in the organization should still be able to use the CLI tool (which uses permissions the user potentially doesn't have).
I thought about using a personal access token so that the users aren't using a single set of centralized credentials (github app creds), but then the CLI tool would have access to at least one of the user's personal repositories and potentially wouldn't have the required permissions required by the CLI tool.
So is there a way to build a tool as a package that can be installed on a users machine that...
has permissions that the user of the tool potentially doesn't have and
prevents the user from doing anything unintended. e.g. the tool (which has admin permissions) can add branch protection rules, but the user shouldn't be able to use the tool's elevated permissions for anything else - e.g. getting the interaction limits for an organization
prevents the user from using the tool in any organization repo they don't have access to.
Ok, that's the gist of it, but I will go into more detail in case that helps.
So currently I'm using a GitHub app and giving it the required permissions (e.g. admin read/write for branch protection rules). I'm using octokit to authenticate to the GitHub API with the GitHub App. To do this, I'm passing in the app id, private key, and the installation id.
package structure
- .env
- authenticate_and_do_stuff.ts
authenticate_and_do_stuff.ts
// authenticate with GitHub app creds
// see https://github.com/octokit/octokit.js#authentication
const octokit = new Octokit({
authStrategy: createAppAuth,
auth: {
appId: process.env.GITHUB_APP_APP_ID,
privateKey: process.env.GITHUB_APP_PRIVATE_KEY,
installationId: process.env.GITHUB_APP_INSTALLATION_ID,
},
});
// create branch, add branch protection, etc.
octokit.rest.do stuff ...
This isn't ideal because then the user who installs the package needs those environment variables to be authenticated. And once they have those creds, they would be able to use them to do other things they potentially don't have permissions for (e.g. with the admin read/write permission the GitHub app has permissions for). So my thought is to have the user provide the authentication credentials that aren't the Github app credentials. This way, each user is using different credentials they provide. As for the reasons stated above, personal access tokens cannot be used. So the ideal situation is as follows -
A user installs the package - npm i my-github-cli-tool.
- node_modules
|
--- my-github-cli-tool
|
--- authenticate_and_do_stuff.ts
|
- some_custom_app_file.ts
- .env.cli_tool
They generate credentials and put them into a custom env file e.g. .env.cli_tool.
They use the CLI tool to create a new branch in an organization repo they have access to, create the branch protection rules (with the admin read/write access that the user doesn't have, but the credentials in step 2 has).
If the user tries to alter the cli tool or use the credentials in step 2 to use it to access repos they don't have access to or perform other actions with the admin read/write permissions, they shouldn't be able to.
If I stick with using the GitHub app, the source code on the user's machine has to get the credentials somehow. And those credentials need to have elevated permissions that the user might not have. So if these credentials are exposed to the source code on the user's machine, doesn't that mean the user can just grab those credentials and use them for nefarious purposes?
I am currently trying to build my first pipeline. The goal is to download the git repo to a server. In doing so, I ran into the problem that I have 2FA enabled on my account. When I run the pipeline I get the following error message:
remote: HTTP Basic: Access denied. The provided password or token is incorrect or your account has 2FA enabled and you must use a personal access token instead of a password.
Pipeline:
download_repo:
script:
echo "Hallo"
As far as I understand I have to use a PAT because I have 2FA enabled. But unfortunately I have not found any info on how to use the PAT.
To access one of your GitLab repository from your pipeline, you should create a deploy token (as described in token overview).
As noted here:
You get Deploy token username and password when you create deploy token on the repository you want to clone.
You can also use Job token. Job token inherits permissions of the user triggering the pipeline.
If your users have access to the repository you need to clone you can use git clone https://gitlab-ci-token:${CI_JOB_TOKEN}#gitlab.example.com/<namespace>/<project>.
More details on Job token is here.
The OP Assassinee adds in the comments:
The problem was that the agent could not access the repository.
I added the following item in the agent configuration:
clone_url = "https://<USER>:<PAT>#gitlab.example.com"
This makes it possible for the agent to access the repository.
We've been having some issues getting Fastlane Match to work in Gitlab CI using access tokens from within an existing CI pipeline.
The setup:
Repo for storing the certs / profiles: set up during fastlane init. We'll call this the "Cert Repo".
Repo for our React Native project: uses fastlane to handle builds/uploading to App Center and Testflight. We'll call this the "Project Repo"
Setup of match via match init went fine. We did the setup via terminal on the build server.
In our Matchfile:
gitlab_project("PATH_TO_CERT_REPO_HERE")
storage_mode("gitlab_secure_files")
app_identifier(["APP_IDENTIFIER_HERE"])
username("APPLE_ACCOUNT_USERNAME_HERE")
keychain_password("KEYCHAIN_PW_HERE")
team_id("TEAM_ID_HERE")
We had to pass in some env vars to the command for our gitlab enterprise api url (as "CI_API_V4_URL" and the Cert Repo access token as "PRIVATE_TOKEN"
We ran match for all cert/profile types we needed and they all uploaded to the secure files section of the Cert Repo correctly.
The Problem:
Our branches in the Project Repo use Gitlab CI to run various scripts and call a fastlane lane that will do the versioning, certs/profiles, and then upload the build to App Center or Testflight.
When we run match in readonly mode in our lane this way, match is failing with a 401 error.
Looking into the source for match and secure files for storage, it seems if you have a PRIVATE_TOKEN env var set, match will give a warning that you have both JOB_TOKEN and PRIVATE_TOKEN set and it will use the JOB_TOKEN.
The JOB_TOKEN is provided via Gitlab CI itself.
My guess is the JOB_TOKEN for this pipeline is not a valid token to authenticate against the CERT_REPO, which match needs to download the certs/profiles.
How is this supposed to work if I can't pass in a token for match to use for the CERT_REPO?
If we were using normal git storage, you can pass in the git_basic_authorization argument and give the base64 encoded "username:acces_token" string, which I'm assuming would solve the problem.
But using gitlab_secure_files, you can only use tokens.
Before we go and redo everything to use git storage and not gitlab secure files, can someone explain what we're missing here?
How is match supposed to authenticate with the Cert Repo from within the Project Repo in CI if the token it has is for the Project Repo? Doesn't it need the token for the Cert Repo to authenticate?
I can ask this question in many ways, like
How to configure Jenkins credentials with Github Personal Access Token
How to clone Github repo in Jenkins using Github Personal Access Token
So this is the problem
The alternate solution that I am aware of
SSH connection
username password configuration in Jenkins. However,
use of a password with the GitHub API is now deprecated.
But My question is how to setup Github connection with Jenkins using Personal Access Token
[UPDATE]
The new solution proposed by git is
https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/
Which says:
Beginning August 13, 2021, we will no longer accept account passwords
when authenticating Git operations and will require the use of
token-based authentication, such as a personal access token (for
developers) or an OAuth or GitHub App installation token (for
integrators) for all authenticated Git operations on GitHub.com. You
may also continue using SSH keys where you prefer.
What you need to do:
https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/#what-you-need-to-do-today
Basically, change the add URL as
https://<access token>#github.com/<userName>/<repository>.git
Something like this
https://<access token>#github.com/dupinder/NgnixDockerizedDevEnv.git
and set the credentials to none.
Thanks to #Gil Stal
[OLD Technique]
After many discussion on multiple threads from Stackoverflow
I found one thread that is useful.
Refer to this answer:
https://stackoverflow.com/a/61104603/5108695
Basically
Personal access token can be used as a password, as far as Jenkins is concerned at least. I added new credentials to the credential manager.
Go to Jenkins
Go to credentials > System > Global credentials > Add credentials a page will open.
In Kind drop-down select Username and password.
In User put a non-existing username like jenkins-user or user.
Add Personal Access Token in the password field
Now start configuring your project.
source code management tab, select new configured credentials from Drop-down near credential Under Repository URL
So this is how we can configure or setup Authentication between Jenkins and Github using Personal Access Token
References:
Git Clone in Jenkins with Personal Access Token idles forever
Change jenkins pipeline to use github instead of gitlab
The accepted answer wont work anymore because of this: https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations.
You will need to:
Change the URL of the repo to: https://<access token>#github.com/<user-name>/<repo-name>.git (Replace every <...> with the real parameters)
Set the credentials to none.
As of August 2021 the answer posted by Dupinder Singh is accurate. The only thing I would add is that if you are part of a team, the url format appears to be a bit different. This is what worked for me:
https://<access token>#github.com/<team>/<repo>.git
for example
https://ghp_6dh3jdk394jsmbh299jjdg20fh87hd83ksk39#github.com/MyKuleTeam/KuleGuyCode.git
Note that if you use a personal access token you don't need to have any github credentials stored in jenkins.
As for credentials for Jenkins Github Plugin, please be aware only Personal access tokens are now accepted by this plugin.
To generate such a token, follow the Github docs (e.g. here). Don't save it, it can be regenerated in Github and updated in Jenkins if lost or when migrating to a different server.
To add the token do Jenkins credentials store, go to <JENKINS_URL:PORT>/credentials/store/system/domain/_/newCredentials and select Kind "Secret text" (not the default "Username and password"), then paste the token as Secret and choose some ID.
Testing: the credential should appear on the list of Credentials at <JENKINS_URL:PORT>/credentials/ and be selectable from the drop-down list at <JENKINS_URL:PORT>/configure/, where pressing the "Test connection" button should display "Credentials verified for user <GITHUB_USER>".
More info: see the Github plugin docs.
Caveats: Git Plugin has its long-standing issues, so if the newly created "Secret text" does not appear in your pipelines, try if this solution helps (with "the user who triggered the build" considered safer than "SYSTEM"):
client-and-managed-masters/why-credentials-are-not-listed-in-the-git-scm-section
There is (yet another) way to do this as of 2020/04 which is supposed to be superior to personal access tokens. The best part is that you can continue using a username/password-style credential, and the plugin will handle authenticating with GitHub in the background.
Benefits include:
Larger rate limits - The rate limit for a GitHub app scales with your organization size, whereas a user based token has a limit of 5000 regardless of how many repositories you have.
User-independent authentication - Each GitHub app has its own user-independent authentication. No more need for 'bot' users or figuring out who should be the owner of 2FA or OAuth tokens.
Improved security and tighter permissions - GitHub Apps offer much finer-grained permissions compared to a service user and its personal access tokens. This lets the Jenkins GitHub app require a much smaller set of privileges to run properly.
Access to GitHub Checks API - GitHub Apps can access the the GitHub Checks API to create check runs and check suites from Jenkins jobs and provide detailed feedback on commits as well as code annotation
Links:
https://www.jenkins.io/blog/2020/04/16/github-app-authentication/
https://github.com/jenkinsci/github-branch-source-plugin/blob/master/docs/github-app.adoc
I am using Fusion Auth as an auth backend for my project.
After starting up the container as shown here(https://fusionauth.io/docs/v1/tech/installation-guide/docker), if we open the URL(Ex: http://localhost:9011) we need to create an admin user and then we will be able to create Application, API Key, Lambda.
As my project doesn't involve UI interaction, I wanted to create Application without involving UI interaction(i.e., setup-wizard).
I was unable to find an API that relates to setup-wizard.
As I saw Since this is your own private instance of FusionAuth, you need to create a new administrator account that you will use to log in to the FusionAuth web interface. in setup-wizard I thought this is required only for UI, So I tried to create Application using this(https://fusionauth.io/docs/v1/tech/apis/applications#create-an-application) API, but it is returning a 401(Unauthorized).
Can someone help me to either create an application without authentication or bypass setup-wizard?
The FusionAuth Kickstart does exactly what you need. It will allow you to pre-define the configuration that you require in a JSON file and then the system will bootstrap itself automatically.
The base use case it to provision an API key which would allow you to programmatically configure the rest of the system by using APIs after an API key has been created.
{
"apiKeys": [{
"key": "a super secret API key that nobody knows"
}]
}
You also have the option of building your entire configuration in the Kickstart definition. There are a bunch of examples and walk throughs on the Kickstart installation guide.
Good luck!