Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add new options to GitHub App credentials to allow dynamic restrictions of the repositories and permissions available to installation access tokens in some contexts #822

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 39 additions & 2 deletions docs/github-app.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -87,8 +87,9 @@ Fill out the form:
- App ID: the github app ID, it can be found in the 'About' section of your GitHub app in the general tab.
- API endpoint (optional, only required for GitHub enterprise this will only show up if a GitHub enterprise server is configured).
- Key: click add, paste the contents of the converted private key
- Advanced: (optional) If you've installed your same GitHub app on multiple organizations you need the next step
* Owner: the name of the organisation or user, i.e. jenkinsci for https://github.com/jenkinsci
- Advanced: (optional):
* Repository access strategy: Controls what GitHub repositories will be accessible to these credentials in untrusted contexts (see below for details)
* Default permissions strategy: Controls what GitHub permissions will be accessible to these credentials in untrusted contexts (see below for details)
- Click OK

=== link:https://github.com/jenkinsci/configuration-as-code-plugin[Configuration as Code Plugin]
Expand Down Expand Up @@ -135,6 +136,42 @@ Verify at the bottom of the scan log it says:
Finished: SUCCESS
----

=== Enhancing security using repository access strategies and default permissions strategies

GitHub App Credentials offer advanced configuration options that can provide additional security in some scenarios.
In particular, when GitHub App Credentials are used by an Organization Folder or Multibranch Pipeline, these strategies may dynamically restrict the accessible repositories and permissions available to the credentials when they are accessed in untrusted contexts, such as when they are accessed by a `withCredentials` step in one of the individual Pipeline jobs.
See TODO for additional information on why it may be beneficial to limit credentials in this way.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs to be replaced with a reference to jenkins-infra/jenkins.io#7770.

These strategies do not apply when using the credentials in trusted contexts, such as during organization folder scans and branch indexing.
Note also that Jenkins users who have Job/Configure permission in a context where the credentials are available are considered trusted and can bypass these strategies by configuring jobs as desired.
In trusted contexts, the generated access tokens will have the same access as configured for the app installation in GitHub.

The following repository access strategies are available:
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do these strategies make sense? Do they work they way you would expect? Do you think the default is appropriate? Is there any other strategy that you think should be supported?

* **Infer owner and allow access to all owned repositories** (Default)
* The credentials may only be used in contexts where a GitHub organization can be inferred, such as Organization Folders and Multibranch Pipelines
* The access tokens generated in untrusted contexts will be able to access all repositories in the inferred GitHub organization that are accessible to the GitHub App installation.
* **Infer accessible repository**
* The credentials may only be used in contexts where a GitHub organization and repository can be inferred, such as Organization Folders and Multibranch Pipelines
* The access tokens generated in untrusted contexts will only be able to access the inferred repository
* **Specify accessible repositories**
* The access tokens generated in untrusted contexts will be able to access the repositories specified statically in the credential configuration
* If the GitHub app is installed in a single organization, the owner field may be left blank empty, in which case that organization will be accessed automatically
* Leaving the repositories field empty will result in all repositories accessible to the configured owner being accessible

The following default permissions strategies are available:
* Read-only access to repository contents
* The access tokens generated in untrusted contexts will only be able to read the repository contents
* Read and write access to repository contents
* The access tokens generated in untrusted contexts will only be able to read and write the repository contents
* All permissions available to the app installation (default)
* The access tokens generated in untrusted contexts will have the same permissions as the app installation in GitHub
Comment on lines +165 to +166
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whether this is the best default, I am not sure. I think for the default we just want to choose whatever is least surprising. Perhaps read-only access would be more appropriate as a default.


==== Repository access strategies and Pipeline libraries

