ACL 규칙 구성 참조

ACL 규칙 구성 참조 (ACL rule configuration reference)

생성할 수 있는 액세스 제어 목록(ACL) 규칙의 유형과 이것이 데이터센터 리소스에 대한 액세스에 어떤 영향을 미치는지에 대한 참조 정보를 제공해요. 규칙을 만들고 정책으로 그룹화하는 방법은 정책(Policies)을 참조하세요.

출처: 문서

본문

이 항목은 생성할 수 있는 액세스 제어 목록(ACL) 규칙의 유형과 규칙이 데이터센터 리소스에 대한 액세스에 어떤 영향을 미치는지에 대한 참조 정보를 제공합니다. 규칙을 만들고 정책으로 그룹화하는 방법에 대한 자세한 내용은 정책(Policies)을 참조하세요.

개요 (Overview)

다음 표는 ACL 규칙을 만드는 데 사용할 수 있는 리소스에 대한 개요를 제공합니다.

리소스	설명	라벨
acl	ACL API의 ACL 작업에 대한 액세스를 제어합니다. 자세한 내용은 ACL 리소스 규칙을 참조하세요.	아니요
partition partition_prefix	Enterprise 하나 이상의 admin 파티션에 대한 액세스를 제어합니다. 자세한 내용은 Admin 파티션 규칙을 참조하세요.	예
agent agent_prefix	Agent API의 `join` 및 `leave` 같은 유틸리티 작업에 대한 액세스를 제어합니다. 자세한 내용은 Agent 규칙을 참조하세요.	예
event event_prefix	Event API의 이벤트 발생(firing) 및 목록화(listing) 같은 이벤트 작업에 대한 액세스를 제어합니다. 자세한 내용은 Event 규칙을 참조하세요.	예
key key_prefix	KV API의 키/값 저장소 작업에 대한 액세스를 제어합니다. 정책 disposition을 설정할 때 `list` 액세스 수준도 사용할 수 있습니다. Consul Enterprise에서 Sentinel과 통합하기 위한 추가 값 옵션이 있습니다. 자세한 내용은 키/값 규칙을 참조하세요.	예
keyring	Keyring API의 키링 작업에 대한 액세스를 제어합니다. 자세한 내용은 Keyring 규칙을 참조하세요.	아니요
mesh	admin 파티션의 리소스(예: 인그레스 게이트웨이 또는 메시 프록시 기본값)에 대한 운영자 수준 권한을 제공합니다. 자세한 내용은 Mesh 규칙을 참조하세요.	아니요
peering	클러스터 피어링 API(Cluster Peering API)의 클러스터 피어링에 대한 액세스를 제어합니다. 자세한 내용은 Peering 규칙을 참조하세요.	아니요
namespace namespace_prefix	Enterprise 하나 이상의 네임스페이스에 대한 액세스를 제어합니다. 자세한 내용은 Namespace 규칙을 참조하세요.	예
node node_prefix	Catalog API, Health API, Prepared Query API, Network Coordinate API, Agent API의 노드 수준 작업에 대한 액세스를 제어합니다. 자세한 내용은 Node 규칙을 참조하세요.	예
operator	keyring API 엔드포인트를 제외한 Operator API에서 사용 가능한 클러스터 수준 작업에 대한 액세스를 제어합니다. 자세한 내용은 Operator 규칙을 참조하세요.	아니요
query query_prefix	Prepared Query API에서 prepared query를 생성, 업데이트, 삭제하기 위한 액세스를 제어합니다. 노드와 서비스에 대한 액세스도 부여되어야 합니다. 자세한 내용은 Prepared Query 규칙을 참조하세요.	예
service service_prefix	Catalog API, Health API, Intentions API, Prepared Query API, Agent API의 서비스 수준 작업을 제어합니다. 자세한 내용은 Service 규칙을 참조하세요.	예
session session_prefix	Session API의 작업에 대한 액세스를 제어합니다. 자세한 내용은 Session 규칙을 참조하세요.	예

다음 리소스는 ACL 정책으로 다루지 않습니다.

Status API는 서버가 부트스트랩할 때 사용되며 서버에 대한 기본 IP 및 포트 정보를 노출하지만 상태를 수정할 수는 없습니다.
Catalog API의 데이터센터 목록 작업은 알려진 Consul 데이터센터의 이름만 노출하며 상태를 수정할 수는 없습니다.
서비스 메시 CA 루트 엔드포인트는 다른 시스템이 Consul과의 TLS 연결을 확인하는 데 사용할 수 있는 공용 TLS 인증서만 노출합니다.

