quay/jwtproxy

An HTTP-Proxy that adds AuthN through JWTs

Project Quay

⚠️ The master branch may be in an unstable or even broken state during development. Please use releases instead of the master branch in order to get stable software.

Project Quay builds, stores, and distributes your container images.

High-level features include:

• Docker Registry Protocol v2
• Docker Manifest Schema v2.1, v2.2
• AppC Image Discovery via on-demand transcoding
• Image Squashing via on-demand transcoding
• Authentication provided by LDAP, Keystone, OIDC, Google, and GitHub
• ACLs, team management, and auditability logs
• Geo-replicated storage provided by local filesystems, S3, GCS, Swift, and Ceph
• Continuous Integration integrated with GitHub, Bitbucket, GitLab, and git
• Security Vulnerability Analysis via Clair
• Swagger-compliant HTTP API

Getting Started

• Explore a live instance of Project Quay hosted at Quay.io
• Watch talks given about Project Quay
• Review the documentation for Red Hat Quay
• Get up and running with our getting started guide for developing or deploying Quay
• Deploy on Kubernetes using the Quay Operator

Community

• Mailing List: [email protected]
• IRC: #quay on libera.chat
• Bug tracking: JBoss JIRA
• Security Issues: [email protected]
• Community meetings held the first Wednesday of every month 11:00 AM EST: meeting link

License

Project Quay is under the Apache 2.0 license. See the LICENSE file for details.

jwtproxy's Issues

docker build fails missing "sirupsen/logrus"

$ docker build -t jwtproxy .
Sending build context to Docker daemon  10.9 MB
Step 1/10 : FROM golang:1.7-alpine
Trying to pull repository docker.io/library/golang ... 
1.7-alpine: Pulling from docker.io/library/golang
...snip...
Step 9/10 : RUN go install -v github.com/coreos/jwtproxy/cmd/jwtproxy
 ---> Running in 23858c504131

proxy/proxy.go:31:2: cannot find package "github.com/sirupsen/logrus" in any of:
	/go/src/github.com/coreos/jwtproxy/vendor/github.com/sirupsen/logrus (vendor tree)
	/usr/local/go/src/github.com/sirupsen/logrus (from $GOROOT)
	/go/src/github.com/sirupsen/logrus (from $GOPATH)
The command '/bin/sh -c go install -v github.com/coreos/jwtproxy/cmd/jwtproxy' returned a non-zero code: 1

Double close of channel if the proxy server can't start up

WARN[0000] Key registry is not configured to use a cache. This could introduce undesired latency during signature verification.
WARN[0000] No CA keypair specified, the proxy will not be able to forward requests to TLS endpoints.
INFO[0000] Starting reverse proxy (Listening on ':8081')
INFO[0000] Starting forward proxy (Listening on ':8080')
ERRO[0000] Failed to start reverse proxy: listen tcp :8081: bind: address already in use
INFO[0000] Received stop signal. Stopping gracefully...
ERRO[0000] Failed to start forward proxy: listen tcp :8080: bind: address already in use
panic: close of closed channel

goroutine 23 [running]:
panic(0x3aad00, 0xc82000e250)
    /usr/local/Cellar/go/1.6/libexec/src/runtime/panic.go:464 +0x3e6
main.startProxy.func1(0x4ecaa8, 0x7, 0xc82010a6a8, 0x5, 0xc8201155a0, 0x0, 0x0, 0x0, 0x0, 0xdf8475800, ...)
    /Users/jake/Projects/coreos/jwtproxy/src/github.com/coreos/jwtproxy/cmd/jwtproxy/main.go:137 +0x387
created by main.startProxy
    /Users/jake/Projects/coreos/jwtproxy/src/github.com/coreos/jwtproxy/cmd/jwtproxy/main.go:139 +0xb8
exit status 2

Write tests

At least, we need to test corner cases for jwt sign/verify.

Reverse proxy unix socket support

We need support for UNIX sockets in two places:

• Listen for incoming requests on a unix socket
• Send requests to the backend which is itself listening on a UNIX socket

This will simplify securing the actual traffic on the box and reducing the performance impact of the proxy.

jti replay protection should be optional

When using jwtproxy as a generic oauth2-proxy which verifies access tokens, a client will reuse the same access token it received from the IdP as long as it remains valid.

I can prepare a PR if this sounds reasonable to you.

jti should only be stored after signature validation

Allow configuring & running multiple verifiers

Remove keys and add instructions on how to generate them

Fix graceful shutdown

It doesn't seem to shut down at all right now.

Revoke autogenerated keys when the proxy is shut down

