ACL 규칙

ACL 규칙 (ACL Rules)

Consul ACL 정책에서 사용할 수 있는 모든 규칙을 설명하는 문서예요. acl, partition, agent, event, key/value, keyring, mesh, namespace, node, operator, peering, query, service, session 리소스에 대한 규칙을 다뤄요.

출처: 문서

본문

ACL 리소스 규칙 (ACL Resource Rules)

acl 리소스는 ACL API의 ACL 작업에 대한 접근을 제어합니다. 정책당 하나의 acl 규칙만 허용됩니다. 값은 정책 처분 중 하나로 설정됩니다.

acl = "write" 규칙은 스냅샷을 만드는 데도 필요합니다. 모든 토큰 시크릿이 스냅샷에 포함되기 때문입니다.

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

다음 예시에서 acl 규칙은 ACL API에 대한 write 접근으로 구성됩니다. 이 규칙은 운영자가 ACL을 읽거나 쓰고 어떤 토큰의 시크릿 ID도 발견할 수 있게 합니다.

acl = "write"

{
  "acl": "write"
}

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

partition 및 partition_prefix 리소스는 하나 이상의 admin 파티션에 대한 접근을 제어합니다. admin 파티션 내에 여러 네임스페이스 규칙을 포함할 수 있습니다.

다음 예시에서 정책은 example 파티션의 ex-namespace 네임스페이스와 exns-로 시작하는 네임스페이스에 write 접근을 부여합니다. mesh와 peering 리소스도 admin 파티션 규칙에 범위가 지정되어 example 파티션의 mesh 및 peering 리소스에 대한 write 접근을 부여합니다.

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

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 Rules)

agent 및 agent_prefix 리소스는 join과 leave 같은 Agent API의 유틸리티 작업에 대한 접근을 제어합니다. 카탈로그 관련 작업은 모두 node 또는 node_prefix 및 service 또는 service_prefix 정책에 포함됩니다.

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

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

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

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

이벤트 규칙 (Event Rules)

event 및 event_prefix 리소스는 이벤트 발생 및 목록 조회 같은 Event API 작업에 대한 접근을 제어합니다.

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

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

이벤트 규칙은 적용되는 이벤트 이름으로 라벨이 지정됩니다. 위 예시에서 규칙은 모든 이벤트에 대한 읽기 전용 접근과 "deploy" 이벤트 발생을 허용합니다.

consul exec 명령은 작업 중에 "_rexec" 접두사의 이벤트를 사용하므로, ACL이 활성화된 Consul 환경에서 이 기능을 활성화하려면 disable_remote_exec를 false로 구성하는 것 외에도 이 이벤트 접두사에 접근할 수 있는 토큰을 에이전트에 제공해야 합니다.

ID 규칙 (Identity Rules)

ID 규칙에서 리소스 라벨을 지정해 규칙의 범위를 설정합니다. 다음 예시의 리소스 라벨은 비어 있습니다. 결과적으로 규칙은 빈 접두사의 모든 워크로드 ID 이름에 대한 읽기 전용 접근을 허용합니다. 규칙은 app ID에 대한 읽기-쓰기 접근을 허용하고 admin ID에 대한 모든 접근을 거부합니다:

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_prefix "" {
  policy = "read"
}
key "foo" {
  policy = "write"
}
key "bar" {
  policy = "deny"
}

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

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

키 목록 정책 (List Policy for Keys)

acl.enable_key_list_policy 매개변수를 true로 설정해 list 정책 처분(Consul 1.0+)을 활성화합니다. 이 처분은 key 항목에 대한 재귀적 접근을 제공합니다. 추가 정보는 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" 접두사에 대한 재귀 읽기만 허용합니다.

접두사에 대한 write 접근이 있는 토큰은 list 접근도 가집니다. 접두사에 대한 list 접근이 있는 토큰은 모든 접미사에 대한 read 접근도 가집니다.

Sentinel 통합 (Sentinel Integration) 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 Rules)

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

keyring = "write"

{
  "keyring": "write"
}

메시 규칙 (Mesh Rules)

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

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

다음 규칙은 읽기 및 쓰기 접근을 부여합니다:

mesh = "write"

{
  "mesh": "write"
}

네임스페이스 규칙 (Namespace Rules) Enterprise

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

참고 Consul 1.7.0 이상

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

다음 예시는 정책에서 네임스페이스 규칙이 어떻게 정의될 수 있는지 설명합니다:

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 규칙 중 write 권한을 부여하려는 규칙은 허용되지 않습니다.

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

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

네임스페이스 내에서 만든 규칙과 정책은 네임스페이스 구성을 상속합니다. 즉, 규칙과 정책이 암시적으로 네임스페이스가 지정되며 추가 구성이 필요하지 않습니다. 위에 설명된 제한이 이러한 규칙과 정책에 적용됩니다. 또한 특정 네임스페이스 내의 규칙과 정책은 다른 네임스페이스의 리소스에 접근할 수 없습니다.