Consul Enterprise 네임스페이스 — 직접 연결된 정책, 역할, 서비스 ID에 더해 Consul Enterprise는 ACL 정책과 역할을 네임스페이스 정의에서 정의할 수 있게 합니다(Consul Enterprise 1.7.0+).

다음 항목은 사용 가능한 리소스에 대한 추가 세부 정보를 제공합니다.

ACL 리소스 규칙 (ACL Resource Rules)

acl 리소스는 ACL API의 ACL 작업에 대한 액세스를 제어합니다. 정책당 하나의 acl 규칙만 허용됩니다. 값은 정책 disposition 중 하나로 설정됩니다.

스냅샷을 생성하려면 acl = "write" 규칙도 필요합니다. 모든 토큰 시크릿이 스냅샷에 포함되기 때문입니다.

ACL 리소스에 대한 규칙은 라벨을 사용하지 않습니다.

다음 예시에서 acl 규칙은 ACL API에 대한 쓰기 액세스로 구성됩니다.

이 규칙은 운영자가 ACL을 읽거나 쓸 수 있게 하고, 모든 토큰의 시크릿 ID를 발견할 수 있게 합니다.

예시 acl 규칙

acl = "write"

{
  "acl": "write"
}

Admin 파티션 규칙 (Admin Partition Rules) Enterprise

partition 및 partition_prefix 리소스는 하나 이상의 admin 파티션에 대한 액세스를 제어합니다.

admin 파티션 안에 얼마든지 많은 네임스페이스 규칙을 포함할 수 있습니다.

다음 예시에서 정책은 example 파티션의 ex-namespace 네임스페이스와 exns- 접두사를 가진 네임스페이스에 대한 쓰기 액세스를 부여합니다.

mesh와 peering 리소스도 admin 파티션 규칙에 범위가 지정되어, example 파티션의 mesh 및 peering 리소스에 대한 쓰기 액세스를 부여합니다.

또한 정책은 example- 접두사를 포함하는 모든 파티션의 ex-namespace 네임스페이스와 exns- 접두사를 가진 네임스페이스에 대한 읽기 액세스를 부여합니다. 관련 파티션 내에 범위가 지정된 mesh 및 peering 리소스에 대한 읽기 액세스가 부여됩니다.

예시 admin 파티션 규칙

partition "example" {
  mesh = "write"
  peering = "write"

  node "my-node" {
    policy = "write"
  }

  namespace "ex-namespace" {
    policy = "write"
  }

  namespace_prefix "exns-" {
    policy = "write"
  }
}

partition_prefix "example-" {
  mesh = "read"
  peering = "read"

  node "my-node" {
    policy = "read"
  }

  namespace "ex-namespace" {
    policy = "read"
  }
}

{
  "partition": {
    "example": {
      "mesh": "write",
      "node": {
        "my-node": {
          "policy": "write"
        }
      },
      "namespace": {
        "ex-namespace": {
          "policy": "write"
        }
      },
      "namespace_prefix": {
        "exns-": {
          "policy": "write"
        }
      }
    }
  },
  "partition_prefix": {
    "example-": {
      "mesh": "read",
      "node": {
        "my-node": {
          "policy": "read"
        }
      },
      "namespace": {
        "ex-namespace": {
          "policy": "read"
        }
      }
    }
  }
}

Agent 규칙 (Agent Rules)

agent 및 agent_prefix 리소스는 Agent API의 join 및 leave 같은 유틸리티 작업에 대한 액세스를 제어합니다. 카탈로그 관련 작업은 모두 node/node_prefix 및 service/service_prefix 정책으로 다룹니다.

예시 agent 규칙

agent "foo" {
  policy = "write"
}
agent_prefix "" {
  policy = "read"
}
agent_prefix "bar" {
  policy = "deny"
}

{
  "agent": {
    "foo": {
      "policy": "write"
    }
  },
  "agent_prefix": {
    "": {
      "policy": "read"
    },
    "bar": {
      "policy": "deny"
    }
  }
}

Agent 규칙은 적용되는 노드 이름으로 키가 지정됩니다. 위 예시에서 규칙은 정확히 foo라는 이름의 노드에 대한 읽기-쓰기 액세스, 빈 접두사를 사용한 모든 노드 이름에 대한 읽기 전용 액세스를 허용하고, bar로 시작하는 모든 노드 이름에 대한 모든 액세스를 거부합니다.

Agent API 유틸리티 작업은 에이전트가 클러스터에 조인하기 전이나 Consul 서버 또는 ACL 데이터센터의 중단 동안 필요할 수 있으므로, acl.tokens.agent_recovery로 특수 토큰을 구성해 ACL 해석 기능이 없더라도 이러한 작업에 대한 쓰기 액세스를 허용할 수 있습니다.

Event 규칙 (Event Rules)

