Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Proposal: being able to temporarily expose information to another team #1209
What challenge are you facing?
When operating in a multi-tenant environment, there are times when one team with a private pipeline/job/etc. may want to request help from another team. A couple examples of this are:
A Modest Proposal
For the first case it's tempting to reach for a "god view" (#1012), however this would mean that if anyone admin team has their auth compromised, or simply forgets to log out, it'd result in mass credential leakage.
If we more tightly scope the exposing of information, i.e. on a case-by-case basis for the amount of time that it's actually needed, this risk is mitigated. We're thinking this may also be all that's needed for the second case.
So, our initial idea is to have a way for a user to temporarily expose something in the web UI (e.g. a build) to another team, for a certain amount of time (e.g. 24 hours). A "flare gun" icon seems appropriate. This will be read-only, though we're considering allowing use of
Oftentimes, people are trying to expose information about a failing build, so they can get help with debugging their current issue. To the person supporting them, though, this often requires them to know information about the rest of the pipeline that feeds into that failing build. So there's a potential use case for exposing a build and exposing a pipeline.
We did some initial research using mocks and found interesting information. However, we'd also like to start deploying beta features to our internal research-focused multi-tenant environment (Wings) and gathering real user feedback, which can drive our product decisions. Due to both of these we are going to try the simplest approach and do:
This matches our most likely Wings use case, so we are going to attempt to do this, gather user feedback, and use that to determine the next steps for this feature.
I believe this lacks a major feature set (and really the thrust of my issue behind #1012):
Feature's an Admin Need's
The idea behind #1012 was to enable admins to operate the system while this feature enables admins to help users. Both are good, but, the former is more important IMO as it affects all users rather than a subset.
As an admin I (the main team) can modify the login methodology for all teams and list all teams. So it is trivial for an attacker who has compromised admin credentials to add himself to all teams and dump there credentials. In many (if not most) cases if an admins credentials are compromised so are the credentials to access the database. In addition troubleshooting a team particular issue often requires physical access to the node anyways. Which again makes the secrets inherently accessible. Strong security models will have multi-factor authentication for admin credentials. Blocking the power of someone who inherently already has complete access makes little sense.
The way to prevent the leakage of secrets is instead to encrypt them, with a key, outside the control or access of the admin. If a team has secrets they are concerned about an admin (or a adversary who has gained admin access) seeing a proper pattern might look something like this:
In this model the admin only has access to the secrets of a given team with explicit permission. In today's Concourse the admin has access to secrets stored in any team regardless, as they can simply add a manual login to the teams. Most admins will also have physical access to the un-encrypted database.