June 20-22 Announcing HashiConf Europe full schedule: keynotes, sessions, labs & more Register Now
  • Overview
    • Consul on Kubernetes
    • Control access with Consul API Gateway
    • Discover Services with Consul
    • Enforce Zero Trust Networking with Consul
    • Load Balancing with Consul
    • Manage Traffic with Consul
    • Multi-Platform Service Mesh with Consul
    • Network Infrastructure Automation with Consul
    • Observability with Consul
  • Enterprise
  • Tutorials
  • Docs
  • API
  • CLI
  • Community
GitHub
Download
Try HCP Consul
    • v1.12.x (latest)
    • v1.11.x
    • v1.10.x
    • v1.9.x
    • v1.8.x
    • Overview
      • Overview
      • What is a Service Mesh?
      • Overview
      • Chef, Puppet, etc.
      • Nagios
      • SkyDNS
      • SmartStack
      • Serf
      • Eureka
      • Istio
      • Envoy and Other Proxies
      • Custom Solutions
    • Overview
    • Manual Bootstrap
    • Consul Agent
    • Glossary
    • Required Ports
    • Bootstrapping a Datacenter
    • Cloud Auto-join
    • Server Performance
    • Kubernetes
  • API
  • Commands (CLI)
    • Register Services - Service Definitions
    • Find Services - DNS Interface
    • Monitor Services - Check Definitions
    • Overview
    • How Service Mesh Works
    • Configuration
      • Overview
      • Ingress Gateway
      • Mesh
      • Exported Services
      • Proxy Defaults
      • Service Defaults
      • Service Intentions
      • Service Resolver
      • Service Router
      • Service Splitter
      • Terminating Gateway
      • Overview
      • Envoy
      • Built-in Proxy
      • Proxy Integration
      • Managed (Deprecated)
      • Overview
      • Proxy Service Registration
      • Sidecar Service Registration
    • Service-to-service permissions - Intentions
    • Service-to-service permissions - Intentions (Legacy Mode)
    • Transparent Proxy
      • Overview
      • UI Visualization
      • Overview
      • Discovery Chain
    • Connectivity Tasks
    • Distributed Tracing
      • Overview
        • WAN Federation
        • Enabling Service-to-service Traffic Across Datacenters
        • Enabling Service-to-service Traffic Across Admin Partitions
      • Ingress Gateways
      • Terminating Gateways
    • Nomad
    • Kubernetes
      • Overview
      • Go Integration
      • Overview
      • Built-In CA
      • Vault
      • ACM Private CA
    • Develop and Debug
    • Security
    • Overview
    • Installation
    • Technical Specifications
    • Common Errors
    • Upgrades
    • Overview
    • Architecture
      • Installing Consul on Kubernetes
      • Installing Consul K8s CLI
        • Minikube
        • Kind
        • AKS (Azure)
        • EKS (AWS)
        • GKE (Google Cloud)
        • Red Hat OpenShift
        • Self Hosted Kubernetes
        • Consul Clients Outside Kubernetes
        • Consul Servers Outside Kubernetes
        • Single Consul Datacenter in Multiple Kubernetes Clusters
        • Consul Enterprise
        • Overview
        • Federation Between Kubernetes Clusters
        • Federation Between VMs and Kubernetes
        • Overview
        • Systems Integration
          • Overview
          • Bootstrap Token
          • Enterprise License
          • Gossip Encryption Key
          • Partition Token
          • Replication Token
          • Server TLS
          • Service Mesh Certificates
          • Snapshot Agent Config
        • WAN Federation
      • Compatibility Matrix
      • Overview
      • Transparent Proxy
      • Ingress Gateways
      • Terminating Gateways
      • Ingress Controllers
      • Configuring a Connect CA Provider
      • Health Checks
        • Metrics
    • Service Sync
      • Overview
      • Upgrade An Existing Cluster to CRDs
    • Annotations and Labels
    • Consul DNS
      • Upgrading Consul on Kubernetes
      • Upgrading Consul K8s CLI
      • Uninstall
      • Certificate Rotation
      • Gossip Encryption Key Rotation
      • Configure TLS on an Existing Cluster
      • Common Error Messages
      • FAQ
    • Helm Chart Configuration
    • Consul K8s CLI Reference
    • Overview
    • Requirements
    • Task Resource Usage
      • Installation
      • Secure Configuration
      • Migrate Existing Tasks
      • Installation
      • Secure Configuration
      • ACL Controller
    • Architecture
    • Consul Enterprise
    • Configuration Reference
    • Overview
      • Installation
      • Requirements
      • Configure
      • Run Consul-Terraform-Sync
    • Architecture
      • Overview
      • Status
      • Tasks
      • Overview
      • task
    • Configuration
    • Tasks
    • Terraform Modules
      • Overview
      • License
      • Terraform Cloud Driver
      • Overview
      • Terraform
      • Terraform Cloud
    • Compatibility
    • Consul KV
    • Sessions
    • Watches
    • Overview
      • General
      • CLI Reference
      • Configuration Reference
    • Configuration Entries
    • Telemetry
    • Sentinel
    • RPC
    • Overview
      • ACL System Overview
      • Tokens
      • Policies
      • Roles
      • Rules Reference
      • Legacy Mode
      • Token Migration
      • ACLs in Federated Datacenters
        • Overview
        • Kubernetes
        • JWT
        • OIDC
        • AWS IAM
    • Encryption
      • Overview
      • Core
      • Network Infrastructure Automation
    • Overview
    • Admin Partitions
    • Audit Logging
    • Automated Backups
    • Automated Upgrades
    • Enhanced Read Scalability
    • Single sign-on - OIDC
    • Redundancy Zones
    • Advanced Federation
    • Network Segments
    • Namespaces
    • NIA with TFE
    • Sentinel
      • Overview
      • FAQ
    • Overview
    • Improving Consul Resilience
    • Anti-Entropy
    • Consensus Protocol
    • Gossip Protocol
    • Jepsen Testing
    • Network Coordinates
    • Consul Integration Program
    • NIA Integration Program
    • Vault Integration
    • Proxy Integration
  • Consul Tools
    • Overview
    • Compatibility Promise
    • Specific Version Details
      • Overview
      • General Process
      • Upgrading to 1.2.4
      • Upgrading to 1.6.9
      • Upgrading to 1.8.13
      • Upgrading to 1.10.0
    • Common Error Messages
    • FAQ
    • Overview
      • v1.11.x
      • v1.10.x
      • v1.9.x
      • v0.1.x
      • v0.2.x
      • v0.4.x
      • v0.3.x
      • v0.2.x
      • v0.5.x
      • v0.6.0-beta
    • Overview
    • ACL
  • Guides
