Per-installation security?


#1

From a security standpoint, having a single key for an integration is really problematic. If that key gets compromised, an attacker will gain access to all accounts where the integration is installed.

I really want a per-installation secret which I would use instead of the Integration key to generate Installation Access Tokens. They key would be generated at installation time, and it would be my responsibility to store it, just as with integration keys.

Are there any plans to provide that capability?


#2

This is an interesting idea, @b-daniels.

How would the secret be generated, and how would you retrieve it? It seems like you would still want an API endpoint to retrieve those secrets, which be based on your installation-specific PEM. That technique would push the vector of compromise down to the PEM, but it would still exist.

Or did you imagine something else?


#3

I assume it would be part of the installation flow on the account. The flow would be initiated from the Integration’s website, and the generated key would be pushed back to the integration’s callback hook. The Integration implementation would then store the key.

The primary value here is isolation, and it’s a big one. Really, the lack per-account credentials is kind of a deal killer for us from a security standpoint. The lack of a self-service way for repo admins to turn on the integration is also a problem.


#5

Just realized I didn’t directly address part of what you said… We very
specifically would not want a way to retrieve the secrets. If the keys get
lost or compromised, we’d want the user to go back to the installation and
generate a new key to give to us (or we could initiate the flow on our end,
just like OAUTH).

It could presumably also be an optional feature to ease migration. If an
installation key exists, it must be used, otherwise the integration key
would be required.