Separate static content specific to doc content
We mixed together doc content and website content. We don’t need to version the website content (logos, main site stuff, etc) but the doc static content (mostly images) should be tied to the markdown that uses it. Signed-off-by: Patrick East <east.patrick@gmail.com>
@@ -53,4 +53,4 @@ into OPA via the filesystem or well-defined APIs.
|
||||
|
||||
## Why use OPA?
|
||||
|
||||
{{< figure src="/img/benefits.svg" width="65" caption="Open Policy Agent: before and after" >}}
|
||||
{{< figure src="benefits.svg" width="65" caption="Open Policy Agent: before and after" >}}
|
||||
|
||||
@@ -28,7 +28,7 @@ The following diagram shows this process in more detail.
|
||||
1. The OPA-enabled software system includes that token as part of the usual `input` to OPA.
|
||||
1. OPA decodes the JWT token and uses the contents to make policy decisions.
|
||||
|
||||
{{< figure src="/img/best-practice-identity-jwt.png" width="60" caption="JSON Web Token flow" >}}
|
||||
{{< figure src="best-practice-identity-jwt.png" width="60" caption="JSON Web Token flow" >}}
|
||||
|
||||
### Updates
|
||||
The JWT only gets refreshed when the user authenticates; how often that happens is up to the TTL included in the token. When LDAP/AD information changes, those changes will not be seen by OPA until the user authenticates and gets a new JWT.
|
||||
@@ -58,7 +58,7 @@ Two things happen independently with this kind of LDAP/AD integration.
|
||||
1. OPA downloads new policy bundles including LDAP/AD
|
||||
1. OPA-enabled software system asks OPA for policy decisions
|
||||
|
||||
{{< figure src="/img/best-practice-identity-bundle.png" width="80" caption="Bundle flow" >}}
|
||||
{{< figure src="best-practice-identity-bundle.png" width="80" caption="Bundle flow" >}}
|
||||
|
||||
### Updates
|
||||
The lag between an LDAP/AD update and OPA having the update is the sum of the lag for an update between LDAP/AD and the central server and the lag for an update between the central server an OPA. So if LDAP/AD updates every 5 minutes, and OPA pulls an update every 2 minutes, then the total maximum lag is 7 minutes. Unlike the JWT case, it is feasible that a user could perform an action requiring authorization on the OPA-enabled service before OPA has the appropriate LDAP/AD policy, but you can account for that when writing policy and reject any request when there is insufficient data.
|
||||
@@ -81,7 +81,7 @@ Two things happen independently with this kind of LDAP/AD integration.
|
||||
1. Synchronizer keeps OPA up to date with LDAP/AD
|
||||
1. OPA-enabled software system asks OPA for policy decisions
|
||||
|
||||
{{< figure src="/img/best-practice-identity-push.png" width="80" caption="Push flow" >}}
|
||||
{{< figure src="best-practice-identity-push.png" width="80" caption="Push flow" >}}
|
||||
|
||||
### Updates
|
||||
|
||||
@@ -114,7 +114,7 @@ The key difference here is that every decision requires contacting LDAP/AD. If
|
||||
1. OPA-enabled service asks OPA for a decision
|
||||
1. OPA during evaluation asks LDAP/AD for user attributes
|
||||
|
||||
{{< figure src="/img/best-practice-identity-remote.png" width="80" caption="Pull flow" >}}
|
||||
{{< figure src="best-practice-identity-remote.png" width="80" caption="Pull flow" >}}
|
||||
|
||||
### Updates
|
||||
LDAP/AD data is perfectly fresh. There is no lag between an update to LDAP/AD and when OPA sees that update.
|
||||
|
||||
@@ -16,7 +16,7 @@ OPA’s RESTful APIs use JSON over HTTP so you and your users can integrate OPA
|
||||
|
||||
When your service is integrated with OPA, your users will be able author and deploy custom policies that control the behavior of your service’s policy-enabled features. Furthermore, users can publish data to OPA that is not available to your service about their own deployment context.
|
||||
|
||||
{{< figure src="/img/request-response.svg" width="50" caption="OPA's query and decision model" >}}
|
||||
{{< figure src="request-response.svg" width="50" caption="OPA's query and decision model" >}}
|
||||
|
||||
In the future, both your service and its users will be able to register for, and react to, notifications triggered when OPA detects a policy-relevant change.
|
||||
|
||||
@@ -30,7 +30,7 @@ When OPA starts for the first time, it will not contain any policies or data. Po
|
||||
|
||||
The primary unit of data in OPA is a document, which is similar to a JSON value. Documents typically correspond to single, self-contained objects and are capable of representing both primitive types (strings, numbers, booleans, and null) as well as structured types (objects, and arrays). Documents are created, read, updated, and deleted via OPA’s [RESTful HTTP APIs](../rest-api).
|
||||
|
||||
{{< figure src="/img/data-model-dependencies.svg" width="70" caption="OPA data model dependencies" >}}
|
||||
{{< figure src="data-model-dependencies.svg" width="70" caption="OPA data model dependencies" >}}
|
||||
|
||||
### Base Documents
|
||||
|
||||
@@ -153,7 +153,7 @@ In contrast to base documents, virtual documents embody the results of evaluatin
|
||||
|
||||
All documents pushed into OPA or computed by rules are nested under a built-in root document named data.
|
||||
|
||||
{{< figure src="/img/data-model-logical.svg" width="70" caption="OPA document structure" >}}
|
||||
{{< figure src="data-model-logical.svg" width="70" caption="OPA document structure" >}}
|
||||
|
||||
Example `data` document:
|
||||
|
||||
|
||||
|
Before Width: | Height: | Size: 183 KiB After Width: | Height: | Size: 183 KiB |
|
Before Width: | Height: | Size: 19 KiB After Width: | Height: | Size: 19 KiB |
|
Before Width: | Height: | Size: 31 KiB After Width: | Height: | Size: 31 KiB |
|
Before Width: | Height: | Size: 67 KiB After Width: | Height: | Size: 67 KiB |
|
Before Width: | Height: | Size: 19 KiB After Width: | Height: | Size: 19 KiB |
|
Before Width: | Height: | Size: 58 KiB After Width: | Height: | Size: 58 KiB |
|
Before Width: | Height: | Size: 31 KiB After Width: | Height: | Size: 31 KiB |
|
Before Width: | Height: | Size: 175 KiB After Width: | Height: | Size: 175 KiB |
|
Before Width: | Height: | Size: 19 KiB After Width: | Height: | Size: 19 KiB |
|
Before Width: | Height: | Size: 31 KiB After Width: | Height: | Size: 31 KiB |
|
Before Width: | Height: | Size: 72 KiB After Width: | Height: | Size: 72 KiB |
|
Before Width: | Height: | Size: 19 KiB After Width: | Height: | Size: 19 KiB |
|
Before Width: | Height: | Size: 31 KiB After Width: | Height: | Size: 31 KiB |
|
Before Width: | Height: | Size: 57 KiB After Width: | Height: | Size: 57 KiB |
|
Before Width: | Height: | Size: 67 KiB After Width: | Height: | Size: 67 KiB |
|
Before Width: | Height: | Size: 91 KiB After Width: | Height: | Size: 91 KiB |
|
Before Width: | Height: | Size: 24 KiB After Width: | Height: | Size: 24 KiB |
@@ -1,9 +1,22 @@
|
||||
{{ $src := .Get "src" | relURL }}
|
||||
{{ $src := .Get "src" }}
|
||||
{{ $version := index (split $.Page.File.Path "/") 1 }}
|
||||
{{/*
|
||||
TODO: Remove this check once we no longer have doc releases
|
||||
with non versioned images. As-is just point them to "edge" since
|
||||
that version will not have the image bundled with the versioned
|
||||
markdown content.
|
||||
*/}}
|
||||
{{ if (hasPrefix $src "/img/") }}
|
||||
{{ $src = strings.TrimPrefix "/img/" $src }}
|
||||
{{ $version = "edge" }}
|
||||
{{ end }}
|
||||
|
||||
{{ $relPath := printf "/docs/%s/images/%s" $version $src }}
|
||||
{{ $caption := .Get "caption" | markdownify }}
|
||||
{{ $width := .Get "width" | default 50 }}
|
||||
{{ $alt := cond (isset .Params "caption") $caption (.Get "alt" | markdownify) }}
|
||||
<figure class="figure">
|
||||
<img src="{{ $src }}" width="{{ $width }}%">
|
||||
<img src="{{ $relPath }}" width="{{ $width }}%">
|
||||
|
||||
{{ with $caption }}
|
||||
<figcaption class="has-text-weight-light">
|
||||
|
||||