CEL 정책의 결과 함수와 판정 함수

결과 함수는 승인, 거절 또는 검토 요건을 반환합니다. 판정 함수는 조건식에 사용할 불리언 값을 반환합니다. 정책의 모든 실행 경로는 결과 함수로 끝나야 합니다.

결과 함수

approve

approve("신뢰할 변경으로 분류되었습니다.")

approve(reason)는 해당 정책에서 검토자를 요구하지 않는 결과를 반환합니다. 사유 문자열은 감사 로그에 기록됩니다. 다른 활성 정책이 반환한 승인 요건은 계속 충족해야 합니다.

reject

reject("허용된 복제본 수를 초과했습니다.")

reject(reason)는 변경을 즉시 거절합니다. 거절된 변경은 편집하여 다시 제출하기 전까지 적용할 수 없습니다. 위 호출은 거절 결과의 형식이며, 복제본 수의 비교 조건은 제품의 실제 구성 필드에 맞추어 정책에 작성해야 합니다.

no_op

no_op()

no_op()는 해당 정책이 변경에 관여하지 않는다는 결과입니다. 이 결과는 제외되고 다른 활성 정책은 정상적으로 평가됩니다. 특정 변경 유형이나 개체 유형만 처리하는 정책의 나머지 분기에 사용합니다.

모든 활성 정책이 같은 변경에 no_op()를 반환하면 오류가 발생합니다. 자동 승인 결과로 사용할 수 없습니다.

require_role

require_role(rid, roleId, reason)는 지정한 리소스에서 특정 역할을 가진 사용자의 승인을 요구합니다.

다음은 개체 구성 변경에 운영자 승인을 요구하는 정책입니다.

type == "UPDATE_ENTITY"
  ? require_role(
      referencedResources.installation.rid,
      "entity:operator",
      "개체 구성을 변경하려면 운영자의 승인이 필요합니다."
    )
  : no_op()

require_operation

require_operation(rid, operation, reason)는 대상 리소스에 특정 작업 권한을 가진 사용자의 승인을 요구합니다. 역할 이름 대신 실제 작업 권한을 기준으로 승인자를 정할 때 사용합니다.

type == "UPDATE_ENTITY"
  ? require_operation(
      referencedResources.installation.rid,
      "entity:approve-config-update",
      "개체 구성 변경 승인 권한이 필요합니다."
    )
  : no_op()

작업에 따라 편집자, 승인자, 관리자 또는 운영자 역할에 필요한 권한이 포함될 수 있습니다. 정책에는 대상 리소스에서 사용하는 실제 작업 문자열을 지정합니다.

require_team

require_team(teamName, reason)는 이름으로 지정한 Apollo 팀의 검토를 요구합니다. 첫 번째 인수는 팀의 이름이고 두 번째 인수는 사유입니다.

가상의 보안 팀이 모든 개체 구성 변경을 검토하도록 요구하려면 다음과 같이 작성할 수 있습니다.

type == "UPDATE_ENTITY"
  ? require_team("platform-security", "보안 팀의 검토가 필요합니다.")
  : no_op()

require_any

require_any(requirements, reason)는 목록의 승인 요건 중 하나만 충족해도 만족하는 OR 조건입니다. 목록의 각 요소에는 require_role, require_operation, require_team 호출을 넣을 수 있습니다.

다음은 가상의 당직 팀 또는 해당 설치본의 운영자 중 한쪽이 승인할 수 있도록 하는 정책입니다.

type == "UPDATE_ENTITY"
  ? require_any([
      require_role(
        referencedResources.installation.rid,
        "entity:operator",
        "개체 운영자가 승인할 수 있습니다."
      ),
      require_team("platform-oncall", "당직 팀이 승인할 수 있습니다.")
    ], "개체 운영자 또는 당직 팀의 승인이 필요합니다.")
  : no_op()

이 OR 관계는 해당 함수에 전달한 요건 사이에 적용됩니다. 다른 정책의 요건과 결합할 때는 여전히 AND 관계를 사용합니다.

판정 함수

Apollo 서비스 계정의 자동 승인 대상 여부

should_auto_approve_service_user(type, author, onBehalfOf, editors)

다음 조건을 충족하면 참을 반환합니다.

• Apollo가 신뢰하는 자체 서비스 계정이 변경을 작성했습니다.
• 해당 서비스 계정에 허용된 자동 승인 변경 유형입니다.
• 요청을 연 뒤 다른 사용자가 편집하지 않았습니다.

함수는 신뢰하는 계정 목록과 계정별 변경 유형을 포함합니다. 기본 정책은 지원하는 변경 유형마다 이 판정을 사용하여 Apollo의 자동화 작업이 사람의 승인을 기다리지 않도록 합니다.

