Dies ist ein zustandsloser GitHub-API-Proxy, der die Erstellung und Verwendung von zugriffsbeschränkten GitHub-API-Tokens ermöglicht.
Im Grunde handelt es sich um die Identitäts- und Zugriffsverwaltung für GitHub-API-Tokens.
Die API-Tokens von GitHub ermöglichen keine detaillierte Kontrolle darüber, welche Aktionen ein Token ausführen kann (siehe dieses Dear GitHub-Problem). Beispielsweise müssen Sie grundsätzlich ein Token erstellen, das die vollständige Kontrolle über ein Repository hat, damit ein Token lediglich Labels auf Probleme anwenden kann.
Dies ist im Maßstab problematisch. Wenn viele Jobs, Prozesse und/oder Bots mit der GitHub-API interagieren, erhöht sich die Wahrscheinlichkeit, dass ein Token kompromittiert wird, und Token mit weitreichenden Berechtigungen haben sehr schwerwiegende Folgen.
Mit diesem Proxy können Sie API-Token mit fein abgestuften Berechtigungen (einen magischen Token ) erstellen und dann mithilfe dieser magischen Token über einen Proxy mit der GitHub-API kommunizieren. Der Proxy validiert das magische Token, um die angeforderte Aktion ausführen zu können, und leitet die Anforderung dann mithilfe des echten GitHub-API-Tokens an die GitHub-API weiter.
Dieser Proxy benötigt keinen Backup-Speicher und speichert seinen gesamten Status im Magic Token selbst.
Der Proxy verwendet asymmetrische Kryptografie (ein öffentliches und privates Schlüsselpaar) und JWTs, um seinen Zustand im magischen Token zu kodieren.
Bei jedem magischen Token handelt es sich um ein einfaches JWT, das mit dem privaten Schlüssel des Proxys mit den folgenden Ansprüchen signiert ist:
{
"iat": 1541616032,
"exp": 1699296032,
"github_token": "[long encrypted key]",
"scopes": [
"GET /user",
"GET /repos/theacodes/nox/issues"
]
}
Der Anspruch github_token
ist eine verschlüsselte Version des rohen GitHub-API-Tokens. Es wird mit dem öffentlichen Schlüssel des Proxys verschlüsselt, sodass nur der Proxy selbst es entschlüsseln kann (mit seinem privaten Schlüssel).
Der Scopes-Anspruch bestimmt, worauf der Magic-Token Zugriff hat. Dieser Proxy verfügt über eine grundlegende, rudimentäre Bereichsimplementierung, die unten beschrieben wird, Sie können jedoch jede gewünschte Bereichsstrategie implementieren.
Das JWT wird vom Proxy selbst mit seinem privaten Schlüssel generiert und signiert. Dies bedeutet, dass der Inhalt nicht manipuliert werden kann, ohne dass das JWT ungültig wird.
Standardmäßig verfügt dieser Proxy über eine einfache Bereichsstrategie, die das folgende Format verwendet:
METHOD /url/pattern
Wobei METHOD
GET
, POST
, PUT
usw. sein kann und /url/pattern
ein beliebiger regulärer Ausdruck sein kann, der zum Überprüfen der URL verwendet wird.
Um beispielsweise ein Token zu erstellen, das Zugriff auf alle Issues eines Repositorys in someorg
hat, könnten Sie Folgendes tun:
GET /repos/someorg/.+?/issues
TODO
Dies ist kein offizielles Google-Produkt, weder experimentell noch anderweitig. Dies ist kein Allheilmittel für die Sicherheit. Bei der Nutzung dieses Projekts übernehmen Sie alle Risiken.