노드 규칙 (Node Rules)

node 및 node_prefix 리소스는 다음 API 동작에 대한 접근을 제어합니다:

Catalog API에 대한 노드 수준 등록 및 읽기 접근
Health API를 사용한 서비스 발견
클러스터 멤버 목록 가져오기 같은 Agent API 작업의 결과 필터링

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

다음 예시 규칙은 빈 접두사 라벨을 사용해 모든 노드에 대한 읽기 전용 접근을 제공합니다. 규칙은 app 노드에 대한 읽기-쓰기 접근도 제공하고 admin 노드에 대한 모든 접근을 거부합니다:

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)

에이전트가 자체 노드 메타데이터, 태그된 주소 및 기타 정보를 카탈로그에 등록할 수 있도록 에이전트는 자체 노드 이름에 대한 write 권한으로 구성되어야 합니다. 잘못 구성하면 에이전트가 상태를 카탈로그와 동기화하려고 할 때 콘솔에 오류를 출력합니다. acl.tokens.agent 매개변수에 write 접근을 구성하세요.

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

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

Consul 에이전트는 헬스 검사가 등록될 때와 Consul이 주기적인 안티 엔트로피 동기화를 수행할 때 토큰을 로컬로 확인합니다. 이러한 작업은 완료하는 데 ACL 토큰이 필요할 수 있습니다. 등록 이벤트에 대한 ACL 토큰을 구성하려면 다음 방법을 사용하세요:

acl.tokens.default 매개변수에 전역 토큰을 구성합니다. 이렇게 하면 모든 검사 등록 작업 중에 단일 토큰을 사용할 수 있습니다.
등록 시 service 및 check 정의와 함께 ACL 토큰을 제공합니다. 이렇게 하면 더 큰 유연성이 제공되고 같은 에이전트에서 여러 토큰을 사용할 수 있습니다. 예시는 services 및 checks 문서를 참조하세요. 또한 필요로 하는 작업에 대해 토큰을 HTTP API에 전달할 수 있습니다.

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

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

다음 규칙 세트 중 하나가 토큰에 연결되면 모든 가져온 노드에 대한 읽기 접근이 부여됩니다:

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

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

엔드포인트(예: /v1/health/service/:name)에 따라 Consul 데이터를 읽으려면 비슷하게 범위 지정된 Service Rules가 필요할 수 있습니다. 이러한 권한은 서비스 ID를 사용할 때 충족됩니다.

헬스 엔드포인트로 가져온 서비스를 읽는 데 사용되는 예시 ACL 정책은 Reading Services를 참조하세요.

운영자 규칙 (Operator Rules)

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

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

operator = "read"

{
  "operator": "read"
}

피어링 규칙 (Peering Rules)

peering 리소스는 Cluster Peering API의 클러스터 피어링에 대한 접근을 제어합니다.

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

다음 규칙은 읽기 및 쓰기 접근을 부여합니다:

peering = "write"

{
  "peering": "write"
}

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

Prepared Query 규칙 (Prepared Query Rules)

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

다음 예시의 리소스 라벨은 비어 있습니다. 결과적으로 규칙은 어떤 이름의 쿼리 리소스에 대한 읽기 전용 접근을 허용합니다. 규칙은 또한 foo라는 이름의 쿼리에 대한 읽기-쓰기 접근을 부여하여 ACL을 기반으로 쿼리 네임스페이스 제어를 위임할 수 있게 합니다:

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를 나열할 때는 관리(management) 토큰만 이러한 유형을 참조할 수 있지만, 클라이언트는 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 토큰이 서비스 조회 능력을 테스트하는 데 사용됩니다. prepared query가 생성될 때 Token이 지정되었으면 동작이 바뀌어 쿼리의 정의자가 설정한 캡처된 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 실행 시 사용할 `Token`으로 캡처됩니다.	`Name`이 정의되지 않으면 ACL 정책이 사용되지 않습니다. 클라이언트가 생성 시 명시적으로 제공하지 않으면 기본적으로 `Token`이 캡처되지 않습니다.
`Name`으로 정적 쿼리 생성	prepared query를 만드는 데 사용된 ACL 토큰이 쿼리되는 서비스에 접근할 수 있는지 확인됩니다. 이 토큰은 실행 시 사용할 `Token`으로 캡처됩니다.	클라이언트 토큰의 `query` ACL 정책을 사용해 클라이언트가 주어진 `Name`에 대한 쿼리를 등록할 수 있는지 결정합니다.
`Name` 없이 정적 쿼리 관리	이러한 작업을 수행하려면 쿼리를 만든 ACL 토큰 또는 관리 권한이 있는 토큰을 제공해야 합니다.	쿼리 ID가 있는 모든 클라이언트가 이러한 작업을 수행할 수 있습니다.
`Name`으로 정적 쿼리 관리	이러한 작업을 수행하려면 쿼리를 만든 ACL 토큰 또는 관리 권한이 있는 토큰을 제공해야 합니다.	생성과 유사하게 클라이언트 토큰의 `query` ACL 정책을 사용해 이러한 작업이 허용되는지 결정합니다.
쿼리 목록	어떤 쿼리를 나열하려면 관리 권한이 있는 토큰이 필요합니다.	클라이언트 토큰의 `query` ACL 정책을 사용해 참조할 수 있는 쿼리를 결정합니다. 관리 권한이 있는 토큰만 `Name`이 없는 prepared query를 참조할 수 있습니다.
쿼리 실행	쿼리가 생성될 때 `Token`이 항상 캡처되므로 캡처된 토큰으로 쿼리되는 서비스에 대한 접근을 확인합니다. 클라이언트가 제공한 토큰은 무시됩니다.	위에 설명된 대로 캡처된 토큰, 클라이언트의 토큰 또는 익명 토큰을 사용해 결과를 필터링합니다.