Need the ability to validate a static set of claims

Or at least limit incoming requests to a specific issuer.

rotation_policy claim

By providing the rotation policy claim, we'll be able to know frequently the proxy plans to rotate its keys on the Key Server side.

Support for HMAC single-key signing

This may already be supported and I'm just missing it, but can the reverse proxy currently be used to just verify signatures on unencrypted JWTs? I'd like to use this project with a private-key only HMAC+SHA256 JWT system, but it seems that the project may only work with public-key-encrypted tokens.

A fixed 1s poll period on key publication may be too aggressive

Starting up a large number of instances that autopublish may overwhelm the key server. We may want to make it configurable. Exponential backoff seems like a really bad fit here though, since you want the response to an approval to be relatively immediate.

Crypto Go ：we are a research group to help developers build secure applications.

Hi, we are a research group to help developers build secure applications. We designed a cryptographic misuse detector (i.e., CryptoGo) on Go language. We found your great public repository from Github, and several security issues detected by CryptoGo are shown in the following.
Note that the cryptographic algorithms are categorized with two aspects: security strength and security vulnerability based on NIST Special Publication 800-57 and other public publications. Moreover, CryptoGo defined certain rules derived from the APIs of Go cryptographic library and other popular cryptographic misuse detectors. The specific security issues we found are as follows:
(1) Location: jwt/keyserver/keyregistry/keyregistry.go:71;
Broken rule: HTTP is insecure;
(2) Location: proxy/proxy.go:224;
Broken rule: SSL/TLS use insecure verification;
We wish the above security issues could truly help you to build a secure application. If you have any concern or suggestion, please feel free to contact us, we are looking forward to your reply. Thanks.

Ability to require client side certificates for SSL termination

README: provide a brief overview

Just for other people at CoreOS curious on what is going on, please write a sentence or two about the use case and design

Add a user agent for the jwtproxy that isn't just Go http client.

Clean up socket on shutdown

Right now if jwtproxy shuts itself down (because it can't publish a key, for example), it leaves the socket it was listening on behind, which causes an error when it restarts later. (Right now I'm manually cleaning it up in the init file)

Also I noticed that we're calling close on the file descriptor rather then on the "socket" object (which does a tiny bit of additional cleanup)

key_server config key is under "private_key" but deals with public keys

This is super confusing. We need to rename things to make the config more intuitive.

Help configuring jwtproxy

I have a REST API authentication which has endpoints for user authentication with JWT and to verify tokens (https://github.com/GetBlimp/django-rest-framework-jwt).

I also want for (client side) users to be able to transparently authenticate against another web service with the same JWT (couchdb):

browser <- webtoken -> REST API (creates and signs webtokens)
browser	-- webtoken -> second web service

Would i be able to implement this with jwtproxy, probably with a preshared key between the web services ?

I've read the documentation and examples, but i'm a bit lost on how to configure jwtproxy for this setup, and if i would also be possible to transparently utilise the REST API JWT verifier endpoints to verify jwtproxy incoming JWTs, so that a preshared key wouldnt be required. Could i get a nudge in the right direction ?

Fail the whole proxy process if one of the configured proxies can't bind

Right now it starts with one half broken.

WARN[0000] Key registry is not configured to use a cache. This could introduce undesired latency during signature verification.
WARN[0000] No CA keypair specified, the proxy will not be able to forward requests to TLS endpoints.
INFO[0000] Starting reverse proxy (Listening on ':9081')
INFO[0000] Starting forward proxy (Listening on ':9080')
ERRO[0000] Failed to start forward proxy: listen tcp :9080: bind: address already in use
INFO[0000] Received stop signal. Stopping gracefully...
DEBU[0000] Adding rotation policy: 12h0m0s
DEBU[0000] Adding expiration time: 2016-04-06 10:42:45.90423738 -0400 EDT
DEBU[0000] Adding rotation time: 12h0m0s
DEBU[0000] Monitoring publish status                     keyID=8sS8C7usox signingKeyID=8sS8C7usox
DEBU[0001] Key not yet approved, waiting                 keyID=8sS8C7usox signingKeyID=8sS8C7usox
DEBU[0002] Key not yet approved, waiting                 keyID=8sS8C7usox signingKeyID=8sS8C7usox
DEBU[0003] Key not yet approved, waiting                 keyID=8sS8C7usox signingKeyID=8sS8C7usox
DEBU[0004] Key not yet approved, waiting                 keyID=8sS8C7usox signingKeyID=8sS8C7usox
DEBU[0005] Successfully published key                    activeKey=8sS8C7usox pendingKey=<nil>

Fill in the registry protocol documentation

Race condition when loading private key from file

If there's a private key stored on disk, jwtproxy finds it and loads it. In order for the private key to be "verified" it must pull the public key - but if the the keyserver doesn't respond, that verification fails and a new key is autogenerated instead.

This means that it's a gamble on startup as to whether you'll end up with the pre-approved boot-generated key or an unapproved autogenerated key, depending on where in the process the keyserver becomes reachable. (after stored key verification fails but before new key publishing occurs - this actually happened on the majority of test starts I did)

I think a good solution would be to simply fail the load process (kill jwtproxy) if the stored private key can't be verified (or at the very least; if it can't be verified because the public key is unreachable).

