github.com/bhameyie/otto@v0.2.1-0.20160406174117-16052efa52ec/website/source/docs/concepts/policies.html.md (about)

     1  ---
     2  layout: "docs"
     3  page_title: "Policies"
     4  sidebar_current: "docs-concepts-policies"
     5  description: |-
     6    Policies are how authorization is done in Vault, allowing you to restrict which parts of Vault a user can access.
     7  ---
     8  
     9  # Access Control Policies
    10  
    11  After [authenticating](/docs/concepts/auth.html) with Vault, the
    12  next step is authorization. This is the process of determining what
    13  a user is allowed to do. Authorization is unified in Vault in the form
    14  of _policies_.
    15  
    16  Policies are [HCL](https://github.com/hashicorp/hcl) or JSON documents
    17  that describe what parts of Vault a user is allowed to access. An example
    18  of a policy is shown below:
    19  
    20  ```javascript
    21  path "sys/*" {
    22    policy = "deny"
    23  }
    24  
    25  path "secret/*" {
    26    policy = "write"
    27  }
    28  
    29  path "secret/foo" {
    30    policy = "read"
    31  }
    32  
    33  path "secret/super-secret" {
    34    policy = "deny"
    35  }
    36  ```
    37  
    38  Policies use path based matching to apply rules. A policy may be an exact
    39  match, or might be a glob pattern which uses a prefix. The default policy
    40  is always deny so if a path isn't explicitly allowed, Vault will reject access to it.
    41  This works well due to Vault's architecture of being like a filesystem:
    42  everything has a path associated with it, including the core configuration
    43  mechanism under "sys".
    44  
    45  ~> Policy paths are matched using the most specific defined policy. This may
    46  be an exact match or the longest-prefix match of a glob. This means if you
    47  define a policy for `"secret/foo*"`, the policy would also match `"secret/foobar"`.
    48  The glob character is only supported at the end of the path specification.
    49  
    50  ## Policies
    51  
    52  Allowed policies for a path are:
    53  
    54    * `deny` - No access allowed. Highest precedence.
    55  
    56    * `sudo` - Read, write, and root access to a path.
    57  
    58    * `write` - Read, write access to a path.
    59  
    60    * `read` - Read-only access to a path.
    61  
    62  The only non-obvious policy is "sudo". Some routes within Vault and mounted
    63  backends are marked as _root_ paths. Clients aren't allowed to access root
    64  paths unless they are a root user (have the special policy "root") or
    65  have access to that path with the "sudo" policy.
    66  
    67  For example, modifying the audit log backends is done via root paths.
    68  Only root or "sudo" privilege users are allowed to do this.
    69  
    70  ## Root Policy
    71  
    72  The "root" policy is a special policy that can not be modified or removed.
    73  Any user associated with the "root" policy becomes a root user. A root
    74  user can do _anything_ within Vault.
    75  
    76  There always exists at least one root user (associated with the token
    77  when initializing a new server). After this root user, it is recommended
    78  to create more strictly controlled users. The original root token should
    79  be protected accordingly.
    80  
    81  ## Managing Policies
    82  
    83  Policy management can be done via the API or CLI. The CLI commands are
    84  `vault policies` and `vault policy-write`. Please see the help associated
    85  with these commands for more information. They are very easy to use.
    86  
    87  ## Associating Policies
    88  
    89  To associate a policy with a user, you must consult the documentation for
    90  the authentication backend you're using.
    91  
    92  For tokens, they are associated at creation time with `vault token-create`
    93  and the `-policy` flags. Child tokens can be associated with a subset of
    94  a parent's policies. Root users can assign any policies.
    95  
    96  There is no way to modify the policies associated with an active
    97  identity. The identity must be revoked and reauthenticated to receive
    98  the new policy list.
    99  
   100  If an _existing_ policy is modified, the modifications propagate
   101  to all associated users instantly. The above paragraph is more specifically
   102  stating that you can't add new or remove policies associated with an
   103  active identity.
   104  
   105  ## Changes from 0.1
   106  
   107  In Vault versions prior to 0.2, the ACL policy language had a slightly
   108  different specification and semantics. The current specification requires
   109  that glob behavior explicitly be specified by adding the `*` character to
   110  the end of a path. Previously, all paths were glob based matches and no
   111  exact match could be specified.
   112  
   113  The other change is that deny had the lowest precedence. This meant if there
   114  were two policies being merged (e.g. "ops" and "prod") and they had a conflicting
   115  policy like:
   116  
   117  ```
   118  path "sys/seal" {
   119      policy = "deny"
   120  }
   121  
   122  path "sys/seal" {
   123      policy = "read"
   124  }
   125  ```
   126  
   127  The merge would previously give the "read" higher precedence. The current
   128  version of Vault prioritizes the explicit deny, so that the "deny" would
   129  take precedence.
   130  
   131  To make all Vault 0.1 policies compatible with Vault 0.2, the explicit
   132  glob character must be added to all the path prefixes.
   133