Type '/' to Search

»Policies

This topic describes policies, which are components in Consul's access control list (ACL) system. Policies define which services and agents are authorized to interact with resources in the network.

»Introduction

A policy is a group of one or more ACL rules that are linked to ACL tokens. The following diagram describes the relationships between rules, policies, and tokens:

ACL system component relationships

The term "policy" should not be confused with the keyword policy. The keyword is a rule-level element that determines access to a resource (see Policy Dispositions).

»Rules

Rules are one of several attributes that form a policy. They are building blocks that define access to resources.

This section describes about how to assemble rules into policies. Refer to the ACL Rules Reference for additional details about how to configure rules and how they affect access to resources.

»Rule Specification

A rule is composed of a resource declaration and an access level defined with the policy keyword and a policy disposition. The following syntax describes the basic structure of a rule:

Basic syntax for configuring an ACL rule
Basic syntax for configuring an ACL rule
HCL
  • HCL
  • JSON
<resource> {
  policy = "<policy disposition>"
}
<resource> {
  policy = "<policy disposition>"
}
{
  "<resource>": {
    "policy": "<policy disposition>"
  }
}
{
  "<resource>": {
    "policy": "<policy disposition>"
  }
}

Access to the specified resource is granted or denied based on the policy disposition.

»Resource Labels

Many resources take an additional value that limits the scope of the rule to resources with the same label. A resource label can be the name of a specific set of resources, such as nodes configured with the same name value.

The following syntax describes how to include a resource label in the rule:

Syntax for applying an ACL rule to named resources
Syntax for applying an ACL rule to named resources
HCL
  • HCL
  • JSON
<resource> "<label>" {
  policy = "<policy disposition>"
}
<resource> "<label>" {
  policy = "<policy disposition>"
}
{
  "<resource>": {
    "<label>": {
      "policy": "<policy disposition>"
    }
  }
}
{
  "<resource>": {
    "<label>": {
      "policy": "<policy disposition>"
    }
  }
}

Labels provide operators with more granular control over access to the resource, but the following resource types do not take a label:

  • acl
  • keyring
  • mesh
  • operator