기본 정책에서 이 호출을 제거하거나 변경하면 자동 승인을 전제로 하는 Apollo 작업이 중단될 수 있습니다. 기존 정책에 분기를 추가할 때는 이 처리도 유지해야 합니다.

type == "UPDATE_ENTITY" ? (
  should_auto_approve_service_user(type, author, onBehalfOf, editors)
    ? approve("신뢰하는 Apollo 서비스 계정의 변경입니다.")
    : require_role(
        referencedResources.installation.rid,
        "entity:operator",
        "개체 운영자의 승인이 필요합니다."
      )
) : no_op()

특정 서비스 계정의 작성 여부

is_author_service_user(username, author, onBehalfOf, editors)

지정한 username이 author 또는 onBehalfOf 사용자와 일치하고, 그 사용자가 서비스 계정이며, 요청을 연 뒤 해당 사용자 외에는 편집하지 않았다면 참을 반환합니다.

조직이 지정한 서비스 계정에 자동 승인을 허용할 때 사용할 수 있습니다. Apollo 자체 서비스 계정의 승인 대상 여부는 앞의 should_auto_approve_service_user로 검사하는 것이 권장됩니다. 사용자 이름이 일치하는지만 직접 비교하면 서비스 계정 여부와 이후 편집자 조건을 검사하지 못합니다.

신뢰할 모듈 요청 여부

is_trusted_module_request(author, metadata, editors)

Apollo의 모듈 배포 서비스가 요청을 열었고, 모듈 설치 메타데이터가 있으며, 다른 사용자가 이후 편집하지 않았다면 참을 반환합니다.

이 함수는 모듈 요청의 생성 주체와 편집 여부를 확인합니다. 모듈 소유자가 선택한 승인 모드, 자동 업데이트 여부와 사용자 구성 보호까지 확인하려면 다음 함수를 사용해야 합니다.

자동 승인 가능한 모듈 업데이트 여부

is_trusted_module_update_eligible_for_auto_approval(author, metadata, editors, request)

자동으로 생성된 모듈 업데이트가 다음 조건을 모두 충족하면 참을 반환합니다.

1. Apollo가 요청을 열었고 다른 사용자가 편집하지 않았습니다.
2. 모듈 소유자가 자동 승인 모드를 선택했습니다.
3. 사용자의 새 설치나 수동 업데이트가 아니라 Apollo가 만든 자동 업데이트입니다.
4. 배포 개체 변경이라면 사용자가 작성한 기존 설정 재정의를 덮어쓰지 않습니다.

모듈의 업데이트 승인 모드를 따르려는 정책에서 사용합니다. 최종 승인 결과는 다른 활성 정책의 요건과 함께 결정됩니다.

신뢰할 환경 가져오기 요청 여부

is_trusted_import_request(author, metadata, editors)

Apollo가 환경 가져오기의 일부로 요청을 열었고 이후 다른 사용자가 편집하지 않았다면 참을 반환합니다. 환경 가져오기는 기준이 되는 환경에서 설정을 동기화하는 작업입니다.

모듈과 환경 가져오기 판정에는 입력의 metadata를 그대로 전달합니다. 내부 메타데이터 필드를 임의로 해석하는 조건으로 판정을 대체하지 않습니다.

변경 경로가 허용 패턴에 포함되는지 검사

diff_only_modifies_paths(diff, allowedPatterns)

diff의 모든 변경 경로가 allowedPatterns 가운데 하나 이상과 일치하면 참을 반환합니다. 하나라도 일치하지 않는 변경 경로가 있으면 거짓을 반환합니다.

경로는 /로 구분하며 글로브 패턴을 사용합니다.

다음은 환경 참조가 있는 요청에서 가상의 서비스 계정과 변경 경로를 함께 검사하는 정책입니다. 허용할 경로는 실제 변경 유형의 차이 구조에 맞추어 설정해야 합니다.

"environment" in referencedResources ? (
  is_author_service_user("svc-excavator", author, onBehalfOf, editors) &&
  diff_only_modifies_paths(
    diff,
    ["dependency-stack-overrides", "incrementalSettings/*"]
  )
    ? approve("허용된 경로만 변경하는 서비스 계정 요청입니다.")
    : require_role(
        referencedResources.environment.rid,
        "apollo-environments:operator",
        "환경 운영자의 승인이 필요합니다."
      )
) : no_op()

위 패턴 중 첫 번째는 최상위 키, 두 번째는 바로 아래 키에 적용됩니다. 실제 요청에서 만들어지는 차이 경로와 허용할 깊이에 맞추어 목록을 지정합니다. 더 깊은 하위 경로까지 허용하려면 그 범위를 명시적으로 패턴에 포함해야 합니다.