event 및 event_prefix 리소스는 Event API의 이벤트 발생과 목록화 같은 이벤트 작업에 대한 액세스를 제어합니다.

예시 event 규칙

event_prefix "" {
  policy = "read"
}
event "deploy" {
  policy = "write"
}

{
  "event_prefix": {
    "": {
      "policy": "read"
    }
  },
  "event": {
    "deploy": {
      "policy": "write"
    }
  }
}

Event 규칙은 적용되는 이벤트 이름으로 라벨이 지정됩니다. 위 예시에서 규칙은 모든 이벤트에 대한 읽기 전용 액세스와 deploy 이벤트의 발생(firing)을 허용합니다.

consul exec 명령은 작동 중에 _rexec 접두사를 가진 이벤트를 사용하므로, ACL이 활성화된 Consul 환경에서 이 기능을 활성화하려면 에이전트에 이 이벤트 접두사에 대한 액세스 권한이 있는 토큰을 부여하는 것에 더해 disable_remote_exec를 false로 구성해야 합니다.

Identity 규칙 (Identity Rules)

identity 규칙에서 리소스 라벨을 지정해 규칙의 범위를 설정합니다.

다음 예시의 리소스 라벨은 비어 있습니다. 결과적으로 규칙은 빈 접두사를 가진 모든 워크로드 ID 이름에 대한 읽기 전용 액세스를 허용합니다.

또한 규칙은 app ID에 대한 읽기-쓰기 액세스를 허용하고 admin ID에 대한 모든 액세스를 거부합니다.

예시 identity 규칙

identity_prefix "" {
  policy = "read"
}
identity "app" {
  policy = "write"
}
identity "admin" {
  policy = "deny"
}

{
  "identity_prefix": {
    "": {
      "policy": "read"
    }
  },
  "identity": {
    "app": {
      "policy": "write"
    },
    "admin": {
      "policy": "deny"
    }
  }
}

키/값 규칙 (Key/Value Rules)

key 및 key_prefix 리소스는 KV API의 키/값 저장소 작업에 대한 액세스를 제어합니다.

예시 key 규칙

key_prefix "" {
  policy = "read"
}
key "foo" {
  policy = "write"
}
key "bar" {
  policy = "deny"
}

{
  "key_prefix": {
    "": {
      "policy": "read"
    }
  },
  "key": {
    "foo": {
      "policy": "write"
    },
    "bar": {
      "policy": "deny"
    }
  }
}

Key 규칙은 적용되는 키 이름으로 라벨이 지정됩니다. 위 예시에서 규칙은 빈 접두사 규칙으로 모든 키 이름에 대한 읽기 전용 액세스를 허용하고, foo 키에 대한 읽기-쓰기 액세스를 허용하며, bar 키에 대한 액세스를 거부합니다.

키에 대한 목록 정책 (List Policy for Keys)

acl.enable_key_list_policy 매개변수를 true로 설정해 list 정책 disposition(Consul 1.0+)을 활성화합니다. 이 disposition은 키 항목에 대한 재귀적 액세스를 제공합니다. 추가 정보는 KV API 문서를 참조하세요.

다음 예시에서 bar로 시작하는 키 리소스를 나열할 수 있습니다.

예시 'key' 규칙

key_prefix "" {
 policy = "deny"
}

key_prefix "bar" {
 policy = "list"
}

key_prefix "baz" {
 policy = "read"
}

{
  "key_prefix": {
    "": {
      "policy": "deny"
    },
    "bar": {
      "policy": "list"
    },
    "baz": {
      "policy": "read"
    }
  }
}

위 예시에서 규칙은 baz 키를 읽는 것을 허용하고 bar 접두사에 대해서만 재귀적 읽기를 허용합니다.

접두사에 대한 쓰기 액세스가 있는 토큰은 목록 액세스도 갖습니다. 접두사에 대한 목록 액세스가 있는 토큰은 모든 하위 접미사에 대한 읽기 액세스도 갖습니다.

Sentinel 통합 Enterprise

Consul Enterprise는 Sentinel 통합을 위한 키 쓰기 정책에 추가 선택적 필드를 지원합니다.

key "foo" {
  policy = "write"
  sentinel {
      code = <<EOF
import "strings"
main = rule { strings.has_suffix(value, "bar") }
EOF
      enforcementlevel = "hard-mandatory"
  }
}

자세한 내용은 Consul Sentinel 문서를 참조하세요.

Keyring 규칙 (Keyring Rules)

keyring 리소스는 Keyring API의 키링 작업에 대한 액세스를 제어합니다. 규칙 세트당 하나의 keyring 정책만 허용됩니다. 값은 정책 disposition 중 하나로 설정되며, 읽고 업데이트할 수 있습니다.