Use the following syntax to create rules for these resources:

Syntax for resources that take ACL rule configurations directly
Syntax for resources that take ACL rule configurations directly
HCL
  • HCL
  • JSON
<resource> = "<policy disposition>"
<resource> = "<policy disposition>"
{
  "<resource>": "<policy disposition>"
}
{
  "<resource>": "<policy disposition>"
}

»Policy Dispositions

Use the policy keyword and one of the following access levels to set a policy disposition:

  • read: Allows the resource to be read but not modified.
  • write: Allows the resource to be read and modified.
  • deny: Denies read and write access to the resource.

The special list access level provides access to all keys with the specified resource label in the Consul KV. The list access level can only be used with the key_prefix resource. The acl.enable_key_list_policy setting must be set to true.

»Matching and Prefix Values

You can define rules for labeled resources based on exact matches or by using resource prefixes to match several resource labels beginning with the same value. Matching resource labels on exact values is described in the Resource Labels section.

The following example rule is an exact match that denies access to services labeled web-prod:

Example rule that denies access to services named 'web-prod'
Example rule that denies access to services named 'web-prod'
HCL
  • HCL
  • JSON
service "web-prod" {
  policy = "deny"
}
service "web-prod" {
  policy = "deny"
}
{
  "service": {
    "web-prod": {
      "policy": "deny"
    }
  }
}
{
  "service": {
    "web-prod": {
      "policy": "deny"
    }
  }
}

You can append the resource with _prefix to match all resource labels beginning with the same value. The following example rule allows write access to all services with labels that begin with "web":

Example rule that grants read and write access to services with names beginning with 'web'
Example rule that grants read and write access to services with names beginning with 'web'
HCL
  • HCL
  • JSON
service_prefix "web" {
  policy = "write"
}
service_prefix "web" {
  policy = "write"
}
{
  "service_prefix": {
    "web": {
      "policy": "write"
    }
  }
}
{
  "service_prefix": {
    "web": {
      "policy": "write"
    }
  }
}

Prefix-based resource labels can also contain an empty string, which configures the rule to apply to all resources of the declared type. The following example rule allows read access to all service resources:

Example rule that grants read access to all services
Example rule that grants read access to all services
HCL
  • HCL
  • JSON
service_prefix "" {
  policy = "read"
}
service_prefix "" {
  policy = "read"
}
{
  "service_prefix": {
    "": {
      "policy":"read"
    }
  }
}
{
  "service_prefix": {
    "": {
      "policy":"read"
    }
  }
}

When using prefix-based rules, the most specific prefix match determines the action. In a real-world scenario, a combination of rules would be combined to create a flexible policy. Each team or business unit would use tokens based on policies that enforce several rules, for example:

  • A rule that denies access to a specific resource label
  • A prefix-based rule that allows write access to a class of resources
  • An empty prefix that grants read-only access to all resources within the declared class

»Matching Precedence

Exact matching rules will only apply to the exact resource specified. The order of precedence for matching rules are:

  1. deny (highest priority)
  2. write
  3. read

»Policy Format

Define policies using the HashiCorp Configuration Language (HCL). HCL is human readable and interoperable with JSON, making it easy to automate policy generation. The following examples show the same policy formatted in HCL and JSON:

Example rules
Example rules
HCL
  • HCL
  • JSON
# These control access to the key/value store.
key_prefix "" {
  policy = "read"
}
key_prefix "foo/" {
  policy = "write"
}
key_prefix "foo/private/" {
  policy = "deny"
}
# Or for exact key matches
key "foo/bar/secret" {
  policy = "deny"
}

# This controls access to cluster-wide Consul operator information.
operator = "read"
# These control access to the key/value store.
key_prefix "" {
  policy = "read"
}
key_prefix "foo/" {
  policy = "write"
}
key_prefix "foo/private/" {
  policy = "deny"
}
# Or for exact key matches
key "foo/bar/secret" {
  policy = "deny"
}

# This controls access to cluster-wide Consul operator information.
operator = "read"
{
  "key_prefix": {
    "": {
      "policy": "read"
    },
    "foo/": {
      "policy": "write"
    },
    "foo/private/": {
      "policy": "deny"
    }
  },
  "key": {
    "foo/bar/secret": {
      "policy": "deny"
    }
  },
  "operator": "read"
}
{
  "key_prefix": {
    "": {
      "policy": "read"
    },
    "foo/": {
      "policy": "write"
    },
    "foo/private/": {
      "policy": "deny"
    }
  },
  "key": {
    "foo/bar/secret": {
      "policy": "deny"
    }
  },
  "operator": "read"
}

