배포 접근 제어

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

이 배포에 누가 닿을 수 있는가 (docs/access.md §3.1). 정책을 한 번도 안 정한 프로젝트는 public 이고 404 가 아니다 — 대부분의 프로젝트가 그 상태다.

값은 없다. 비밀번호는 어느 표면에도 나가지 않고, 우회 시크릿은 만들 때 한 번만 보인다.

viewer 이상 — "이 배포가 열려 있는가" 는 조직의 누구나 알아야 하는 사실이다.

operationId getAccess

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

public 은 지금 동작 그대로, org 는 프로젝트가 속한 org 의 member 이상, password 는 프로젝트당 하나의 공유 비밀번호다 — 사용자별이 되는 순간 그것은 가입자 표이고 우리 칸이 아니다 (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 로 옮겨간다. 쿠키를 심는 것은 그 콜백을 받는 front 다 — 다른 오리진에서 심을 수 없다는 사실이 이 흐름 전체의 모양을 정했다.

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