예시 keyring 규칙

keyring = "write"

{
  "keyring": "write"
}

Mesh 규칙 (Mesh Rules)

mesh 리소스는 인그레스 게이트웨이, 터미네이팅 게이트웨이, 메시 구성 항목에 대한 액세스를 제어합니다.

Consul Enterprise에서 mesh 규칙은 admin 파티션에 범위가 지정됩니다. 따라서 admin 파티션 규칙에는 중첩될 수 있지만 네임스페이스 규칙에는 중첩될 수 없습니다.

다음 규칙은 읽기 및 쓰기 액세스를 부여합니다.

예시 mesh 규칙

mesh = "write"

{
  "mesh": "write"
}

mesh 리소스를 사용하는 또 다른 예시 규칙은 Admin 파티션 규칙을 참조하세요.

Namespace 규칙 (Namespace Rules) Enterprise

namespace 및 namespace_prefix 리소스는 Consul 네임스페이스에 대한 액세스를 제어합니다. 네임스페이스는 ACL 규칙이 적용되는 리소스 범위를 정의합니다. ACL 규칙 자체는 특정 네임스페이스에만 적용되도록 정의할 수 있습니다.

Consul 1.7.0 이상

많은 유형의 리소스를 별도의 네임스페이스에 추가하는 기능은 Consul Enterprise 1.7.0에 추가되었습니다.

다음 예시는 정책에서 네임스페이스 규칙을 정의하는 방법을 설명합니다.

예시 namespace 규칙

namespace_prefix "" {
  # grants permission to create and edit all namespaces
  policy = "write"

  # grant service:read for all services in all namespaces
  service_prefix "" {
    policy = "read"
  }

  # grant node:read for all nodes in all namespaces
  node_prefix "" {
    policy = "read"
  }
}

namespace "foo" {
  # grants permission to manage ACLs only for the foo namespace
  acl = "write"

  # grants permission to create and edit the foo namespace
  policy = "write"

  # grants write permissions to the KV for namespace foo
  key_prefix "" {
    policy = "write"
  }

  # grants write permissions for sessions for namespace foo
  session_prefix "" {
    policy = "write"
  }

  # grants service:write for all services in the foo namespace
  service_prefix "" {
    policy = "write"
  }

  # grants node:read for all nodes
  node_prefix "" {
    policy = "read"
  }
}

{
  "namespace_prefix": {
    "": {
      "policy": "write",
      "service_prefix": {
        "": {
          "policy": "read"
        }
      },
      "node_prefix": {
        "": {
          "policy": "read"
        }
      }
    }
  },
  "namespace": {
    "foo": {
      "acl": "write",
      "policy": "write",
      "key_prefix": {
        "": {
          "policy": "write"
        }
      },
      "session_prefix": {
        "": {
          "policy": "write"
        }
      },
      "service_prefix": {
        "": {
          "policy": "write"
        }
      },
      "node_prefix": {
        "": {
          "policy": "read"
        }
      }
    }
  }
}

제한 사항 (Restrictions)

사용자가 만든 네임스페이스에 규칙이 정의될 때 다음 제한 사항이 적용됩니다.

operator 규칙은 허용되지 않습니다.
event 규칙은 허용되지 않습니다.
keyring 규칙은 허용되지 않습니다.
query 규칙은 허용되지 않습니다.
쓰기 권한을 부여하려는 node 규칙은 허용되지 않습니다.

이러한 제한 사항은 Consul이 만든 기본 네임스페이스에는 적용되지 않습니다. 일반적으로 위의 모든 것은 운영자만 가져야 하는 권한이므로 이러한 권한을 부여하는 것은 기본 네임스페이스 안에서만 수행할 수 있습니다.

암시적 네임스페이스 지정 (Implicit Namespacing)

네임스페이스 안에서 생성된 규칙과 정책은 네임스페이스 구성을 상속합니다.

이는 규칙과 정책이 암시적으로 네임스페이스가 지정되며 추가 구성이 필요하지 않다는 것을 의미합니다.

위에서 설명한 제한 사항이 이러한 규칙과 정책에 적용됩니다. 또한 특정 네임스페이스 안의 규칙과 정책은 다른 네임스페이스의 리소스에 액세스하지 못합니다.

Node 규칙 (Node Rules)

node 및 node_prefix 리소스는 다음 API 동작에 대한 액세스를 제어합니다.

Catalog API에 대한 노드 수준 등록 및 읽기 액세스
Health API를 사용한 서비스 디스커버리
클러스터 멤버 목록 가져오기 같은 Agent API 작업에서 결과 필터링

