Giter Site home page Giter Site logo

pomerium / pomerium Goto Github PK

View Code? Open in Web Editor NEW
3.9K 38.0 276.0 66.88 MB

Pomerium is an identity and context-aware access proxy.

Home Page: https://www.pomerium.com

License: Apache License 2.0

Dockerfile 0.05% Makefile 0.16% Go 94.90% Shell 0.45% Python 0.14% Open Policy Agent 0.29% Lua 0.18% Jsonnet 1.36% TypeScript 2.47%
reverse-proxy iam beyondcorp identity go identity-aware-proxy zero-trust gateway pomerium vpn

pomerium's Introduction

pomerium logo

Go Report Card GoDoc LICENSE Docker Pulls

Pomerium builds secure, clientless connections to internal web apps and services without a corporate VPN.

Pomerium is:

  • Easier because you don’t have to maintain a client or software.
  • Faster because it’s deployed directly where your apps and services are. No more expensive data backhauling.
  • Safer because every single action is verified for trusted identity, device, and context.

It’s not a VPN alternative – it’s the trusted, foolproof way to protect your business.

Docs

For comprehensive docs, and tutorials see our documentation.

Contributing

See Contributing for information on how you can contribute to Pomerium.

pomerium's People

Contributors

alexfornuto avatar alexrudd2 avatar bonifaido avatar bradjones1 avatar calebdoxsey avatar cfanbo avatar cmo-pomerium avatar contrun avatar cuonglm avatar dependabot[bot] avatar desimone avatar grounded042 avatar kenjenkins avatar lumexralph avatar mbarrien avatar nareddyt avatar nhayfield avatar pflipp avatar renovate-bot avatar renovate[bot] avatar rspier avatar shapeshed avatar sylr avatar tdorsey avatar travisgroth avatar u5surf avatar wasaga avatar whs avatar yegle avatar zpain8464 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

pomerium's Issues

deployment: docker image does not contain nsswitch.conf

Describe the bug
Pomerium's base image inherits from alpine linux which does not currently have nsswitch.conf. This is problematic because Go uses nsswitch.conf by default.

As a result, Pomerium will not resolve hosts via /etc/hosts but instead always uses DNS.

Expected behavior

To be completely frank, I'm not sure if this is our problem to fix, Go's or Alpine's.

Potential fix?

Could we simply add a minimal nsswitch.conf to our Dockerfile?

RUN [ ! -e /etc/nsswitch.conf ] && echo 'hosts: files dns' > /etc/nsswitch.conf

Additional context

As @tianon mentions and as commented here: docker-library/docker#82 (comment) it is Go that is hardcoded to behave as glibc (dns first and then use hosts if it fails) if there is no /etc/nsswitch.conf. musl libc does not use this file at all since it does not implement NSS. I'd say that this is a bug in Go which assumes that linux always is glibc.

See also:

/cc @yegle

authorize: access right per route

Is your feature request related to a problem? Please describe.

In case different services have different access rights, it is needed to deploy pomerium multiple time (one instance per access right set), and this can become quite cumbersome when the number of services increase.

Describe the solution you'd like