»Rule Scope

The rules from all policies, including roles and service identities, linked with a token are combined to form that token's effective rule set. Policy rules can be defined in either an allowlist or denylist mode, depending on the configuration of the acl_default_policy. If the default policy is configured to deny access to all resources, then you can specify allowlist in policy rules to explicitly allow access to resources. Conversely, if the default policy is configured to allow access to all resources, then you can specify denylist in policy rules to explicitly deny access to resources.

»Implementing Policies

After defining policies, the person responsible for administrating ACLs in your organization can implement them through the command line or by calling the ACL HTTP API endpoint and including rules in the payload.

»Command Line

Use the consul acl policy command to manage policies. Refer to the ACL command line documentation for details.

The following example creates a policy called my-app-policy and applies the rules defined in rules.hcl:

$ consul acl policy create -name "my-app-policy" -description "Human-readable description of my policy" -rules @rules.hcl -token "<token with ACL 'write' access>"
$ consul acl policy create -name "my-app-policy" -description "Human-readable description of my policy" -rules @rules.hcl -token "<token with ACL 'write' access>"

Note that the command must present a token with permissions to use the ACL system. If the command is issued successfully, the console wil print information about the policy:

ID:           <auto-generated ID>
Name:         my-app-policy
Description:  Human-readable description of my policy
Datacenters:  <specified with the -valid-datacenter option>
Rules:
<rules defined in the rules.hcl file>
ID:           <auto-generated ID>
Name:         my-app-policy
Description:  Human-readable description of my policy
Datacenters:  <specified with the -valid-datacenter option>
Rules:
<rules defined in the rules.hcl file>

You can can define several attributes that attach additional metadata and specify the scope of the policy. See Policy Attributes for details.

»HTTP API Endpoint

The endpoint takes data formatted in HCL or JSON. Refer to the ACL HTTP API endpoint documentation for details about the API.

The following example adds a set of rules to a policy called my-app-policy. The policy defines access to the key resource (Consul K/V). The rules are formatted in HCL, but they are wrapped in JSON so that the data can be sent using cURL:

$ curl \
    --request PUT \
    --data \
'{
  "Name": "my-app-policy",
  "Rules": "key \"\" { policy = \"read\" } key \"foo/\" { policy = \"write\" } key \"foo/private/\" { policy = \"deny\" } operator = \"read\""
}' http://127.0.0.1:8500/v1/acl/policy?token=<token with ACL "write" access>
$ curl \
    --request PUT \
    --data \
'{
  "Name": "my-app-policy",
  "Rules": "key \"\" { policy = \"read\" } key \"foo/\" { policy = \"write\" } key \"foo/private/\" { policy = \"deny\" } operator = \"read\""
}' http://127.0.0.1:8500/v1/acl/policy?token=<token with ACL "write" access>

The following call performs the same operation as the previous example using JSON:

$ curl \
    --request PUT \
    --data \
'{
  "Name": "my-app-policy",
  "Rules": "{\"key\":{\"\":{\"policy\":\"read\"},\"foo/\":{\"policy\":\"write\"},\"foo/private\":{\"policy\":\"deny\"}},\"operator\":\"read\"}"
}' http://127.0.0.1:8500/v1/acl/policy?token=<management token>
$ curl \
    --request PUT \
    --data \
'{
  "Name": "my-app-policy",
  "Rules": "{\"key\":{\"\":{\"policy\":\"read\"},\"foo/\":{\"policy\":\"write\"},\"foo/private\":{\"policy\":\"deny\"}},\"operator\":\"read\"}"
}' http://127.0.0.1:8500/v1/acl/policy?token=<management token>

The policy configuration is returned when the call is successfully performed:

{
  "CreateIndex": 7,
  "Hash": "UMG6QEbV40Gs7Cgi6l/ZjYWUwRS0pIxxusFKyKOt8qI=",
  "ID": "5f423562-aca1-53c3-e121-cb0eb2ea1cd3",
  "ModifyIndex": 7,
  "Name": "my-app-policy",
  "Rules": "key \"\" { policy = \"read\" } key \"foo/\" { policy = \"write\" } key \"foo/private/\" { policy = \"deny\" } operator = \"read\""
}
{
  "CreateIndex": 7,
  "Hash": "UMG6QEbV40Gs7Cgi6l/ZjYWUwRS0pIxxusFKyKOt8qI=",
  "ID": "5f423562-aca1-53c3-e121-cb0eb2ea1cd3",
  "ModifyIndex": 7,
  "Name": "my-app-policy",
  "Rules": "key \"\" { policy = \"read\" } key \"foo/\" { policy = \"write\" } key \"foo/private/\" { policy = \"deny\" } operator = \"read\""
}