서비스 규칙 (Service Rules)

service 및 service_prefix 리소스는 Catalog API에 대한 서비스 수준 등록/읽기 접근과 Health API를 사용한 서비스 발견을 제어합니다. 서비스 규칙에서 리소스 라벨을 지정해 규칙의 범위를 설정합니다.

다음 예시의 리소스 라벨은 비어 있습니다. 결과적으로 규칙은 빈 접두사의 모든 서비스 이름에 대한 읽기 전용 접근을 허용합니다. 규칙은 app 서비스에 대한 읽기-쓰기 접근을 허용하고 admin 서비스에 대한 모든 접근을 거부합니다:

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 인터페이스는 서비스 규칙의 제한에 영향을 받습니다. 에이전트가 사용하는 acl.tokens.default가 주어진 서비스에 대한 read 접근이 없으면 DNS 인터페이스는 쿼리될 때 레코드를 반환하지 않습니다.

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

서비스 규칙은 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)

서비스 규칙은 exported-services 구성 항목으로 내보내진 서비스에 대한 읽기 접근에 영향을 줍니다. 여기에는 클러스터 피어링 또는 admin 파티션(Enterprise 전용) 간에 내보내진 서비스가 포함됩니다.

다음 규칙 세트 중 하나가 토큰에 연결되면 모든 가져온 서비스에 대한 읽기 접근이 부여됩니다:

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

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

엔드포인트(예: /v1/health/service/:name)에 따라 Consul 데이터를 읽으려면 비슷하게 범위 지정된 Node Rules가 필요할 수 있습니다. 이러한 권한은 서비스 ID를 사용할 때 충족됩니다.

헬스 엔드포인트로 가져온 서비스를 읽는 데 사용되는 예시 ACL 정책은 Reading Services를 참조하세요.

인텐션 (Intentions)

서비스 규칙은 인텐션에 대한 읽기 또는 쓰기 접근을 부여하는 데도 사용됩니다. 다음 정책은 "app" 서비스에 대한 읽기-쓰기 접근을 제공하고 "app" 서비스와 연결된 인텐션을 보기 위한 intentions:read 접근을 명시적으로 부여합니다.

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

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

서비스 규칙으로 인텐션 접근을 관리하는 방법에 대한 자세한 정보는 ACL requirements for intentions를 참조하세요.

세션 규칙 (Session Rules)

session 및 session_prefix 리소스는 Session API 작업에 대한 접근을 제어합니다. 세션 규칙에서 리소스 라벨을 지정해 규칙의 범위를 설정합니다.

다음 예시의 리소스 라벨은 비어 있습니다. 결과적으로 규칙은 모든 세션에 대한 읽기 전용 접근을 허용합니다. 규칙은 app이라는 이름의 노드에서 세션 생성도 허용하고 admin 노드의 모든 세션에 대한 모든 접근을 거부합니다:

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

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

ACL 규칙

ACL 규칙 (ACL Rules)

본문

ACL 리소스 규칙 (ACL Resource Rules)

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

에이전트 규칙 (Agent Rules)

이벤트 규칙 (Event Rules)

ID 규칙 (Identity Rules)

키/값 규칙 (Key/Value Rules)

키 목록 정책 (List Policy for Keys)

Sentinel 통합 (Sentinel Integration) Enterprise

키링 규칙 (Keyring Rules)

메시 규칙 (Mesh Rules)

네임스페이스 규칙 (Namespace Rules) Enterprise

제한 사항 (Restrictions)

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

노드 규칙 (Node Rules)

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

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

운영자 규칙 (Operator Rules)

피어링 규칙 (Peering Rules)

Prepared Query 규칙 (Prepared Query Rules)

서비스 규칙 (Service Rules)

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

인텐션 (Intentions)

세션 규칙 (Session Rules)

더 알아보기 (Learn more)