배포 접근 제어

GET /v1/orgs/{orgSlug}/projects/{projectName}/access

이 배포에 접근할 수 있는 사람 (docs/access.md §3.1). 정책을 한 번도 설정한 적 없는 프로젝트는 404가 아니라 public입니다 — 대부분의 프로젝트가 이 상태입니다.

값이 없습니다. 비밀번호는 어떤 화면에도 노출되지 않으며, 우회 시크릿은 생성 시점에 단 한 번만 표시됩니다.

viewer 이상 — 이 배포가 공개되어 있는지는 org 내 누구나 알아야 하는 사실입니다.

operationId getAccess

PUT /v1/orgs/{orgSlug}/projects/{projectName}/access

public은 현재 동작을 유지하고, org는 프로젝트가 속한 org의 member 이상을 의미하며, password는 프로젝트당 하나의 공유 비밀번호를 의미합니다 — 사용자별로 바뀌는 순간 그것은 구독자 테이블의 문제이며 이 API의 범위를 벗어납니다 (docs/access.md §3.1).

비밀번호를 보내지 않으면 기존 값이 유지됩니다. 모드만 변경하는 저장이 비밀번호까지 지운다면, 다시 전환할 때 비밀번호를 새로 설정해야 하는데 이 불편함이 안전을 사주지는 못합니다. 지우고 싶다면 새 값을 보내세요.

admin 이상이 필요합니다. member가 경계를 바꿀 수 있다면 그것은 경계가 아닙니다. access.set으로 감사 기록됩니다 (비밀번호 자체는 감사 기록에 포함되지 않습니다).

operationId setAccess

요청 본문: application/json · object

POST /v1/orgs/{orgSlug}/projects/{projectName}/access/bypass

CI가 보호된 배포에 접근할 때 사용하는 키입니다 (docs/access.md §3.6). Runlot-Access-Bypass: <secret> 요청 헤더로 전송하세요.

값은 이 응답에서만 나타납니다. 다시 조회할 수 없으며, 이 호출을 다시 실행하면 기존 값이 즉시 무효화됩니다 — 유출된 시크릿을 폐기하는 유일한 방법입니다.

이 키가 없으면 CI가 보호된 배포에 접근할 수 없어 보호를 꺼야 할 수도 있습니다. admin 이상이 필요합니다. access.bypass.new 감사 이벤트는 키 값을 기록하지 않습니다.

operationId newAccessBypass

DELETE /v1/orgs/{orgSlug}/projects/{projectName}/access/bypass

우회 키가 없어도 204를 반환합니다. 접근 정책 자체는 변경되지 않습니다. 우회 키는 정책과 별개로 관리됩니다. admin 이상이 사용할 수 있습니다. access.bypass.revoke로 감사 기록됩니다.

operationId revokeAccessBypass

POST /v1/access/authorize

이것은 로그인 왕복의 중간에 위치합니다. 보호된 배포로 향하던 요청이 대시보드의 /access/authorize 화면으로 되돌아오면, 그 화면이 세션과 함께 이 호출을 실행하고 수신한 redirect로 이동합니다. 그 콜백을 받는 프런트엔드가 쿠키를 설정합니다 — 다른 origin에서는 쿠키를 설정할 수 없다는 사실이 이 흐름 전체를 형성했습니다.

to는 우리가 알고 있는 호스트네임이어야 합니다. 그렇지 않으면 404를 반환합니다: 이 검사가 없다면 이 엔드포인트는 세션을 가진 사용자를 임의의 도메인으로 보내는 오픈 리다이렉트가 되고, 그 도메인이 코드를 받게 됩니다. next도 경로만 허용합니다 (//evil.example은 절대 주소로 해석됩니다).

org 외부의 사용자는 403을 받습니다 — 다시 로그인해도 결과는 같습니다 (§3.7). 핵심은 member 이상이 아니라 viewer 이상이라는 점입니다: 배포를 보는 것은 정확히 viewer의 역할이기 때문입니다.

문서의 §3.4-2 절은 이 흐름을 브라우저의 GET /access/authorize로 설명합니다. 대시보드가 세션 토큰을 localStorage에 저장하기 때문에, 서버는 그 GET에서 세션을 볼 수 없습니다. 따라서 이동을 수행하는 주체만 서버에서 브라우저로 바뀌었을 뿐, 판정은 그대로입니다.

operationId authorizeAccess

요청 본문: application/json · object