README: provide a quay.io container

This should be a requirement for an OSS release.

Switch public key lookaside cache to real http client cache

This will let the keyserver specify the expiration policy, giving us nice properties such as: "cache this key until it would be expiring anyway", and end up with perfect caching. The downside is of course key invalidation becomes much tricker, unless we set a max expiration policy on the key server to: min(actual expiration, max_expiration_default_5m) or something

Error - "Failed to create JWT signer: no private key provider specified"

Hello Team,

I have quay running with clair-jwt proxy as well for security scanning engine.

However when i started the container for clair-jwt:v2.01 i got an error as below.

level=error msg="Failed to create JWT signer: no private key provider specified"

Can someone help me what could be this issue? and why this issue occurs.

Thanks and Regards,
Arjun.M

Polish up all of the vendoring

keyserver: reference implementation wanted

Currently there is no reference implementation of the keyserver in this code base. We should provide one. Here is the API.

Ideally we also provide a gRPC and OpenAPI/swagger doc for this API as well.

README: provide a kubernetes pod example

This will give people a fast onboard to trying it out and show them how pods can be used to protect a service.

Docker Repository on Quay: Repository not found

When click on the "Docker Repository on Quay" link, it goes to quay.io and shows "Repository not found". Maybe, it is a result of b4167c1.

The repository URL before that commit, https://quay.io/repository/coreos/jwtproxy, is still available.

Feature: Verify JWT by JWK discovered by well known OpenId Connect Discovery endpoint

We maintain an identity server (IdentityServerr4 for .NET) which provides an well known endpoint to discover all other endpoints.
Among other things there is an URL for the currently used JWKs (jwks_uri).

Example:

{
   "issuer":"http://id.company.com",
   "jwks_uri":"http://id.company.com/.well-known/openid-configuration/jwks",
   "authorization_endpoint":"http://id.company.com/connect/authorize",
   "token_endpoint":"http://id.company.com/connect/token",
   "userinfo_endpoint":"http://id.company.com/connect/userinfo",
   "end_session_endpoint":"http://id.company.com/connect/endsession",
   "check_session_iframe":"http://id.company.com/connect/checksession",
   "revocation_endpoint":"http://id.company.com/connect/revocation",
   "introspection_endpoint":"http://id.company.com/connect/introspect",
   "device_authorization_endpoint":"http://id.company.com/connect/deviceauthorization",
   "frontchannel_logout_supported":true,
   "frontchannel_logout_session_supported":true,
   "backchannel_logout_supported":true,
   "backchannel_logout_session_supported":true,
   "scopes_supported":[
      "openid",
      "profile",
      "tenant",
      "roles",
      "offline_access"
   ],
   "claims_supported":[
      "sub",
      "tenant_id",
      "email",
      "name",
      "family_name",
      "given_name",
      "preferred_username",
      "locale",
      "tenant_name",
      "role"
   ],
   "grant_types_supported":[
      "authorization_code",
      "client_credentials",
      "refresh_token",
      "implicit",
      "password",
      "urn:ietf:params:oauth:grant-type:device_code"
   ],
   "response_types_supported":[
      "code",
      "token",
      "id_token",
      "id_token token",
      "code id_token",
      "code token",
      "code id_token token"
   ],
   "response_modes_supported":[
      "form_post",
      "query",
      "fragment"
   ],
   "token_endpoint_auth_methods_supported":[
      "client_secret_basic",
      "client_secret_post"
   ],
   "id_token_signing_alg_values_supported":[
      "RS256"
   ],
   "subject_types_supported":[
      "public"
   ],
   "code_challenge_methods_supported":[
      "plain",
      "S256"
   ],
   "request_parameter_supported":true
}

Example response of jwks_uri:

{
  "keys" : [ {
    "kty" : "RSA",
    "kid" : "1438289820780",
    "use" : "sig",
    "alg" : "RS256",
    "n" : "idWPro_QiAFOdMsJD163lcDIPogOwXogRo3Pct2MMyeE2GAGqV20Sc8QUbuLDfPl-7Hi9IfFOz--JY6QL5l92eV-GJXkTmidUEooZxIZSp3ghRxLCqlyHeF5LuuM5LPRFDeF4YWFQT_D2eNo_w95g6qYSeOwOwGIfaHa2RMPcQAiM6LX4ot-Z7Po9z0_3ztFa02m3xejEFr2rLRqhFl3FZJaNnwTUk6an6XYsunxMk3Ya3lRaKJReeXeFtfTpShgtPiAl7lIfLJH9h26h2OAlww531DpxHSm1gKXn6bjB0NTC55vJKft4wXoc_0xKZhnWmjQE8d9xE8e1Z3Ll1LYbw",
    "e" : "AQAB"
  }, {
    "kty" : "RSA",
    "kid" : "1438289856256",
    "use" : "sig",
    "alg" : "RS256",
    "n" : "zo5cKcbFECeiH8eGx2D-DsFSpjSKbTVlXD6uL5JAy9rYIv7eYEP6vrKeX-x1z70yEdvgk9xbf9alc8siDfAz3rLCknqlqL7XGVAQL0ZP63UceDmD60LHOzMrx4eR6p49B3rxFfjvX2SWSV3-1H6XNyLk_ALbG6bGCFGuWBQzPJB4LMKCrOFq-6jtRKOKWBXYgkYkaYs5dG-3e2ULbq-y2RdgxYh464y_-MuxDQfvUgP787XKfcXP_XjJZvyuOEANjVyJYZSOyhHUlSGJapQ8ztHdF-swsnf7YkePJ2eR9fynWV2ZoMaXOdidgZtGTa4R1Z4BgH2C0hKJiqRy9fB7Gw",
    "e" : "AQAB"
  } ]
}

It would be great if this proxy supports this well known endpoint to validate JWTs.

Log failed requests

Should probably log failed incoming (reverse proxy) requests at a level above debug

We should move the run and terminate logic outside of main.go

This will make it easier to extend the binary with more plugins

Cache warning shouldn't be written for reader key registry

Configurable error message

I think it makes sense to have the error message on verification failure be configurable.

Right now it returns a 403 with jwtproxy: unable to verify request: No JWT found (text/plain). You could always transform the 403 to whatever error response, but then you'd have to inspect the response body to see if it came from jwt or if it came from an upstream service or another proxy

Revoke key when the server shuts down

Passthrough mode if verifier not configured?

If the user disables the verifier, do we still bind to the port, do SSL termination, and pass through requests unverified? Or do we not bind to the port and require the upstream app to compensate?

Write JWK format when caching keys to disk

Right now the format saved to disk is a json serialization of the format in go-oidc:

{
    "KeyID": "rqcOAUsTdSjsXuDMGb7EBsfwHuyckNVDXllG2h5SsPI2d4OPaezdIw21t0krXyktji9K7GnlT3zkqnfquoi1T1PnWJA-V04LDsGEwxmxe5bFV-MnPOSLvZqdMYZ_A1KOxjsNf21OmwC2UR8eExQdu6eQ1KdMw9o6KZn7Y36wXYY_2uPOQlb9z191MDilIhF4-fVBJmt63xKkbKGaXZh7tsIBbdtVL7O-cSML11ZgJ_y-qjBua4xOfDYUeSB9wYzCKdar4t0vUwp7439bOSzIlHooV1Mx-i4n5F8joFiZVn-awvYJkbeCP1G5EvY1L9ALKmY89TwMOAy4kKN3x_lL1w==",
    "PrivateKey": {
        "N": 22047842810491776016612944468137650229686216356599353818821799229385947435439847242795550380546040597323289481867310895462305938400898158780724726178959081806763945043395601372556813085493055824384441400106858381413786815383586977276963584464367443401750946200535045120379235732880512741295217567021028248620306485868841721873955907416643538260687280999603573921142541450347167944873486944785391906532662323862197635444226105029751206447154862729409065614431728166741774662881551845255492294176836741435699811263410932353264933697003845601532214244874343994128601624679371652710056676956691306823886892964469028768727,
        "E": 65537,
        "D": 9001543099017783097738873539129943500552574744854493036455969635178293109694737212192815379591229507950917140948222189448478264091930238407248600002600182368792939523111160198445193520126610841098226933528529070776640581949412343424320836008866437021844913064188415738986941887860046682314358857451235986516404186285644569118139794214872671510588835601889942943160721368087342274621137943058016486307046155861632238950456485463416332967039612629205484061150272324573906897292427764382644198905620834110549066116127221199524469204664109714184231016760456726778106397490413216329499979035504262771828695183514253887673,
        "Primes": [140093153411592146053428913269248262016650992781486765847787795243197897148607607131732213802660221387750412805895944737374298987702642263543428720438864900182610267953550923096701405342243181647788561993456420130856553102817490110234434052333728298465619799407365435334536923257528032869900574289845207598451, 157379873845193961728105686537190443807957852206054316563797408127846018429909147640084685699883482423477680309367022129805759211858129466118288203347222972968696990964408651188751166007756746800541434042065373090471499095286188868040615781529289593975320317168361901548392642062961798852990796148108380088077],
        "Precomputed": {
            "Dp": 32880859450037542008237233073036250764302997863265474957210001471395853547459941909155208702145650935904555438611645665048620886351862967450829616518769853588185469912591670340013443047047997621286962488111244860961525547820904723677099418542157997573861540114501657480748996041126328663271291541059233460173,
            "Dq": 24049917398715496997222613953491345266592884780255946723018005743326332828410517930565148348022232883274012669153466387384297091822316654762571621473708562709332138555450396595134701429233620995886635975575395753560157825950092032186806949540196153068691471633445907563775459820567960320318336564433914072693,
            "Qinv": 133838487953338150539275990130645595567220486963492738755532246498759041379006605727543786481473501187477897613536690463358747926723198821787331116511600976674415523421228358575940783536049507275898211503526060885138239359064641125372485172727594985489510272638219349123020538092925258675789646090001273864160,
            "CRTValues": []
        }
    }
}

We should instead save/load from JWK:

{
  "kty": "RSA",
  "n": "AN-fWcpCyE5KPzHDjigLaSUVZI0uYrcGcc40InVtl-rQRDmAh-C2W8H4_Hxhr5VLc6crsJ2LiJTV_E72S03pzpOOaaYV6-TzAjCou2GYJIXev7f6Hh512PuG5wyxda_TlBSsI-gvphRTPsKCnPutrbiukCYrnPuWxX5_cES9eStR",
  "e": "AQAB",
  "d": "C0G3QGI6OQ6tvbCNYGCqq043YI_8MiBl7C5dqbGZmx1ewdJBhMNJPStuckhskURaDwk4-8VBW9SlvcfSJJrnZhgFMjOYSSsBtPGBIMIdM5eSKbenCCjO8Tg0BUh_xa3CHST1W4RQ5rFXadZ9AeNtaGcWj2acmXNO3DVETXAX3x0",
  "p": "APXcusFMQNHjh6KVD_hOUIw87lvK13WkDEeeuqAydai9Ig9JKEAAfV94W6Aftka7tGgE7ulg1vo3eJoLWJ1zvKM",
  "q": "AOjX3OnPJnk0ZFUQBwhduCweRi37I6DAdLTnhDvcPTrrNWuKPg9uGwHjzFCJgKd8KBaDQ0X1rZTZLTqi3peT43s",
  "dp": "AN9kBoA5o6_Rl9zeqdsIdWFmv4DB5lEqlEnC7HlAP-3oo3jWFO9KQqArQL1V8w2D4aCd0uJULiC9pCP7aTHvBhc",
  "dq": "ANtbSY6njfpPploQsF9sU26U0s7MsuLljM1E8uml8bVJE1mNsiu9MgpUvg39jEu9BtM2tDD7Y51AAIEmIQex1nM",
  "qi": "XLE5O360x-MhsdFXx8Vwz4304-MJg-oGSJXCK_ZWYOB_FGXFRTfebxCsSYi0YwJo-oNu96bvZCuMplzRI1liZw"
}

Send expiration time/TTL with key registry publication requests

If rotation is set up. Also send the key rotation policy as a query param. This will let key registries do more intelligent garbage collection and UI.

Stash autogenerated keys on the filesystem.

This will help with shutdown and restart within a server.

Put the signer kid claim in the signed payload for key registration

This will help us pick the public key which was used for the signature

provide trivial example

Having a really trivial example makes it easy for people to dive into the project. I get what this thing does from a high level but it is unclear how I can configure and start using it.

An example way of doing this is etcd's Procfile that lets you spin up a 3 members cluster and a proxy with one command and poke around at it: https://github.com/coreos/etcd/blob/master/Procfile

rename this repo

In preparation for an open source release we can rename this repo to github.com/coreos/jwtproxy and keep it private.