Various manual fixes for syntax highlighting and lists; much prettier docs ensue.

This commit is contained in:
John Mulhausen
2016-02-17 16:18:59 -08:00
parent d6311dbd19
commit f0aea25011
102 changed files with 1486 additions and 1364 deletions
+4 -4
View File
@@ -12,6 +12,7 @@ the request, (such as user, resource, and namespace) with access
policies. An API call must be allowed by some policy in order to proceed.
The following implementations are available, and are selected by flag:
- `--authorization-mode=AlwaysDeny`
- `--authorization-mode=AlwaysAllow`
- `--authorization-mode=ABAC`
@@ -25,6 +26,7 @@ The following implementations are available, and are selected by flag:
### Request Attributes
A request has 5 attributes that can be considered for authorization:
- user (the user-string which a user was authenticated as).
- group (the list of group names the authenticated user is a member of).
- whether the request is readonly (GETs are readonly).
@@ -46,6 +48,7 @@ The file format is [one JSON object per line](http://jsonlines.org/). There sho
one map per line.
Each line is a "policy object". A policy object is a map with the following properties:
- `user`, type string; the user-string from `--token-auth-file`. If you specify `user`, it must match the username of the authenticated user.
- `group`, type string; if you specify `group`, it must match one of the groups of the authenticated user.
- `readonly`, type boolean, when true, means that the policy only applies to GET
@@ -125,7 +128,4 @@ An authorization module can be completely implemented in go, or can call out
to a remote authorization service. Authorization modules can implement
their own caching to reduce the cost of repeated authorization calls with the
same or similar arguments. Developers should then consider the interaction between
caching and revocation of permissions.
caching and revocation of permissions.