redhat-actions/openshift-github-connector

OpenShift <--> GitHub connector app

openshift-github-connector's Issues

Add OpenShift authentication layer

Internal tech debt

• How to make workflows bot-readable so we can detect & edit them (versioning?)
• Mapping of ApiEndpoints to ApiRequests and ApiResponses
  • Integrate with fetchJSON/DataFetcher
• TypeScript base pathing to remove relpath imports for server
• TypeScript base pathing to remove relpath imports for client

Footer

It would be nice if there was a footer with some branding, documentation links, etc.

Install using operator instead of Helm chart

Manage self-hosted runners from app UI

Create session from already installed app

Right now if a user session expires (or they use another browser, etc) the only way to get a session back is to uninstall and then reinstall the configured app, or change its repository selection so the setup callback is invoked.

How can we get a user to point the connector to an existing, already installed app, without having to mess with the installation?

Fix namespacing of SA tokens

Presently the connector uses its service account to authenticate for all k8s api requests. This means it is limited to viewing & managing resources in its own namespace.

The service account tokens copied into repository Actions secrets through the Connect Repositories feature are also limited to that namespace. This also means that all connector users can do stuff in the connector's namespace, even if they don't have access to it - because the service account that their Actions workflows are using does have access.

This design does not make any sense.

When creating SA tokens for Actions, the user have to select a namespace. The user would then have to provide a service account in that namespace that would own the token (or select one from a list). The user's authentication token would be used to manage those SA tokens (the connector could only do it if it had cluster-wide powers, eg if it were an operator), so consequently the user would need permissions on that namespace.
This way, the user cannot use the connector's SA tokens to gain access to the connector's namespace, unless the cluster RBAC allows it.

Create a secret into cluster with app auth for other tools (gitops) to reference

the token should have permissions to read from the repository and put up pull requests

openshift-github-connector 1.16.0 returns 401 and can not fetch valid token

Version

openshift-github-connector 1.16.0

Openshift version - 4.8.20

Describe the bug

The callback url returns 401 and unable to get token for the user.

Steps to reproduce, workflow links, screenshots

• Install the openshift-github-connector chart via Helm as instructed in the README file.
• Open the route created by the chart.
• It redirects to the Openshift login page, provide the credentials to login.
• It prints error

{"success":false,"message":"Failed to obtain access token","status":401,"statusMessage":"Unauthorized","severity":"danger"}

GHE support

In some places, github.com is hardcoded. In other places, it uses a function, which just returns github.com.

There needs to be a way for the owner to tell the connector to use a GHE instance instead of github.com, and that change should persist for all users.

Backend proxy for console

Since the frontend host no longer matches the backend's when running as a console plugin, we need some kind of proxy solution.

Image registry

Right now, the starter workflow can be added. But it fails, because there's no image registry set up.

We have to provide the user a frontend for setting up an image registry. Then, we have to insert the registry hostname and username into the starter workflow, and create a REGISTRY_PASSWORD secret.

Installing app after creating should be optional

The connector 'expects' a user to have an installation. Installations should be separated from apps, such that a user can view their created apps without installing any.

Check if all requested permissions are actually still needed with PR flow

Webhooks

The webhook secret is stored, and there is an endpoint which receives webhooks.

The webhook endpoint needs to validate against the secret.

But past that, what can we do with webhooks?

Repo lists should be searchable

a continuation of #10, it's hard to find a repo if you have a lot of them selected.

Add titles to pages

All pages have the same title right now.

Inject workflow steps into existing workflow files, or create a new one

eg. inject an oc-login step at the start of a workflow, which references created secrets

Navigation header

Once the setup wizard is finished, there needs to be a navigation header that lets the user jump between pages and view their app and session state.

Investigate console integration

Investigate using the console dynamic plugin SDK to plug the connector into the openshift console.

Create secrets at the org level

A user can create secrets into any repository they've installed the app on.

It should be possible to create secrets into an org, too, but this requires a different permission scope and a slightly different github API endpoint.

App screws up if lots of repos are enabled

Only 30 repos can be retrieved per github API request. So if you enable more than 30 repos, they will get cut off. The requests have to be paginated.

The UI that lists repos also has to be updated to have a max-height, and be scrollable and searchable.

Add workflows using PRs instead of just committing them to main

Support for the OpenShift internal image registry