Secrets Manager 코드를 작성하거나 변경 사항을 리뷰할 때 이 지침을 사용합니다. Secrets Manager에는 동시에 참일 수 있는 여러 종류의 상태가 있으며, 각 상태 변경에는 필수 부수 효과가 따릅니다. 변경 사항이 그 자체로는 올바르게 보여도 다른 상태가 참일 때 오동작할 수 있습니다. 상태가 결합되는 방식은 Secrets Manager 상태와 부수 효과를 참고합니다.

문서를 최신 상태로 유지#

doc/development/secrets_manager/ 아래의 페이지는 코드가 현재 작동하는 방식을 설명합니다. 리뷰어가 이 페이지를 참고하며, Secrets Manager 원칙을 사용하는 자동 리뷰어도 마찬가지입니다.

• 변경 사항이 어떤 페이지에서 설명하는 동작을 바꾼다면, 같은 머지 리퀘스트에서 그 페이지를 업데이트합니다.
• 이미 오래된 페이지를 발견하면 같은 머지 리퀘스트에서 또는 후속 작업으로 수정합니다.

영역별 페이지#

변경 사항이 건드리는 파일에 따라 다음 페이지에 더 자세한 내용이 있습니다.

변경 사항 체크리스트#

각 변경 사항에 대해 다음 질문에 답합니다.

1. 정리(cleanup) 코드가 실시간 프로젝트나 그룹을 읽습니까? 부모가 이미 없어졌을 수 있으므로 Secrets Manager 행이나 작업에 저장된 ID를 사용합니다.
2. 새 쓰기 경로가 엔터티별 리스를 획득하며, 획득하지 못하면 진행하지 않고 즉시 실패합니까?
3. 변경 사항이 프로젝트 쪽을 고치는 것이라면 그룹 쪽에도 같은 수정이 필요합니까, 또는 그 반대입니까? 먼저 프로젝트와 그룹의 차이를 확인합니다.
4. 생성, 읽기, 업데이트, 삭제(CRUD) 작업이 active 상태가 아닌 Secrets Manager(프로비저닝 해제 작업이 대기 중인 것 포함)를 여전히 거부합니까?
5. 고유 작업 인덱스 때문에 새 작업 삽입이 아무 일도 하지 않을 수 있습니까? 프로젝트 또는 그룹당 작업은 한 번에 하나만 존재할 수 있습니다.
6. 대량 작업이 같은 엔터티에 대한 레코드별 작업과 경합할 수 있습니까? 워커가 실제로 삽입된 행에 대해서만 실행되는지 확인합니다.
7. 아직 프로비저닝 중이라서 프로젝트나 그룹 이전이 건너뛰는 Secrets Manager를 변경 사항이 처리합니까?
8. 네임스페이스 해체(teardown) 변경이 상태 전환의 부수 효과에 나열된 두 가지 무해한 오류를 여전히 허용합니까?
9. 변경 사항이 일치하는 감사 이벤트 없이 감사 대상 작업을 추가합니까?
10. 변경 사항이 일치하는 OpenBao ACL이나 CEL 로직 없이 Rails 정책을 업데이트합니까, 또는 그 반대입니까? 자세한 내용은 두 가지 인가 계층을 참고합니다.
11. 변경 사항이 metadata_cas를 올바르게 사용합니까, 아니면 동시 업데이트를 덮어쓸 수 있습니까?
12. 새 쓰기 경로가 동급의 다른 경로와 같은 위치에서 자격을 확인합니까?
13. 새 코드가 concern, 정책 규칙, 활성 네임스페이스 확인, 기능 확인처럼 가장 가까운 기존 동급 코드와 같은 가드를 포함합니까? 동급 코드에는 있고 새 코드에는 없는 가드는, 변경 사항이 그 이유를 설명하지 않는 한 버그일 가능성이 높습니다.
14. 변경 사항이 프로비저닝이나 실행 중인 파이프라인 같은 다단계 작업 중에 자격이 동일하게 유지된다고 가정합니까?
15. 프로비저닝 해제 워커나 정리 크론이 자신을 차단할 수 있는 자격 확인을 호출합니까?
16. 변경 사항이 읽기와 삭제는 되지만 쓰기는 되지 않는 느슨한(loose) 읽기 전용을 엄격한(strict) 읽기 전용과 별도로 처리합니까?