리소스 라벨을 사용해 규칙을 특정 리소스 또는 리소스 세트로 범위를 지정할 수 있습니다.

다음 예시 규칙은 모든 노드에 대한 읽기 전용 액세스를 제공하는 빈 접두사 라벨을 사용합니다.

또한 규칙은 app 노드에 대한 읽기-쓰기 액세스를 제공하고 admin 노드에 대한 모든 액세스를 거부합니다.

예시 node 규칙

node_prefix "" {
  policy = "read"
}
node "app" {
  policy = "write"
}
node "admin" {
  policy = "deny"
}

{
  "node_prefix": {
    "": {
      "policy": "read"
    }
  },
  "node": {
    "app": {
      "policy": "write"
    },
    "admin": {
      "policy": "deny"
    }
  }
}

노드 정보 등록 및 쿼리 (Registering and Querying Node Information)

에이전트는 자체 노드 이름에 대한 쓰기 권한으로 구성되어야 에이전트가 카탈로그에 노드 메타데이터, 태그 주소 및 기타 정보를 등록할 수 있습니다.

잘못 구성하면 에이전트가 상태를 카탈로그와 동기화하려고 할 때 콘솔에 오류를 출력합니다.

acl.tokens.agent 매개변수에 쓰기 액세스를 구성하세요.

에이전트가 사용하는 acl.token.default는 DNS 인터페이스를 쿼리할 수 있도록 주어진 노드에 대한 읽기 액세스 권한을 가져야 합니다.

Node 규칙은 카탈로그에서 읽거나 건강 엔드포인트에서 정보를 검색할 때 쿼리 결과를 필터링하는 데 사용됩니다. 이를 통해 토큰이 주어진 서비스 이름에 액세스할 수 있지만 허용된 노드 이름의 하위 집합에서만 가능한 구성을 만들 수 있습니다.

Consul 에이전트는 건강 검사가 등록될 때와 Consul이 주기적 안티 엔트로피 동기화를 수행할 때 토큰을 로컬에서 확인합니다.

이러한 작업은 완료하기 위해 ACL 토큰이 필요할 수 있습니다. 등록 이벤트에 대한 ACL 토큰을 구성하려면 다음 방법을 사용하세요.

acl.tokens.default 매개변수에 전역 토큰을 구성합니다. 이렇게 하면 모든 검사 등록 작업 중에 단일 토큰을 사용할 수 있습니다.
등록 시점에 서비스 및 검사 정의와 함께 ACL 토큰을 제공합니다. 이는 더 큰 유연성을 제공하며 동일한 에이전트에서 여러 토큰을 사용할 수 있게 합니다.

예시는 services 및 checks 문서를 참조하세요. 또한 필요한 작업에 대해 토큰을 HTTP API에 전달할 수 있습니다.

가져온 노드 읽기 (Reading Imported Nodes)

노드 규칙은 클러스터 피어링 또는 admin 파티션(Enterprise 전용)에서 가져온 노드를 포함해 exported-services 구성 항목이 내보낸 서비스가 있는 노드에 대한 읽기 액세스에 영향을 줍니다.

다음 규칙 세트 중 하나가 토큰에 연결되어 있으면 모든 가져온 노드에 대한 읽기 액세스가 부여됩니다.

어떤 서비스에든 service:write가 부여됨
모든 노드에 node:read가 부여됨

Consul Enterprise의 경우 두 규칙 세트 모두 요청하는 서비스의 파티션과 최소 하나 이상의 네임스페이스에 범위가 지정되어야 합니다.

엔드포인트(예: /v1/health/service/:name)에 따라 Consul 데이터를 읽으려면 유사하게 범위가 지정된 Service 규칙이 필요할 수 있습니다.

이러한 권한은 서비스 ID(service identity)를 사용할 때 충족됩니다.

건강 엔드포인트를 사용해 가져온 서비스를 읽는 데 사용되는 예시 ACL 정책은 서비스 읽기를 참조하세요.

Operator 규칙 (Operator Rules)

operator 리소스는 Keyring API를 제외한 Operator API의 클러스터 수준 작업에 대한 액세스를 제어합니다.

규칙 세트당 하나의 operator 규칙만 허용됩니다. 다음 예시에서 토큰은 진단 목적으로 operator 엔드포인트를 쿼리하는 데 사용할 수 있지만 변경하지는 않습니다.

예시 operator 규칙

operator = "read"

{
  "operator": "read"
}

Peering 규칙 (Peering Rules)

peering 리소스는 클러스터 피어링 API의 클러스터 피어링에 대한 액세스를 제어합니다.

Consul Enterprise에서 peering 규칙은 admin 파티션에 범위가 지정됩니다. 따라서 admin 파티션 규칙에는 중첩될 수 있지만 네임스페이스 규칙에는 중첩될 수 없습니다.

