인증 구성하기
기본적으로 Backstage는 누구나 자격 증명 없이 로그인할 수 있게 하는 게스트 인증 프로바이더를 사용해요. 이것은 로컬 개발에는 편리하지만 프로덕션에 배포하면 보안 위험을 만들어요. 이 글에서는 실제 인증 프로바이더로 게스트 로그인을 교체하는 방법을 설명드릴게요.
출처: 문서
본문
대상 독자: 개발자 및 관리자
요약
기본적으로 Backstage는 누구나 자격 증명 없이 로그인할 수 있게 하는 게스트 인증 프로바이더를 사용해요. 이것은 로컬 개발에는 편리하지만 프로덕션에 배포하면 보안 위험을 만들어요. 배포하기 전에 실제 인증 프로바이더를 구성해야 해요.
이 페이지가 끝나면 무엇을 변경해야 하는지, 그리고 선택한 프로바이더의 설정 지침을 어디에서 찾을 수 있는지 이해하게 될 거예요.
게스트 인증을 왜 교체하나요?
게스트 프로바이더는 명시적으로 컨테이너화 또는 프로덕션 환경용이 아니에요. 게스트 인증이 활성화되면 Backstage 인스턴스에 접근할 수 있는 어떤 사용자든 같은 정체성을 공유하고 같은 수준의 접근 권한을 갖게 돼요. 이를 교체하는 것은 프로덕션에 들어가기 전 가장 중요한 단계 중 하나예요.
게스트 인증 프로바이더와 함께 Backstage를 배포하면 인스턴스가 무단 접근에 노출돼요. 배포하기 전에 실제 프로바이더를 구성하세요.
인증 프로바이더 선택하기
Backstage는 광범위한 인증 프로바이더를 지원해요. 대부분의 개발자가 이미 계정을 갖고 있으므로 GitHub가 일반적인 선택이지만, 조직이 싱글 사인온에 이미 사용하는 것을 선택해야 해요.
몇 가지 인기 있는 옵션:
| | 프로바이더 | 적합한 경우... | GitHub | 팀이 GitHub를 사용하고 빠른 설정을 원할 때. | Microsoft / Azure AD | 회사가 Microsoft Entra ID(Azure AD)를 사용할 때. | Google | 회사가 Google Workspace를 사용할 때. | Okta | Okta를 ID 프로바이더로 사용할 때. | OIDC | 일반 OpenID Connect 프로바이더가 있을 때. | OAuth2 Proxy | 인증을 수행하는 리버스 프록시를 이미 사용할 때.
전체 프로바이더 목록과 구성은 인증 문서에서 확인할 수 있어요.
설정에 포함되는 것
어떤 프로바이더를 선택하든 설정은 같은 패턴을 따르게 돼요:
-
ID 프로바이더로 OAuth 애플리케이션(또는 동등한 것)을 만들어요. 그러면 client ID와 client secret을 받게 돼요.
-
자격 증명과 함께 프로바이더 구성을
app-config.yaml에 추가해요. 일반적으로 시크릿에는 환경 변수를 사용해요. -
선택한 프로바이더의 백엔드 인증 모듈을
packages/backend에 설치해요. -
인증된 사용자 정체성을 Backstage 카탈로그 사용자 엔티티에 매핑하는 로그인 리졸버(sign-in resolver)를 구성해요.
-
올바른 로그인 페이지가 표시되도록 프론트엔드를 업데이트해요.
인증 시작하기 가이드에서 GitHub를 예시 프로바이더로 사용해서 이 과정을 단계별로 안내해요.
프로덕션 구성
인증이 구성되면 프로덕션 구성에서 게스트 프로바이더가 비활성화되었는지 확인해요:
app-config.production.yaml
auth: providers: guest: null
이렇게 하면 로컬 개발을 위해 기본 app-config.yaml에 게스트 프로바이더가 구성되어 있더라도, 프로덕션에서 명시적으로 비활성화되도록 보장해요.
다음 단계
데이터베이스와 인증이 모두 구성되었으니, 이제 배포할 준비가 되었어요.
- 프로덕션에 배포하기