Jenkins CI/CD for Github using Deploy Keys

by

When setting up a continuous integration and deployment (CI/CD) pipeline using Jenkins and GitHub deploy keys, you can use the Jenkins GitHub plugin to interact with the GitHub repository. Here are the general steps for setting up a basic Jenkins CI/CD pipeline using GitHub deploy keys:

  1. Set up a Jenkins server: This can be done by installing Jenkins on a server or by using a cloud-based version, such as Jenkins on Azure or AWS.
  2. Create a new ssh key pair on the Jenkins server: This key will be used as the deploy key for the GitHub repository.
  3. Add the public key to the GitHub repository:
    1. On the GitHub website, navigate to the repository where you want to add the deploy key.
    2. In the repository’s menu, click on “Settings”.
    3. In the left sidebar, click on “Deploy keys”.
    4. Click on “Add deploy key” button.
    5. In the “Title” field, give the key a name that will help you identify it later.
    6. In the “Key” field, paste the entire contents of the public key that you want to add.
    7. (Optional) check “Allow write access” checkbox if you want to allow Jenkins to push the code to the repository.
    8. Click on “Add key” button.
  4. Install the Jenkins GitHub plugin: This plugin allows Jenkins to interact with GitHub, including the ability to trigger builds when code is pushed to a repository.
  5. Create a new Jenkins job: This job will be used to build and test the code from your GitHub repository. You can configure the job to use a build script, such as a Makefile or a Maven script, to build and test the code.
  6. In the Jenkins job configuration, specify the repository URL and any branches you want to build. You can also configure the build triggers, such as building on every push to the repository or on a schedule.
  7. To set up continuous deployment, you’ll need to add another step to the Jenkins job. This step can be configured to deploy the code to a staging or production environment, depending on your requirements.
  8. Ensure that the Jenkins server uses the private key that you added as a deploy key to access the repository
  9. Finally, you can add post-build actions to Jenkins job such as sending notifications to a slack channel, email or other applications.

Limitations of using Deploy Keys

Using GitHub deploy keys can be a convenient way to grant read-only or read-write access to a specific GitHub repository, but there are some limitations to keep in mind:

  1. One deploy key per repository: Each deploy key can only be associated with one repository, which can make managing access to multiple repositories more cumbersome.
  2. Limited permissions: Deploy keys can only be granted read-only or read-write access to a repository, which can limit their use in a continuous integration and deployment (CI/CD) pipeline.
  3. No User-level access: Deploy keys do not have access to all the features that a user account does, such as creating and managing issues or pull requests.
  4. No Access to the Github organization: Deploy keys can not be added to Github organization repositories or repos within that org, it only can access the specific repository where it was added.
  5. Limited Revocation: You can only revoke a deploy key by removing it from the repository, there are no granular access control or permissions, which can make it harder to maintain security.
  6. Limited Auditing: Deploy keys don’t provide detailed logging or auditing of user activities. This can make it more difficult to track down issues or identify suspicious activities.

Deploy Keys vs CI/CD github account

Deploy keys and CI/CD GitHub accounts are two different methods for allowing Jenkins to access a GitHub repository.

  1. Deploy keys: The advantage of deploy keys is that they can be easily revoked and also it does not require creating a Github account.
  2. CI/CD GitHub accounts: A CI/CD GitHub account is a separate GitHub account that is used specifically for your CI/CD pipeline. This account can be granted access to multiple repositories and can be used to trigger builds and deployments when code is pushed. The advantage of using a separate account is that you can easily revoke access to all of the repositories it has access to, if necessary. Additionally, you can use the access levels like branch protection and commit status check features provided by Github to ensure security and quality.

Which method you choose will depend on your specific needs and how you want to manage access to your GitHub repositories. If you have a small number of repositories, you can use deploy keys. But if you have a large number of repositories and you want to be able to manage access more easily, you may want to use a separate CI/CD GitHub account.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.