Repository inference for GitHub App Credentials does not work when checking out Pipeline libraries.
If you have a GitHub App Credential for an Organization Folder or Multibranch Pipeline whose individual Pipeline jobs access a Pipeline library, the contextually inferred repository for the library checkout will be the repository for the Pipeline job rather than the library.
This means that the library will be inaccessible if you use an inference-based repository access strategy which only provides access to a single contextually-inferred repository, or if the Pipeline library is in a different GitHub organization than the repository being built.
For now, in this case, you either need to use a less restrictive strategy for the GitHub App credential, such as "Infer owner and allow access to all owned repositories", or you can define a second credential specifically for the Pipeline library which uses "Specify accessible repositories" and only allows access to the repository for the Pipeline library.

=== Help?

Raise an issue on link:https://issues.jenkins-ci.org/[Jenkins jira]
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -227,7 +227,7 @@
} finally {
Connector.release(connector);
}
} catch (IllegalArgumentException | InvalidPrivateKeyException e) {
} catch (IllegalArgumentException | IllegalStateException | InvalidPrivateKeyException e) {

Check warning on line 230 in src/main/java/org/jenkinsci/plugins/github_branch_source/Connector.java

View check run for this annotation

ci.jenkins.io / Code Coverage

Not covered line

Line 230 is not covered by tests
String msg = "Exception validating credentials " + CredentialsNameProvider.name(credentials);
LOGGER.log(Level.WARNING, msg, e);
return FormValidation.error(e, msg);
Expand Down Expand Up @@ -261,8 +261,7 @@
}

/**
* Resolves the specified scan credentials in the specified context for use against the specified
* API endpoint.
* Retained for binary compatibility only.
*
* @param context the context.
* @param apiUri the API endpoint.
Expand All @@ -281,6 +280,9 @@
* Resolves the specified scan credentials in the specified context for use against the specified
* API endpoint.
*
* <p>Callers of this method must not expose the credentials to unprivileged users for
* uncontrolled usage.
*
* @param context the context.
* @param apiUri the API endpoint.
* @param scanCredentialsId the credentials to resolve.
Expand All @@ -306,9 +308,20 @@
githubDomainRequirements(apiUri)),
CredentialsMatchers.allOf(
CredentialsMatchers.withId(scanCredentialsId), githubScanCredentialsMatcher()));

if (c instanceof GitHubAppCredentials && repoOwner != null) {
c = ((GitHubAppCredentials) c).withOwner(repoOwner);
// Note: We considered adding an overload so that all existing callers in this plugin could
// specify an exact repository and granular permission, but decided against it. This method
// should only be called in contexts where the credential could not be exposed to users
// other than those who were able to create/configure whatever is using the credential in
// the first place. Those users would be able to steal the GitHub App refresh JWT, which
// they can then use to generate their own credentials, so dynamic limitations in this
// context have no benefits, and would unnecessarily increase the size of the connection
// cache because the cache keys are distinct for every context.
final var usageContext = GitHubAppUsageContext.builder()
.inferredOwner(repoOwner)
.trust()
.build();
return ((GitHubAppCredentials) c).contextualize(usageContext);
}
return c;
}
Expand Down Expand Up @@ -368,12 +381,15 @@
password = null;
gitHubAppCredentials = (GitHubAppCredentials) credentials;
hash = Util.getDigestOf(gitHubAppCredentials.getAppID()
+ gitHubAppCredentials.getOwner()
+ gitHubAppCredentials.getAccessibleRepositories()
+ gitHubAppCredentials.getPermissions()
+ gitHubAppCredentials.getPrivateKey().getPlainText()
+ SALT); // want to ensure pooling by credential
authHash = Util.getDigestOf(gitHubAppCredentials.getAppID()
+ "::"
+ gitHubAppCredentials.getOwner()
+ gitHubAppCredentials.getAccessibleRepositories()
+ "::"
+ gitHubAppCredentials.getPermissions()
+ "::"
+ gitHubAppCredentials.getPrivateKey().getPlainText()
+ "::"
Expand Down
Loading
Loading