v0.6.0

Signed-off-by: Bobby DeSimone <bobbydesimone@gmail.com>

docs/docs/CHANGELOG.md

@@ -1,19 +1,46 @@
 # Changelog
 
-## vUnreleased
+## v0.6.0
 
-### New
+## New
 
-### Changed
+- authenticate: support backend refresh @desimone [GH-438]
+- cache: add cache service @desimone [GH-457]
 
-- Added yaml tags to all options struct fields
-  - [GH-394](https://github.com/pomerium/pomerium/pull/394)
-  - [GH-397](https://github.com/pomerium/pomerium/pull/397)
-- Improved config validation for `shared_secret` [GH-427](https://github.com/pomerium/pomerium/pull/427)
+## Changed
 
-### Fixed
+- authorize: consolidate gRPC packages @desimone [GH-443]
+- config: added yaml tags to all options struct fields @travisgroth [GH-394],[gh-397]
+- config: improved config validation for `shared_secret` @travisgroth [GH-427]
+- config: Remove CookieRefresh [GH-428] @u5surf [GH-436]
+- config: validate that `shared_key` does not contain whitespace @travisgroth [GH-427]
+- httputil : wrap handlers for additional context @desimone [GH-413]
 
-- Fixed regression preventing policy reload [GH-396](https://github.com/pomerium/pomerium/pull/396)
+## Fixed
+
+- proxy: fix unauthorized redirect loop for forward auth @desimone [GH-448]
+- proxy: fixed regression preventing policy reload [GH-396](https://github.com/pomerium/pomerium/pull/396)
+
+## Documentation
+
+- add cookie settings @danderson [GH-429]
+- fix typo in forward auth nginx example @travisgroth [GH-445]
+- improved sentence flow and other stuff @Rio [GH-422]
+- rename fwdauth to be forwardauth @desimone [GH-447]
+
+## Dependency
+
+- chore(deps): update golang.org/x/crypto commit hash to 61a8779 @renovate [GH-452]
+- chore(deps): update golang.org/x/crypto commit hash to 530e935 @renovate [GH-458]
+- chore(deps): update golang.org/x/crypto commit hash to 53104e6 @renovate [GH-431]
+- chore(deps): update golang.org/x/crypto commit hash to e9b2fee @renovate [GH-414]
+- chore(deps): update golang.org/x/oauth2 commit hash to 858c2ad @renovate [GH-415]
+- chore(deps): update golang.org/x/oauth2 commit hash to bf48bf1 @renovate [GH-453]
+- chore(deps): update module google.golang.org/grpc to v1.26.0 @renovate [GH-433]
+- chore(deps): update module google/go-cmp to v0.4.0 @renovate [GH-454]
+- chore(deps): update module spf13/viper to v1.6.1 @renovate [GH-423]
+- chore(deps): update module spf13/viper to v1.6.2 @renovate [GH-459]
+- chore(deps): update module square/go-jose to v2.4.1 @renovate [GH-435]
 
 ## v0.5.0
 

docs/docs/background.md

@@ -16,17 +16,19 @@ For years, security was synonymous with network security. Firewalls, network seg
 >
 > [Rob Joyce](https://en.wikipedia.org/wiki/Rob_Joyce) [Chief of Tailored Access Operations](https://en.wikipedia.org/wiki/Tailored_Access_Operations), [National Security Agency @ ENIGMA 2016](https://www.youtube.com/watch?v=bDJb8WOJYdA&feature=youtu.be&t=1627)
 
-There's no such thing as perfect security. Many recent high-profile breaches have demonstrated just how difficult it is for even large companies with sophisticated security organizations to avoid a breach. To pick just two of many possible breaches were perimeter security played a role, consider the Target and Google hacks. In Target's case, hackers circumvented both the physical and network perimeter by [hacking the HVAC system](https://krebsonsecurity.com/2014/02/target-hackers-broke-in-via-hvac-company/) which was connected to the internal corporate network and then moved laterally to exfiltrate customer credit card data. In Google's case, they experienced a devastating attack at the hands of the Chinese military. Google did a bottom up review of their security posture following [Operation Aurora](https://en.wikipedia.org/wiki/Operation_Aurora). The resulting actions from that review would be released as a [series of white papers](https://ai.google/research/pubs/pub43231) called "BeyondCorp" which have since become foundational documents in articulating how and why an organization could move beyond corporate perimeter (BeyondCorp...get it?) based security.
+There's no such thing as perfect security. Many recent high-profile breaches have demonstrated just how difficult it is for even large companies with sophisticated security organizations to avoid a breach. To pick just two of many possible breaches that epitomize the shortcomings of perimeter security, consider the Target and Google hacks. In Target's case, hackers circumvented both the physical and network perimeter by [hacking the HVAC system](https://krebsonsecurity.com/2014/02/target-hackers-broke-in-via-hvac-company/) which was connected to the internal corporate network from which hackers were then able  to move laterally and exfiltrate customer credit card data. In Google's case, they experienced a devastating attack at the hands of the Chinese military known as [Operation Aurora](https://en.wikipedia.org/wiki/Operation_Aurora). After which, Google did a bottom up review of their security posture. The resulting actions from that review would be released as a [series of white papers](https://ai.google/research/pubs/pub43231) called "BeyondCorp" which have since become foundational documents in articulating how and why an organization could move beyond corporate perimeter (BeyondCorp...get it?) based security.
 
 > In reality, there's never one front door; there are many front doors...[and] ... we're not securing a single castle. We're starting to think about securing many different interconnected castles.
 >
 > [Armon Dadgar, Cofounder of HashiCorp @ PagerDuty Nov 2018](https://www.hashicorp.com/resources/how-zero-trust-networking)
 
-The other side of the security trade-off is operational agility. Perimeter based approaches tend to focus on network segmentation which entails creating virtual or physical boundaries around services that need to communicate. Making those boundaries is increasingly difficult to manage in a world of microservices, and cloud computing where service communication requirements are constantly in flux. In theory, an organization could "micro/nano/pico-segment" each and every layer of an application stack to ensure the appropriate audience. However, in practice, operators usually choose between two sides. A very precise boundary that is high-touch, time-consuming to manage, and error prone. Or that of a more lax boundary that may entail more risk but is less time consuming to update, manage and less prone to break.
+The other side of the security trade-off is operational agility. Perimeter based approaches tend to focus on network segmentation which entails creating virtual or physical boundaries around services that need to communicate. Making those boundaries is increasingly difficult to manage in a world of microservices, and cloud computing where service communication requirements are constantly in flux.
+
+In theory, an organization could "micro/nano/pico-segment" each and every layer of an application stack to ensure appropriate access controls. However, in practice, operators are usually pulled in the direction of one of two extremes. That is, either a very precise boundary that is high-touch, time-consuming to manage, and error prone. Or that of a more lax boundary that may entail more risk but is less time consuming to update, manage and less prone to break.
 
 ### Gaps in the perimeter
 
-Perimeter based security suffers from the following shortcomings:
+In summary, perimeter based security suffers from the following shortcomings:
 
 - Perimeter security largely ignores the insider threat.
 - The "impenetrable fortress" model fails in practice even for the most sophisticated of security organizations.
@@ -34,14 +36,15 @@ Perimeter based security suffers from the following shortcomings:
 - Even just defining what the network perimeter is is an increasingly difficult proposition in a remote-work, BYOD, multi-cloud world. Most organizations are a heterogeneous mix of clouds, servers, devices, and organizational units.
 - VPNs are often misused and exacerbate the issue by opening yet another door into your network organization.
 
-### Zero-trust, behind the gates
+### Zero-trust, security behind the gates
 
 [Zero-trust](https://ldapwiki.com/wiki/Zero%20Trust) instead attempts to mitigate these shortcomings by adopting the following principles:
 
 - Trust flows from identity, device-state, and context; not network location.
 - Treat both internal and external networks as completely untrusted. Mutually authenticated encryption is used instead of network segmentation.
 - Act like you are already breached, because you probably are. An attacker could be anyone, and anywhere on your network.
-- Every device, user, and application's communication should be authenticated, authorized, and encrypted. Access policy should be dynamic, and built from multiple sources.
+- Every device, user, and application's communication should be authenticated, authorized, and encrypted.
+- Access policy should be dynamic, and built from multiple sources.
 
 To be clear, perimeter security is not defunct, nor is zero-trust security a panacea or a single product. Many of the ideas and principles of perimeter security are still relevant and are part of a holistic, and wide-ranging security policy. After all, we still want our castles to have high walls.
 

docs/docs/quick-start/helm.md

@@ -46,6 +46,10 @@ Run [./scripts/helm_gke.sh] which will:
 
 Open a browser and navigate to `httpbin.your.domain.example`.
 
+You can also navigate to the special pomerium endpoint `httpbin.your.domain.example/.pomerium/` to see your current user details.
+
+![currently logged in user](./img/logged-in-as.png)
+
 [./scripts/helm_gke.sh]: ../reference/examples.html#helm
 [./scripts/kubernetes_gke.sh]: ../reference/examples.html#google-kubernetes-engine
 [example kubernetes files]: ../reference/examples.html#google-kubernetes-engine

docs/docs/quick-start/kubernetes.md

@@ -59,6 +59,10 @@ And if you check out Google's Kubernetes Engine dashboard you'll see something l
 
 Open a browser and navigate to `httpbin.your.domain.example`.
 
+You can also navigate to the special pomerium endpoint `httpbin.your.domain.example/.pomerium/` to see your current user details.
+
+![currently logged in user](./img/logged-in-as.png)
+
 [./kubernetes_gke.sh]: ../reference/examples#google-kubernetes-engine
 [example kubernetes files]: ../reference/examples#google-kubernetes-engine
 [identity provider]: ../identity-providers/readme.md

docs/docs/quick-start/readme.md

@@ -48,6 +48,10 @@ Docker will automatically download the required [container images] for Pomerium
 
 You should now be able access to the routes (e.g. `https://httpbin.corp.yourdomain.example`) as specified in your policy file.
 
+You can also navigate to the special pomerium endpoint `httpbin.corp.yourdomain.example/.pomerium/` to see your current user details.
+
+![currently logged in user](./img/logged-in-as.png)
+
 [configuration file]: ../../configuration/readme.md
 [container images]: https://hub.docker.com/r/pomerium/pomerium
 [docker]: https://docs.docker.com/install/

docs/docs/quick-start/synology.md

@@ -206,6 +206,10 @@ If that user is authorized to see the httpbin service, you should be redirected
 
 ![Synology done](./img/synology-step-3-validate-header.png)
 
+You can also navigate to the special pomerium endpoint `httpbin.your.domain.example/.pomerium/` to see your current user details.
+
+![currently logged in user](./img/logged-in-as.png)
+
 And just to be safe, try logging in from another google account to see what happens. You should be greeted with a `403` unauthorized access page.
 
 ![Synology done](./img/synology-step-4-unauthorized.png)

docs/docs/releases.md

@@ -55,6 +55,7 @@ To see difference between releases, please refer to the changelog and upgrading
 For convenience, we maintain hosted documentation for each tagged release. The format for which is `https://{MAJOR}-{MINOR}-{PATCH}.docs.pomerium.io`. For example:
 
 - [github@master](https://master.docs.pomerium.io/)
+- [v0.6.0](https://0-6-0.docs.pomerium.io/)
 - [v0.5.0](https://0-5-0.docs.pomerium.io/)
 - [v0.4.0](https://0-4-0.docs.pomerium.io/)
 - [v0.3.0](https://0-3-0.docs.pomerium.io/)

docs/docs/upgrading.md

@@ -7,6 +7,38 @@ description: >-
 
 # Upgrade Guide
 
+## Since 0.5.0
+
+### Breaking
+
+#### New cache service
+
+A back-end cache service was added to support session refreshing from [single-page-apps](https://en.wikipedia.org/wiki/Single-page_application).
+
+- For all-in-one deployments, _no changes are required_. The cache will be embedded in the binary. By default, autocache an in-memory LRU cache will be used to temporarily store user session data. If you wish to persist session data, it's also possible to use bolt or redis.
+- For split-service deployments, you will need to deploy an additional service called cache. By default, pomerium will use autocache as a distributed, automatically managed cache. It is also possible to use redis as backend in this mode.
+
+For a concrete example of the required changes, consider the following changes for those running split service mode,:
+
+```diff
+...
+  pomerium-authenticate:
+    environment:
+      - SERVICES=authenticate
++      - CACHE_SERVICE_URL=http://pomerium-cache:443
+...
++  pomerium-cache:
++    image: pomerium/pomerium
++    environment:
++      - SERVICES=cache
++    volumes:
++      - ../config/config.example.yaml:/pomerium/config.yaml:ro
++    expose:
++      - 443
+```
+
+Please see the updated examples, and [cache service docs] as a reference and for the available cache stores. For more details as to why this was necessary, please see [PR438](https://github.com/pomerium/pomerium/pull/438) and [PR457](https://github.com/pomerium/pomerium/pull/457).
+
 ## Since 0.4.0
 
 ### Breaking
@@ -187,5 +219,7 @@ Usage of the POLICY_FILE envvar is no longer supported. Support for file based p
 
 The configuration variable [Authenticate Internal Service URL] must now be a valid [URL](https://golang.org/pkg/net/url/#URL) type and contain both a hostname and valid `https` schema.
 
-[policy]: ./configuration/readme.md#policy
-[authenticate internal service url]: ./configuration/readme.md#authenticate-service-url
+[policy]: ../configuration/readme.md#policy
+[authenticate internal service url]: ../configuration/readme.md#authenticate-service-url
+[cache service docs]: ../configuration/readme.md#cache-service
+[split service example]: ../configuration/examples.md#distinct-services