다음 규칙은 읽기 및 쓰기 액세스를 부여합니다.

예시 peering 규칙

peering = "write"

{
  "peering": "write"
}

peering 리소스에 대한 규칙을 다른 규칙과 함께 적용하는 방법의 예시는 Admin 파티션 규칙의 예시 구성을 참조하세요.

Prepared Query 규칙 (Prepared Query Rules)

query 및 query_prefix 리소스는 Prepared Query API에서 prepared query를 생성, 업데이트, 삭제하기 위한 액세스를 제어합니다. query 규칙에서 리소스 라벨을 지정해 규칙의 범위를 결정합니다.

다음 예시의 리소스 라벨은 비어 있습니다. 결과적으로 규칙은 어떤 이름의 쿼리 리소스에 대한 읽기 전용 액세스를 허용합니다.

또한 규칙은 foo라는 쿼리에 대한 읽기-쓰기 액세스를 부여하여 ACL을 기반으로 쿼리 네임스페이스 제어를 위임할 수 있게 합니다.

예시 query 규칙

query_prefix "" {
  policy = "read"
}
query "foo" {
  policy = "write"
}

{
  "query_prefix": {
    "": {
      "policy": "read"
    }
  },
  "query": {
    "foo": {
      "policy": "write"
    }
  }
}

쿼리 실행은 node/node_prefix 및 service/service_prefix 정책의 적용을 받습니다.

prepared query와 함께 ACL을 사용할 때 몇 가지 변형이 있으며, 각각은 두 가지 방식 중 하나로 ACL을 사용합니다: 열림(개방형, 추측할 수 없는 ID로 보호) 또는 닫힘(ACL 정책으로 관리). 이러한 변형은 예시와 함께 여기에 설명되어 있습니다.

Name이 정의되지 않은 정적 쿼리는 어떤 ACL 정책으로도 제어되지 않습니다. 이러한 유형의 쿼리는 임시적이며 신뢰할 수 없는 클라이언트와 공유되지 않도록 설계되었으며, prepared query ID를 알 때만 접근할 수 있습니다. 이러한 ID는 ACL 토큰과 동일한 무작위 ID 체계로 생성되므로 추측하는 것이 불가능합니다. 모든 prepared query를 나열할 때 관리 토큰만 이러한 유형을 참조할 수 있지만, 클라이언트는 ID를 가진 인스턴스를 읽을 수 있습니다. 이 유형의 예시 사용은 시작 스크립트로 빌드되고 세션에 연결되어 프로세스가 DNS를 통해 사용하도록 구성 파일에 기록되는 쿼리입니다.
Name이 정의된 정적 쿼리는 query 및 query_prefix ACL 리소스로 제어됩니다. 클라이언트는 해당 쿼리 이름에 액세스할 수 있는 권한이 있는 ACL 토큰을 가져야 합니다. 클라이언트는 접두사에 따라 read 액세스가 있는 쿼리를 나열하거나 읽을 수 있으며, 마찬가지로 write 액세스가 있는 쿼리를 업데이트할 수 있습니다. 이 유형의 예시 사용은 데이터베이스에 대한 지리적 장애 조치(geo-failover) 동작을 제공하기 위해 많은 클라이언트가 사용하고 아는 잘 알려진 이름(예: prod-primary-customer-db)을 가진 쿼리입니다.
템플릿 쿼리는 Name이 정의된 정적 쿼리처럼 작동하지만, 빈 Name을 가진 catch-all 템플릿은 모든 쿼리 접두사에 쓸 수 있는 ACL 토큰을 요구합니다.

prepared query가 DNS 조회 또는 HTTP 요청을 통해 실행될 때 ACL 검사는 쿼리되는 서비스에 대해 실행되며, 이는 ACL이 다른 서비스 조회에서 작동하는 방식과 유사합니다. 이 검사를 위해 ACL 토큰이 선택되는 방법은 여러 가지입니다.

prepared query가 정의될 때 ACL 토큰이 캡처되었다면 서비스 조회를 수행하는 데 사용됩니다. 이렇게 하면 더 적은 ACL 토큰 또는 ACL 토큰이 없는 클라이언트도 쿼리를 실행할 수 있으므로 주의해서 사용해야 합니다.
ACL 토큰이 캡처되지 않았다면 클라이언트의 ACL 토큰이 서비스 조회를 수행하는 데 사용됩니다.
ACL 토큰이 캡처되지 않았고 클라이언트에 ACL 토큰이 없다면 익명 토큰이 서비스 조회를 수행하는 데 사용됩니다.