It would interesting to be able to configure pomerium to have different access right depending on the routes. A bit like buzzfeed-sso does it for example (see https://github.com/buzzfeed/sso/blob/master/docs/sso_config.md).

Is this a planned feature?

Tag releases on Docker Hub

Now that there are getting to be releases of Pomerium, there's build artifacts in the form of releases on GitHub, but it would be nice to have a tag for a Docker Hub image corresponding to that same release. As much as I believe in CI/CD, sometimes we don't want to always be on the latest master branch image.

proxy: support HTTP backend

With the ROUTES environment variable, we cannot support proxying to backends that are served over HTTP without encryption. When the part after the colon is just the domain name, the proxy automatically prepends https://, but intentionally does not touch the URL otherwise. If the domain contains "http://", https://github.com/pomerium/pomerium/blob/master/proxy/proxy.go#L275 won't touch it. However, envconfig is unable to parse the setting properly; it tokenizes at both the colon separator separating the source domain and target AND the colon after the "http" protocol.

I built Pomerium repointing the envconfig dependency at a fork that contains kelseyhightower/envconfig#133 and got this working locally. One way is to build using that PR. Another is to use a different separator or even a completely different format for specifying routes. Another (not desired) possibility is to not support non HTTPS backends.

After sign out, user is redirected to previous url and is signed on automatically again (Google IdP)

Describe the bug

After signing out, user is signed on automatically again without choice using the same Google user as before.

To Reproduce Steps to reproduce the behavior:

  1. Sign out of a give route via https://xxx.com/.pomerium/sign_out
  2. Click on sign out in the pomerium sign out page
  3. User is redirected to https://xxx.com/ and signed in without any question

Expected behavior

User should be presented with the normal Google IdP user choice, so that:

  • he can choose not to sign in again
  • he can choose another identity in the IdP

Environment:

  • Pomerium version (retrieve with pomerium --version): v0.0.2+45e6a8d
  • Server Operating System/Architecture/Cloud: GKE/Google Oauth2

authenticate: handlers return a 404 not found if the route contains a port

  1. git checkout v0.0.4
  2. make
  3. config env and run source ./env
  4. run ./bin/pomerium

If I access any URL defined in policy.yml, it redirects me to AUTHENTICATE_SERVICE_URL but then it shows Unknown route HTTP 404.

Here's the console log. I mask secrets and sig.

3:16PM DBG proxy: request duration=0.286107 ip=1xx.xx.xx.xx method=GET pomerium-email= pomerium-user= req_id=d5536f4e-1ad7-92ce-d877-55517010960e size=1935 status=404 url=/sign_in?redirect_uri=https%3A%2F%2Fbugtik.lab.henryzhou.com%3A8443%2F.pomerium%2Fcallback&response_type=code&shared_secret=somesecrets&sig=somesig&ts=1556921814 user_agent="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36"

I'm feeling that "sign_in" is not properly handled by the process.
Error

There are debug logs when POMERIUM_DEBUG is not set

Describe the bug

POMERIUM_DEBUG is not set but I see logs of the following form for example in proxy:

{"level":"debug","cert-override-name":"xxx.com","addr":"pomerium-authenticate:443","time":"2019-03-25T14:25:13Z","message":"proxy/clients: grpc connection"}
{"level":"debug","cert-override-name":"xxx.com","addr":"pomerium-authorize:443","time":"2019-03-25T14:25:13Z","message":"proxy/clients: grpc connection"}

(Actually, I think those should be info also)

Environment:

  • Pomerium version (retrieve with pomerium --version): v0.0.2+45e6a8d

Allow running behind external TLS termination / reverse proxy

I'm interested in using Pomerium, but would like to run it behind an external load balancer so that I don't have to deal with Pomerium needing its own certificate, but I don't see a way (skimming the documentation) to configure Pomerium to operate behind a reverse proxy.

My specific scenario is that I'm running in AWS, and I'm already paying the hourly costs for an Application Load Balancer for other reasons, so I'd like to use the ALB to terminate TLS for Pomerium as well because there's no incremental cost aside from actual bandwidth use. ALBs (and also NLBs) support free zero-touch-renewal certificates issued by Amazon's CA, which notably can be wildcard certificates—a particularly useful thing for a use case like Pomerium.

There are two scenarios that would be nice to support:

  1. Pomerium behind an HTTPS->HTTP reverse proxy. (ELB,ALB)

    In this mode of operation, Pomerium would trust X-Forwarded-For, X-Forwarded-Proto, and X-Forwarded-Port headers for logging and other purposes. Out of an abundance of caution, in this mode Pomerium should probably refuse or force a redirect to https if X-Forwarded-Proto is http.

  2. Pomerium behind protocol-oblivious TLS->TCP. (NLB)

    In this mode of operation, Pomerium would not receive any special headers. It must assume (for url construction, etc...) that from the browser's perspective the browser has made an HTTPS connection.

Groups of Google IdP seems to be referenced by name instead of email

Describe the bug

Looking at the logs of the authorize service, it seems that pomerium retrieves the name of the groups and not the unique id in the form of an email address.

This means I can't use a stable identifier to authorize users by group.

To Reproduce Steps to reproduce the behavior:

  1. Login on a group protected service
  2. Check logs

:30PM DBG authorize/grpc Valid?=true email=[email protected] groups=["Infra","Demo Ops","Demo Test Group for SSO","Support","Tech"] route=www.xxx.com

Expected behavior

Pomerium should use the email as a way to identify a group in the policy file.

Environment:

  • Pomerium version (retrieve with pomerium --version): v0.0.2+45e6a8d

Phoenix

Describe the bug A clear and concise description of what the bug is.

To Reproduce Steps to reproduce the behavior:

  1. Ran x
  2. Clicked y
  3. Saw error z

Expected behavior

A clear and concise description of what you expected to happen.

Environment:

  • Pomerium version (retrieve with pomerium --version):
  • Server Operating System/Architecture/Cloud:

Configuration file(s):

# Paste your confis here.
# Be sure to scrub any sensitive values

Logs(s):

# Paste your confis here.
# Be sure to scrub any sensitive values

Additional context

Add any other context about the problem here.

all: pass standard logger interface to http, reverseproxy, and grpc

Describe the bug
If an internal error, or request is cancelled, that message is currently getting logged to the standard log.Logger interface. The easiest way to replicate this is by cancelling a http request context by quickly refreshing a page.

12:55PM DBG proxy: request duration=167.531567 ip=192.168.1.1 method=GET [email protected] pomerium-user=110524515923396131437 referer=https://httpbin.corp.beyondperimeter.com/ req_id=12babd31-5478-8ebe-bd7f-af0bede3a290 size=3760 status=200 url=/spec.json user_agent="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.119 Safari/537.36"
2019/03/03 12:55:01 http: proxy error: context canceled

Notice
2019/03/03 12:55:01 http: proxy error: context canceled

Expected behavior

Logs should be piped to our package logger.

Environment:

  • Pomerium version (retrieve with pomerium --version): v0.0.2-dirty+5913122
  • Server Operating System/Architecture/Cloud: Darwin

Additional context

add service metrics / instrumentation / telemetry

Is your feature request related to a problem? Please describe.

Code instrumentation is essential for observability into a distributed system.

Describe the solution you'd like

Add support for common instrumentation capabilities like counters, gauges, and histograms, and provides adapters to popular metrics packages, like expvar, StatsD, and Prometheus.

Additional context

CORS preflight OPTIONS requests should bypass authentication

Describe the bug
Pomerium is requiring authentication for http OPTIONS requests, but the spec says OPTIONS requests should not include user credentials. These requests should be passed downstream without authentication.

To Reproduce Steps to reproduce the behavior:

Browser on https://bob.corp.domain.com/ makes a CORS request to https://alice.corp.domain.com/ like this:

curl 'https://alice.corp.domain.com/api/route' -X OPTIONS -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0' -H 'Accept: */*' -H 'Accept-Language: en-US,en;q=0.5' --compressed -H 'Access-Control-Request-Method: POST' -H 'Access-Control-Request-Headers: content-type' -H 'Origin: https://bob.corp.domain.com' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Referer: https://bob.corp.domain.com/some/route' -H 'TE: Trailers'

Pomerium will try to redirect to the authentication provider.

Expected behavior

Pomerium should not require auth for HTTP OPTIONS requests.

Environment:

  • Pomerium version (retrieve with pomerium --version): v0.0.3+41c42f5
  • Server Operating System/Architecture/Cloud: ubuntu 18.04, running on EC2 behind an elastic ip

Configuration file(s):

Logs(s):

ERR authenticate: failed to load session error="http: named cookie not present" 
WRN authenticate: authenticate error error="http: named cookie not present" 

Provide HTTP support and insert HSTS header

Without running additional HTTP server at port 80, I have to remember to use https:// for each of the domain proxied by Pomerium, at least for the first use.

It would be great if Pomerium can serve on port 80 and do a simple redirection to HTTPS, and insert HSTS header in the redirect response.

Alternatively maybe there's such an NGINX container exist that will automatically redirect HTTP to HTTPS then add HSTS, but I would rather for Pomerium to support this.

Allow running authenticator and proxy separately as standalone processes

I found this while following the buzzfeed SSO. Looking at it, the code looks clean and seems to cleanup a lot of the configuration messiness from Buzzfeed and bit.ly's SSO. Most importantly for my organization, it adds Okta SSO support.

For my organization, the double OAuth flow is pretty important to prevent having to configure separate applications within Okta for every single internal app we create. The code seems architected for this, but it looks like you've hard coded in cmd/main.go that you instantiate both an Authenticator and Proxy object every time, and that all environment settings must be valid for both simultaneously. There doesn't seem to be some way using environment variables to disable one or the other.

pomerium needs to either split the command line into 2 apps (I know you are intentionally trying to merge them though), add flags/subcommands to only enable one, or provide environment variable settings/combinations to selectively disable one or the other.

proxy: allow hot-reloading of policy on change

Right now when you edit policy.yaml, you have to restart Pomerium (at least for users who run Pomerium in docker).

It would be great if Pomerium can monitor this file and trigger a reload upon file change (or with a given interval).

Ideally Pomerium should only reload when the semantic of the policy file is changed. E.g. when someone add a comment line, it should not cause a reload. But if it's too hard I'm fine with any change (e.g. compare the hash with an interval).

docs: clarify PROXY_ROOT_DOMAIN option

Describe the bug

There is an inconsistency here because rootDomain is singular while the description is plural.

Also when using the PROXY_ROOT_DOMAIN envvar (which is singular), I thought it was actually meant to be able to parse multiple domains. But since rootDomain is also used for the ingress, if someone uses multiple domains, the ingress is going to be broken.

Additional context

Thank you @victornoel for reporting this.

authenticate: allow manual refresh

Is your feature request related to a problem? Please describe.

A user tries to sign in into an application, but they are not authorized to access it because not in the only authorized group.

The admin adds them to the group for the user to be able to access the application.

The user tries to access the application but access is still refused.

Describe the solution you'd like

Authorization of groups (since the others are not mutable) should be refreshed after some time, if possible configurable.

Describe alternatives you've considered

Sign out from another application the user has access to in order to sign in again and refresh groups.

Explain any additional use-cases

Changing access right of a user by removing them from a group.

Google: Missing refresh token during re-authorization after clearing cookies

In an edge case, session state can end up without a refresh token, which causing 500 in pomerium proxy due to unable to fresh oauth token.

Steps to reproduce the behavior:

  1. Login to a pomerium proxied app with Google account.
  2. Clear all pomermium cookies
  3. Login with Google again. If you check session state at this point, refresh_token is already empy.
  4. Wait a few hours until oauth token expire
  5. Go to pomerium proxied app.
  6. 500 Error

Expected behavior

Pomerium should always be able to get a fresh token, since it's "persisted" in cookies, and the chance of losing it is very high.

Environment:

  • Pomerium version: 0.0.3
  • Server Operating System/Architecture/Cloud: kubernetes 1.12

Logs(s):

proxy: refresh failed [31merror=[0m[31m"missing refresh token"...

Additional context

PR to fix will follow.

authorize: policy and authorization

Authorization Service

Authorization modules

  • Device state (vNext)
    • Persistent device identifier (X.509 certificates in TCB)
    • Encryption status, secure boot enabled, etc
    • Device inventory (OSQuery, others?)
    • Hardware enclaves and trusted attestation is absolutely critical. Devices cannot be trusted to report their own state. (intel sgx, Apple T2)
  • Identity state (muddy mix of oidc / oauth2 / rest / saml for unified interface)
    • v0.0.3
    • vNext
      • multi-factor authentication used?
      • roles
      • titles
      • status
  • Request state (vNext)
    • IP
    • Geo
    • Date/time
    • Known tor exit, proxy, vpn
    • Browser version (though UA is spoof-able, better to get from device state)

Policy Engine

  • v0.0.3 #59
    • Policy applied per route; Combine policy assignment with route map?
    • Yaml /Json based? ACL driven.
    • User should be shown a deny landing page explaining why they were denied (lack group membership etc).
  • vNext
    • dynamic “policy as code” w/ generic Language or DSL🤮 ( see sentinel, OPA)
    • Compiled for speed
    • Centralized ? (support storage backends?😕)
    • Queryable by RPC (support storage backends?😕)
    • Managed by security team
    • Self service support


See:

/cc @tboerger

proxy: add forward-auth endpoint (third party proxy support)

Is your feature request related to a problem? Please describe.

When using pomerium in a kubernetes cluster, it does (at least) two different things:

  • it authorizes request and authenticate users
  • it proxies request

Often a kubernetes has already an existing proxy such a nginx-ingress or ambassador or others.

So the requests are proxied twice, and the proxy implementation is done twice, hence increasing the attack surface as well as the potentiality of bugs/problems.

Describe the solution you'd like

It would be cool if it was possible to use the authorize/authenticate part of pomerium coupled with another proxy that would be responsible of proxying.

See for example:

Describe alternatives you've considered

I didn't. Notice also that I just thought of this while reading about ambassador and wanted to bring the subject to awareness to the pomerium project in case it converges with its goals.

internal/aead : consider replacing miscreant

Pomerium needs to encrypt data. Specifically, it must encrypt data with authentication.
Encryption is hard to get right and it has become increasingly clear that nonce-reuse is a subtle problem. Currently miscreant is used, but I would like to consider using nacl/secretbox or GCM with random nonces until AE_GCM-SIV is supported by the standard library.

At some point, this will likely include support for third party KMS.

Each choice has trade-offs, but I'd like to earmark this issue as a place for future discussion as the space evolves.

Miscreant

  • ✅ AES-GCM-SIV
  • ✅ hard to misuse (nonces!)
  • Not maintained or relied on by any BigCo. Normally, this is an extremely weak argument but with cryptography I'd much prefer to use a package used by a company like Google critical to their business with the likes of Filippo Valsorda or Adam Langley maintaining it.
  • 🤷‍♂️ streaming support (not relevant for our use case)
  • 🤷‍♂️ ~30% slower encryption (not relevant for our use case yet)

XChaCha20-Poly1305

nacl/secretbox

  • ✅ Fast
  • ✅XSalsa20 w/ Poly1305 MAC provides encryption and authentication together
  • ⚠️relatively newer standard
  • ⚠️maintained as an /x/ package
  • ❌ doesn't use the underlying cipher.AEAD api.
  • 🤷‍♂️DJB monoculture

GCM with random nonces

  • ✅ Fastest
  • ✅ Go standard library, supported by google $
  • ⚠️Easy to get wrong
  • ❌IV reuse is a known weakness so keys must be rotated before birthday attack. NIST SP 800-38D recommends using the same key with random 9

Further reading on tradeoffs

proxy: provide logout link on 403 page

I use Google OAuth to login to Pomerium. I usually have more than 2 Google accounts login at the same time, but not all of them are whitelisted to access pages protected by Pomerium.

Sometimes, I would choose the wrong email address and get a 403 page. But there's no logout link on the 403 page and I have to either remember the secret URL to logout (/.pomerium/somethingsomething) or delete the cookie.

It would be great if you can add some description on the 403 page. E.g.: You are logged in as [email protected]. Do not intend to use this email? Click Here to login again.

Alternative without this feature: delete the cookie, or use the /.pomerium/ link to logout (which I can barely remember 😞.

Demonstrating websocket support?

Describe the bug

I am unable to confirm that websocket support works in 0.0.3.

To Reproduce

  1. Deployed Pomerium 0.0.3
  2. Tried to connect to otherwise-working proxied apps where websocket-based features failed
  3. Websockets were unable to connect
  4. Added a proxy from https://websocket.corp.my-redacted-domain.com to https://websockets.org
  5. Demo was unable to connect to wss://websocket.corp.my-redacted-domain.com/
    6, Deployed Kaazing gateway at http://kaazing.corp.my-redacted-domain.com:8000
  6. Successfully demonstrated insecure websockets on port 8000
  7. Configured a policy to point at local gateway
  8. Local gateway cannot connect to websocket (this might be a Kaazing issue; it's expecting a particular host value, I think.)

Expected behavior

Websocket support works.

Environment:

  • Pomerium version (retrieve with pomerium --version): v0.0.3+41c42f5
  • Server Operating System/Architecture/Cloud: Synology x86 NAS running docker

Configuration file(s):

policy.yaml:

- from: kaazing.corp.my-redacted-domain.com
  to: http://kaazing.corp.my-redacted-domain.com:8000
  allowed_users:
  - <me>
- from: httpbin.corp.my-redacted-domain.com
  to: https://httpbin.org
  allowed_users:
  - <me>
- from: websocket.corp.my-redacted-domain.com
  to: https://websocket.org/
  allowed_users:
  - <me>

Logs(s):

There appear to be no logs associated with websocket connection attempts.

Additional context

Pomerium is bound directly to port 443.

Happy to add any Pomerium folks who want to try these routes to my allowed users (and share with them the actual URLs involved.) This is not a production system so I'm happy to make sweeping changes.

Connecting to wss://httpbin.corp.my-redacted-domain.com/anything yields an error 200; curiously, nothing is in the logs for this request. POMERIUM_DEBUG is true and LOG_LEVEL is default; l I am seeing DBG logs.

Pomerium used DNS query for hostnames in /etc/hosts

I'm running Pomerium in docker without IPv6 configured.

The domain name I used as AUTHENTICATE_SERVICE_URL only have AAAA record. This should normally be fine because I can either set hostname on the container to the hostname, or add extra_hosts to add an internal IPv4 address.

I'm setting the hostname of the docker container running Pomerium to example.com, but I'm seeing this in the log:

5:48AM ERR proxy: error redeeming authorization code error="rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = \"transport: Error while dialing dial tcp [2600:XXXX:XXXX:XXXX]:443: connect: cannot assign requested address\"" ip=172.29.0.1 req_id=58d3c18e-a357-0c09-3f57-adfb47017376 user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36"

The IPv6 address in the log is the AAAA record of example.com

Auto port discovery on Docker containers

This is a bit stretch because Pomerium may not be running on a server with Docker at all.

But for people who run Pomerium in Docker and want to proxy request to other containers, it would be super useful to only specify the hostname (the container name if they are connected to the same network) and let Pomerium to discover the exposed ports. If there are more than 1 exposed port, just randomly pick one and raise error if it's not an HTTP port.

E.g. if I have a container named example that have exposes:8181, I should be able to specify this in policy file and let Pomerium to do the port discovery:

- from: external.example.com
  to: http://example
  ...

Without this I would probably run https://github.com/jwilder/nginx-proxy or https://traefik.io/ as an additional layer of proxy.

cmd/pomerium : top-level health-checks

Placeholder for reproduction steps. Currently not a bug, but it would be helpful to know what's going on routing-wise when this is deployed behind K8s/Helm.

See further description of the issue.

Initial checkin of Pomerium

Happy new years. 🎉

All

  • Consolidated many instances of duplicated code, likely the result of the project's history.
  • Removed statsd / datadog code. buzzfeed/sso#5, buzzfeed/sso#35
  • Removed support for HTTP in favor of HTTPS only.
  • Renamed structures for clarity (e.g., both auth and proxy use the term provider to mean very different things)
  • Refactored package scoped http response structs in favor of anonymous structs.
  • Replaced hardcoded integer status codes with their respective http package enums (e.g. http.StatusOK).
  • Replaced how Authorization validators, and providers are injected via functions.
  • Replaced vendoring to use go mod.
  • Replace logrus with a zero allocation logger, zerolog, that does not use interface{} unmarshalling. buzzfeed/sso#126
  • Options are now set to parse URLs directly as environmental configuration variables instead of as strings.
  • Option structures throw errors on first encounter instead of building error string slices which had (at least for me, especially when testing) where struct.New() would create unpredictable struct state and runtime nil pointer errors.
  • Add version flag buzzfeed/sso#36
  • Add debug flag for more verbose and human friendly debugging buzzfeed/sso#126
  • Combine authenticate and proxy into a single binary buzzfeed/sso#85

Authenticate

  • Refactored template code to use template package directly instead of as a wrapper (oddly, this differed between auth and proxy).
  • Removed code to generate and serve a single static css file, which be served directly as an inline.
  • Remove skip provider setting buzzfeed/sso#134
  • Removed "groups" from the authentication abstraction in favor of having it handled by authorization package. Though google supports groups, support amongst other identity providers is spottier.
  • Document preference for generating random keys from urandom over openssl rand.
  • Abstracted out templates, middleware, templates, and sessions into their own internal packages where appropriate.

Authenticate/providers

  • Add support for additional identity providers (IdP). buzzfeed/sso#27
  • Changed authorization to be OpenID based.
  • Replaced vanilla http client with /x/oauth2 and oidc libraries for identity calls. The big benefit here is as providers update their endpoint URLs in .wellknown we will update as well.
    • Updated google oauth2 url buzzfeed/sso#131. See above.
    • Non standard OpenID connect endpoints like revoke still use vanilla http (see google/okta for examples). Revoke URLs are still populated from .well-known/openid-configuration
  • Removed internal_utils. If we are concerned about secrets in logs we should either use a secure hash function, or not log it.
  • Broke out "googleClient" to be its own package since there's nothing really google specific about it. Useful for non-oauth2 endpoints like revoke.

Proxy

  • Fixed a bug where RequireHTTPS middleware which would cause infinite redirects when served directly where scheme and http-forward-protocol could be empty .
  • Removed provider interface. Proxy has a http client to interact with authentication model. Provider interface is unnecessary. buzzfeed/sso#82
  • Replaced duplicate "sessions" package. buzzfeed/sso#43
  • With the removal of HTTP support, HMAC request signing is no longer required (covered by TLS).
    Deployment
  • Added script to generate wildcard, TLS certificates from LetsEncrypt. In the future, we may build this functionality in directly.
  • Added alpine based docker image. buzzfeed/sso#20

Session/Cookie

  • Added TokenID for OpenID. buzzfeed/sso#45
  • isExpired func refactored to single boolean check
  • Add gzip compression to session (compress then encrypt). buzzfeed/sso#95
  • Removed unused 'addPadding' and 'SecretBytes' functions.
  • Use internal sessions package for proxy. buzzfeed/sso#43

Nota bene, the following significant features were removed:

  • Regex proxying
  • Group membership validation and caching (to be handled in the authorization model).
  • Cleartext HTTP support.

proxy: grpc client should retry connections to services on failure

Describe the bug

I restarted pomerium, tried to login with my user and got a 500 error.
After refreshing the page, I'm correctly logged in.

To Reproduce Steps to reproduce the behavior:

  1. Restart pomerium with a fresh set of secrets (to ensure user has to log again)
  2. Go to a protected service and log in
  3. Saw 500 error

Logs of the proxy:

{"level":"error","fwd_ip":"10.4.0.1","ip":"10.4.0.42","user_agent":"Mozilla/5.0 (X11; Linux x86_64; rv:66.0) Gecko/20100101 Firefox/66.0","referer":"https://accounts.google.com/signin/oauth/oauthchooseaccount?client_id=XXXXXXXXX&flowName=GeneralOAuthFlow","req_id":"017ee31d-aad7-5207-a989-a834895ca395","error":"rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = \"transport: Error while dialing dial tcp 10.7.240.43:443: i/o timeout\"","time":"2019-03-25T10:00:16Z","message":"proxy: error redeeming authorization code"}

There is no error in the authenticate service.

Expected behavior

User should be able to login at any time :)

Environment:

  • Pomerium version (retrieve with pomerium --version): v0.0.2+45e6a8d
  • Server Operating System/Architecture/Cloud: GKE / GSuite

proposal: remove file support for certificates

Is your feature request related to a problem? Please describe.

For a few settings, we allow the option to specify file paths to be used in addition to passing base64 encoded bytes. Those settings are:

  • Certificate files
  • Certificate private key files

The problem is basically we just have to maintain more code paths than I would like. As I started implementing policy and considering whether to support a file as well, I started to question the benefits of maintaining code paths for both file paths and file contents directly.

Describe the solution you'd like

Remove support for files. Instead extend envconfig to support a base64 type and return bytes. Or even optionally support compressed bytes if size becomes an issue.

Describe alternatives you've considered

The one downside is that envars are typically limited to about 1MB in size. Which seems pretty massive for policy/text/certs/ but maybe I'm overlooking something. Supporting both files and environmental variables for configurations that may be large (certificates, policy files, etc).

Additional context

Any good reasons to keep support for file paths?

Programmatic access to resources behind proxy

I'd like to have programmatic access for resources behind proxy for "dumb" software like grafana or prometheus (like connect prometheus behind pomerium proxy).

Solution can be something like API tokens via basic auth or some http header.

For example, with nginx + auth_request + oauth2_proxy you can allow by IP.

proxy: add per-route configuration settings

Is your feature request related to a problem? Please describe.

Different routes may require different transport settings (timeouts, keep alives, max connections etc) depending on their underlying function.

For instance, an internal training site may need to stream video (requiring long lived write timeouts) content but an on-premise CRM (relatively short write timeouts) may not. Settings can be configured accordingly.

Describe the solution you'd like

Allow policy to include definitions for route specific http transport settings.

var DefaultTransport RoundTripper = &Transport{
	Proxy: ProxyFromEnvironment,
	DialContext: (&net.Dialer{
		Timeout:   30 * time.Second,
		KeepAlive: 30 * time.Second,
		DualStack: true,
	}).DialContext,
	MaxIdleConns:          100,
	IdleConnTimeout:       90 * time.Second,
	TLSHandshakeTimeout:   10 * time.Second,
	ExpectContinueTimeout: 1 * time.Second,
}

Additional context

#40

proxy : authorize_internal_url is extraneous

Hi,

If I set on the proxy the two AUTHORIZE_INTERNAL_URL and AUTHENTICATE_INTERNAL_URL, then pomerium complains that AUTHORIZE_SERVICE_URL and AUTHENTICATE_SERVICE_URL are not set.

I would expect that if the proxy is using the internal urls, it does not need to know about the external urls, does it?

authenticate: allow skipping pomerium login page

Right now the authentication-flow is such that when a user's session is invalid, they are redirected first to a pomerium specific login page containing an HTML page with a button to redirect to the underlying identity provider login flow. It's an extra-step many users understandably want to skip.

This should probably be the default functionality.

Placeholder, may be a multi-PR issue.

See also:

deployment: add docker images for other architectures and cpus

Describe the solution you'd like

It would be nice to have multi-arch support for docker image (namely arm32v7) as lots of people runs their self-hosted home automation System of Systems on Raspberry Pi and other ARM-powered single board computers. IAP would profit them in terms of providing secure remote access without the need to setup VPNs or exposing web GUI directly to the Internet.

Cheers

Release on Docker Hub

Having an official Docker Hub release of Pomerium would be useful to prevent people from having to build and host their own binaries.

proxy: default WriteTimeout could be used to exhaust file descriptors

Describe the bug
WriteTimeout normally covers the time from the end of the request header read to the end of the response write (a.k.a. the lifetime of the ServeHTTP), by calling SetWriteDeadline at the end of readRequest.

However, when the connection is HTTPS, SetWriteDeadline is called immediately after Accept so that it also covers the packets written as part of the TLS handshake. Annoyingly, this means that (in that case only) WriteTimeout ends up including the header read and the first byte wait.

Incidentally, this means that the package-level convenience functions that bypass http.Server like http.ListenAndServe, http.ListenAndServeTLS and http.Serve are unfit for public Internet servers

Annoyingly, there is no way of accessing the underlying net.Conn from ServeHTTP so a server that intends to stream a response is forced to unset the WriteTimeout (which is also possibly why they are 0 by default). This is because without net.Conn access, there is no way of calling SetWriteDeadline before each Write to implement a proper idle (not absolute) timeout.

Expected behavior

Safely support both streaming, and prevent abuse of unlimited timeouts.

Additional context

docs : add helm guide

Currently we have quick start guides for docker, kubernetes, and from source. I would be great to have an equivalent guide for helm!

See:

proxy: 302 redirect breaks reverse proxy

Hi,

I run into a situation that internal website uses 302/302 redirect breaks the reverse proxy.

Here's my policy file.

Here's the log

11:25PM DBG proxy: request duration=19.236317 ip=x.x.x.x method=GET pomerium-email=[email protected] pomerium-user=10524413789654936831 req_id=174989fa-b99c-a8b8-010c-ba03e2aa944d size=95 status=303 url=/ user_agent="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_4) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1 Safari/605.1.15

After the authorization, I notice the URL in the browser window changes from tautulli.lab.henryzhou.com to 192.168.1.2 which is inaccessible if I'm out of the internal network.

I wonder if the issue is caused by 302/303 redirect (of the internal website itself) or a miss configured env.

Thanks

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.