»Linking Policies to Tokens

A policy that has been implemented must still be linked to a token before the policy has an effect. A service or agent presents the token when interacting with resources in the network. The ACL system processes evaluate the policies linked to the token to determine if the requester has access to the requested resource.

The person responsible for administrating ACLs can use the command line or call the API endpoint to link policies to tokens. Tokens can also be generated dynamically from an external system using Consul's auth methods functionality.

Refer to the tokens documentation, as well as the ACL tutorial, for details about creating and linking policies to tokens.

»Policy Attributes

Policies may have several attributes that enable you to perform specific functions. For example, you can configure the policy's scope by specifying the name of a datacenter, namespace (Consul Enterprise), or administrative partition (Consul Enterprise) when interacting or creating policies.

Additional metadata, such as the values of the ID and name fields, provide handles for updating and managing policies.

Refer to the following topics for additional information:

  • Namespaces
  • Admin Partitions

ACL policies can have the following attributes:

AttributeDescriptionRequiredDefault
IDThe policy's public identifier. Present the ID (or the name) value when interacting with policies. You can specify a value when creating policies or use the value auto-generated by Consul.N/AN/A
nameUnique name for the policy.Requirednone
descriptionHuman readable description of the policy.Optionalnone
rulesSet of rules granting or denying permissions. See the Rule Specification documentation for more details.Optionalnone
datacenterDatacenter in which the policy is valid. More than one datacenter can be specified.Optionalnone
namespace
Enterprise
Namespace in which the policy is valid. Added in Consul Enterprise 1.7.0.
Optionaldefault
partition
Enterprise
Admin partition in which the policy is valid. Added in Consul Enterprise 1.11.0
Optionaldefault

Non-default Namespaces and Partitions - Rules defined in a policy tied to an namespace or admin partition other than default can only grant a subset of privileges that affect the namespace or partition. See Namespace Rules and Admin Partition Rules for additional information.

You can view the current ACL policies on the command line or through the API. The following example demonstrates the command line usage:

$ consul acl policy list -format json -token <token_id>
[
    {
        "ID": "56595ec1-52e4-d6de-e566-3b78696d5459",
        "Name": "b-policy",
        "Description": "",
        "Datacenters": null,
        "Hash": "ULwaXlI6Ecqb9YSPegXWgVL1LlwctY9TeeAOhp5HGBA=",
        "CreateIndex": 126,
        "ModifyIndex": 126,
        "Namespace": "default",
        "Partition": "default"
    },
    {
        "ID": "00000000-0000-0000-0000-000000000001",
        "Name": "global-management",
        "Description": "Builtin Policy that grants unlimited access",
        "Datacenters": null,
        "Hash": "W1bQuDAlAlxEb4ZWwnVHplnt3I5oPKOZJQITh79Xlog=",
        "CreateIndex": 70,
        "ModifyIndex": 70,
        "Namespace": "default",
        "Partition": "default"
    }
]
$ consul acl policy list -format json -token <token_id>
[
    {
        "ID": "56595ec1-52e4-d6de-e566-3b78696d5459",
        "Name": "b-policy",
        "Description": "",
        "Datacenters": null,
        "Hash": "ULwaXlI6Ecqb9YSPegXWgVL1LlwctY9TeeAOhp5HGBA=",
        "CreateIndex": 126,
        "ModifyIndex": 126,
        "Namespace": "default",
        "Partition": "default"
    },
    {
        "ID": "00000000-0000-0000-0000-000000000001",
        "Name": "global-management",
        "Description": "Builtin Policy that grants unlimited access",
        "Datacenters": null,
        "Hash": "W1bQuDAlAlxEb4ZWwnVHplnt3I5oPKOZJQITh79Xlog=",
        "CreateIndex": 70,
        "ModifyIndex": 70,
        "Namespace": "default",
        "Partition": "default"
    }
]

The Hash, CreateIndex, and ModifyIndex attributes are also printed. These attributes are printed for all responses and are not specific to ACL policies.