일반적인 경우 호출자의 ACL 토큰을 사용해 서비스를 조회할 수 있는지 테스트합니다. prepared query를 만들 때 토큰이 지정되었다면 동작이 바뀌어 이제 서비스 조회 시 쿼리 정의자가 설정한 캡처된 ACL 토큰이 사용됩니다.

ACL 토큰 캡처는 함수에 설정할 수 있는 PostgreSQL의 SECURITY DEFINER 속성과 유사하며, 클라이언트의 ACL 토큰 사용은 상보적인 SECURITY INVOKER 속성과 유사합니다.

Prepared query는 원래 Consul 0.6.0에서 도입되었습니다. ACL 동작은 0.6.3까지 변경되지 않았지만, 0.6.3 이후 버전에는 prepared query 네임스페이스 관리를 개선하는 변경 사항이 포함되어 있습니다.

이러한 차이는 아래 표에 요약되어 있습니다.

작업	버전 <= 0.6.3	버전 > 0.6.3
Name 없이 정적 쿼리 생성	prepared query를 만드는 데 사용된 ACL 토큰을 확인해 쿼리되는 서비스에 액세스할 수 있는지 검사합니다. 이 토큰은 prepared query를 실행할 때 사용할 토큰으로 캡처됩니다.	`Name`이 정의되지 않는 한 ACL 정책이 사용되지 않습니다. 클라이언트가 쿼리를 만들 때 명시적으로 제공하지 않는 한 기본적으로 토큰이 캡처되지 않습니다.
Name과 함께 정적 쿼리 생성	prepared query를 만드는 데 사용된 ACL 토큰을 확인해 쿼리되는 서비스에 액세스할 수 있는지 검사합니다. 이 토큰은 prepared query를 실행할 때 사용할 토큰으로 캡처됩니다.	클라이언트 토큰의 query ACL 정책을 사용해 클라이언트가 주어진 `Name`에 대해 쿼리를 등록할 수 있는지 결정합니다. 클라이언트가 쿼리를 만들 때 명시적으로 제공하지 않는 한 기본적으로 토큰이 캡처되지 않습니다.
Name 없이 정적 쿼리 관리	쿼리를 만드는 데 사용된 ACL 토큰 또는 관리 권한이 있는 토큰을 제공해야 이러한 작업을 수행할 수 있습니다.	쿼리 ID가 있는 모든 클라이언트가 이러한 작업을 수행할 수 있습니다.
Name과 함께 정적 쿼리 관리	쿼리를 만드는 데 사용된 ACL 토큰 또는 관리 권한이 있는 토큰을 제공해야 이러한 작업을 수행할 수 있습니다.	생성과 유사하게, 클라이언트 토큰의 query ACL 정책을 사용해 이러한 작업이 허용되는지 결정합니다.
쿼리 나열	쿼리를 나열하려면 관리 권한이 있는 토큰이 필요합니다.	클라이언트 토큰의 query ACL 정책을 사용해 참조할 수 있는 쿼리를 결정합니다. 관리 권한이 있는 토큰만 Name이 없는 prepared query를 참조할 수 있습니다.
쿼리 실행	쿼리를 만들 때 토큰이 항상 캡처되므로 이를 사용해 쿼리되는 서비스에 대한 액세스를 확인합니다. 클라이언트가 제공한 모든 토큰은 무시됩니다.	위에서 설명한 대로 캡처된 토큰, 클라이언트의 토큰 또는 익명 토큰을 사용해 결과를 필터링합니다.

Service 규칙 (Service Rules)

service 및 service_prefix 리소스는 Catalog API에 대한 서비스 수준 등록 및 읽기 액세스와 Health API를 사용한 서비스 디스커버리를 제어합니다.

service 규칙에서 리소스 라벨을 지정해 규칙의 범위를 설정합니다.

다음 예시의 리소스 라벨은 비어 있습니다. 결과적으로 규칙은 빈 접두사를 가진 모든 서비스 이름에 대한 읽기 전용 액세스를 허용합니다.

또한 규칙은 app 서비스에 대한 읽기-쓰기 액세스를 허용하고 admin 서비스에 대한 모든 액세스를 거부합니다.

예시 service 규칙

service_prefix "" {
  policy = "read"
}
service "app" {
  policy = "write"
}
service "admin" {
  policy = "deny"
}

{
  "service_prefix": {
    "": {
      "policy": "read"
    }
  },
  "service": {
    "app": {
      "policy": "write"
    },
    "admin": {
      "policy": "deny"
    }
  }
}

Consul의 DNS 인터페이스는 service 규칙의 제한 사항에 영향을 받습니다. 에이전트가 사용하는 acl.tokens.default가 주어진 서비스에 대한 읽기 액세스 권한이 없다면 DNS 인터페이스는 쿼리할 때 해당 서비스에 대한 레코드를 반환하지 않습니다.

카탈로그에서 읽거나 건강 엔드포인트에서 정보를 검색할 때 service 규칙은 쿼리 결과를 필터링하는 데 사용됩니다.

Service 규칙은 Agent API를 사용해 서비스 또는 검사를 등록할 때도 적용됩니다. 에이전트는 서비스 또는 검사가 등록될 때 토큰을 로컬에서 확인하며, Consul은 완료하려면 ACL 토큰이 필요할 수 있는 주기적 안티 엔트로피 동기화도 수행합니다. 이를 수용하기 위해 Consul은 등록 이벤트에 사용할 ACL 토큰을 구성하는 두 가지 방법을 제공합니다.

acl.tokens.default 구성 지시어를 사용합니다. 이렇게 하면 단일 토큰을 전역적으로 구성하고 모든 서비스 및 검사 등록 작업 중에 사용할 수 있습니다.
등록 시점에 서비스 및 검사 정의와 함께 ACL 토큰을 제공합니다. 이는 더 큰 유연성을 제공하며 동일한 에이전트에서 여러 토큰을 사용할 수 있게 합니다. 이에 대한 예시는 services와 checks에서 확인할 수 있습니다. 또한 필요한 작업에 대해 토큰을 HTTP API에 전달할 수 있습니다. 에이전트에 전달된 모든 토큰은 다시 시작 후 복구할 수 있도록 로컬 디스크에 저장됩니다. 액세스 보호에 대한 정보는 -data-dir 플래그 문서를 참조하세요.

ACL 외에도 Consul 0.9.0 이상에서 스크립트 검사를 활성화하려면 에이전트가 enable_script_checks 또는 enable_local_script_checks를 true로 구성해야 합니다.

가져온 서비스 읽기 (Reading Imported Services)

Service 규칙은 클러스터 피어링 또는 admin 파티션(Enterprise 전용) 사이에서 내보낸 서비스를 포함해 exported-services 구성 항목이 내보낸 서비스에 대한 읽기 액세스에 영향을 줍니다.

다음 규칙 세트 중 하나가 토큰에 연결되어 있으면 모든 가져온 서비스에 대한 읽기 액세스가 부여됩니다.

어떤 서비스에든 service:write가 부여됨
모든 서비스에 service:read가 부여됨

Consul Enterprise의 경우 두 규칙 세트 모두 요청하는 서비스의 파티션과 최소 하나 이상의 네임스페이스에 범위가 지정되어야 합니다.

엔드포인트(예: /v1/health/service/:name)에 따라 Consul 데이터를 읽으려면 유사하게 범위가 지정된 Node 규칙이 필요할 수 있습니다.

이러한 권한은 서비스 ID(service identity)를 사용할 때 충족됩니다.

건강 엔드포인트를 사용해 가져온 서비스를 읽는 데 사용되는 예시 ACL 정책은 서비스 읽기를 참조하세요.

인텐션 (Intentions)

Service 규칙은 인텐션에 대한 읽기 또는 쓰기 액세스를 부여하는 데도 사용됩니다. 다음 정책은 app 서비스에 대한 읽기-쓰기 액세스를 제공하고 app 서비스와 연관된 인텐션을 볼 수 있는 intentions:read 액세스를 명시적으로 부여합니다.

인텐션을 사용한 예시 service 규칙

service "app" {
  policy = "write"
  intentions = "read"
}

{
  "service": {
    "app": {
      "policy": "write",
      "intentions": "read"
    }
  }
}

service 규칙으로 인텐션 액세스를 관리하는 방법에 대한 자세한 내용은 인텐션에 대한 ACL 요구 사항을 참조하세요.

Session 규칙 (Session Rules)

session 및 session_prefix 리소스는 Session API 작업에 대한 액세스를 제어합니다.

session 규칙에서 리소스 라벨을 지정해 규칙의 범위를 설정합니다.

다음 예시의 리소스 라벨은 비어 있습니다. 결과적으로 규칙은 모든 세션에 대한 읽기 전용 액세스를 허용합니다.

또한 규칙은 app이라는 노드에서 세션을 만들 수 있게 하고 admin 노드의 모든 세션에 대한 모든 액세스를 거부합니다.

예시 session 규칙

session_prefix "" {
  policy = "read"
}
session "app" {
  policy = "write"
}
session "admin" {
  policy = "deny"
}

{
  "session_prefix": {
    "": {
      "policy": "read"
    }
  },
  "session": {
    "app": {
      "policy": "write"
    },
    "admin": {
      "policy": "deny"
    }
  }
}

ACL 규칙 구성 참조