»Built-in Policies

New installations of Consul ship with the following built-in policies.

»Global Management

The global-management policy grants unrestricted privileges to any token linked to it. The policy is assigned the reserved ID of 00000000-0000-0000-0000-000000000001. You can rename the global management policy, but Consul will prevent you from modifying any other attributes, including the rule set and datacenter scope.

»Namespace Management
Enterprise

The namespace-management policy will be injected into all namespaces you create. The policy will be assigned a randomized UUID and can be managed as a normal, user-defined policy within the namespace. This feature was added in Consul Enterprise 1.7.0.

»Example Policies

This section includes example policy configurations for achieving specific use-cases.

»Enable the Snapshot Agent to Run on a Specific Node

The consul snapshot agent command starts a process that takes snapshots of the state of the Consul servers and either saves them locally or pushes them to a remote storage service. Refer to Consul Snapshot Agent for additional information.

In the following example, the ACL policy enables the snapshot agent to run on a node named server-1234.

HCL
  • HCL
  • JSON
# Required to read and snapshot ACL data
acl = "write"
# Allow the snapshot agent to create the key consul-snapshot/lock which will
# serve as a leader election lock when multiple snapshot agents are running in
# an environment
key "consul-snapshot/lock" {
  policy = "write"
}
# Allow the snapshot agent to create sessions on the specified node
session "server-1234" {
  policy = "write"
}
# Allow the snapshot agent to register itself into the catalog
service "consul-snapshot" {
  policy = "write"
}
# Required to read and snapshot ACL data
acl = "write"
# Allow the snapshot agent to create the key consul-snapshot/lock which will
# serve as a leader election lock when multiple snapshot agents are running in
# an environment
key "consul-snapshot/lock" {
  policy = "write"
}
# Allow the snapshot agent to create sessions on the specified node
session "server-1234" {
  policy = "write"
}
# Allow the snapshot agent to register itself into the catalog
service "consul-snapshot" {
  policy = "write"
}
{
  "acl": "write",
  "key": {
    "consul-snapshot/lock": {
      "policy": "write"
    }
  },
  "session": {
    "server-1234": {
      "policy": "write"
    }
  },
  "service": {
    "consul-snapshot": {
      "policy": "write"
    }
  }
}
{
  "acl": "write",
  "key": {
    "consul-snapshot/lock": {
      "policy": "write"
    }
  },
  "session": {
    "server-1234": {
      "policy": "write"
    }
  },
  "service": {
    "consul-snapshot": {
      "policy": "write"
    }
  }
}

»Enable Vault to Access the Consul Storage Backend

If you are using Vault to manage secrets in your infrastructure, you can configure Vault to use Consul's key/value (KV) store as backend storage to persist Vault's data. Refer to the Consul KV documentation and the Vault storage documentation for additional information.

In the following example, the ACL policy enables Vault to register as a service and provides access to the vault/ path in Consul's KV store.

HCL
  • HCL
  • JSON
# Provide KV visibility to all agents.
agent_prefix "" {
  policy = "read"
}
# Enable resources prefixed with 'vault/' to write to the KV
key_prefix "vault/" {
  policy = "write"
}
# Enable the vault service to write to the KV
service "vault" {
  policy = "write"
}
# Enable the agent to initialize a new session.
session_prefix "" {
  policy = "write"
}
# Provide KV visibility to all agents.
agent_prefix "" {
  policy = "read"
}
# Enable resources prefixed with 'vault/' to write to the KV
key_prefix "vault/" {
  policy = "write"
}
# Enable the vault service to write to the KV
service "vault" {
  policy = "write"
}
# Enable the agent to initialize a new session.
session_prefix "" {
  policy = "write"
}
{
  "agent_prefix": {
    "": {
      "policy": "read"
    }
  },
  "key_prefix": {
    "vault/": {
      "policy": "write"
    }
  },
  "service": {
    "vault": {
      "policy": "write"
    }
  },
  "session_prefix": {
    "": {
      "policy": "write"
    }
  }
}
{
  "agent_prefix": {
    "": {
      "policy": "read"
    }
  },
  "key_prefix": {
    "vault/": {
      "policy": "write"
    }
  },
  "service": {
    "vault": {
      "policy": "write"
    }
  },
  "session_prefix": {
    "": {
      "policy": "write"
    }
  }
}
github logoEdit this page
IntroGuidesDocsCommunityPrivacySecurityBrandConsent Manager