Skip to content

Chore/#134 API 보안 설정 로직 개선 및 개발/배포 환경 분리 - #147

Open
kym8821 wants to merge 5 commits into
devfrom
chore/#134-environment-and-security-improvement
Open

Chore/#134 API 보안 설정 로직 개선 및 개발/배포 환경 분리#147
kym8821 wants to merge 5 commits into
devfrom
chore/#134-environment-and-security-improvement

Conversation

@kym8821

@kym8821 kym8821 commented Jul 26, 2026

Copy link
Copy Markdown
Contributor

PR 타입

  • Bugfix
  • Feature
  • Code style update
  • Refactoring
  • Other... Please describe:

작업 내용

  • application.yml의 swagger, 스토리지, JWT 토큰 설정을 application-prod.yml, application-dev.yml로 분리
  • application.yml에 permit-all/admin-only 경로 목록 추가
  • RequestMatcher 생성 시 권한별로 집계 및 생성하도록 개선

주의사항

  • 확인할 때 서브모듈의 dev/monolitic 브랜치에 있는 최신 application.yml, application-prod.yml, application-dev.yml 함께 확인하기

관련 이슈: #134

테스트 결과

1. 통합 테스트 결과

image

2. 수동 테스트 ( profile = dev일 때 swagger 접속 )

image

3. 수동 테스트 ( profile = prod일 때 swagger 접속 )

image

4. 수동 테스트 ( permit-all로 설정한 요청 경로 접근 테스트 ( 토큰 없을 때 ) )

image

PR 체크리스트

  • 커밋 메시지가 가이드라인을 따르는가
  • 테스트 코드를 모두 통과하였는가
  • 관련 이슈를 연결하였는가

kym8821 added 5 commits July 7, 2026 03:04
… into chore/#134-environment-and-security-improvement
…estMatcher 반영 로직 개선

- 권한별 RequestMatcher를 개별 집계하여 적용하도록 개선
- permit-all 및 admin-only 설정 추가
- HTTP 메서드별 허용/관리자 전용 요청 경로를 application.yml에서 관리하도록 변경
Fixes: #134
- 동일한 의미의 테스트 제거 및 테스트 시 실제 요청 경로를 사용하도록 개선
Fixes: #134
@kym8821 kym8821 self-assigned this Jul 26, 2026
@kym8821 kym8821 added documentation Improvements or additions to documentation enhancement New feature or request labels Jul 26, 2026
@gemini-code-assist

Copy link
Copy Markdown
Contributor

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

@kym8821 kym8821 linked an issue Jul 26, 2026 that may be closed by this pull request
3 tasks
Comment thread build.gradle
tasks.register('copyConfig', Copy) {
from("${rootProject.projectDir}/backend_config/dev/monolithic") {
include 'application.yml'
include 'application-prod.yml'

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

spring boot 에서는 application.yml -> application-prod.yml 순으로 적용됩니다. 그러나 application-prod.yml 에는 ddl-auto 설정이 명시되어있지 않아 application.yml 의 ddl-auto: create-drop 이 적용될 것으로 예상됩니다. 따라서 prod에는 validate 또는 none을 명시해야 합니다.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

확인 감사합니다. 말씀하신대로 DB 관련 설정은 prod/dev 환경에서 분리해서 관리하는 것이 좋아보입니다

Comment thread build.gradle
from("${rootProject.projectDir}/backend_config/dev/monolithic") {
include 'application.yml'
include 'application-prod.yml'
include 'application-dev.yml'

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

추가로 운영 환경에서 dev profile의 비활성화가 보장되는 지 궁금합니다. application.yml에는 active: dev, auth 가 활성화 되어 있어서 별도 처리가 없다면

https://github.com/kakao-theme-maker/backend/blob/b7db4ac8c938f90f13eefac1ecd3092d71dfcb84/src/main/java/com/komentum/user/controller/DevAuthController.java#L18-L37

DevAuthController의 POST /dev/users/auth가 permitAll 상태로 활성화되어 인증없이 ADMIN 토큰을 발급받을 수 있어 보입니다.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

확인 감사합니다.

해당 부분이 수동 테스트 과정에서 확인되지 않은 이유는 IntelliJ Run Configuration에서 설정한 profile이 application.yml의 spring.profiles.active보다 우선 적용되기 때문입니다.

profile은 application.yml에 고정하기보다 JAR 실행 시 외부에서 전달하는 방식을 고려하고 PR을 구성했습니다. 동일한 Docker 이미지를 사용하면서 실행 환경에 따라 dev/prod 등 필요한 profile을 지정하여 환경별 설정을 분리하기 위함입니다.

따라서 현재 application.yml에 설정된 profile 관련 부분은 제거하도록 하겠습니다.

@klaqwe1

klaqwe1 commented Aug 9, 2026

Copy link
Copy Markdown
Contributor

Swagger는 application-prod.yml에서 비활성화하고 application-dev.yml에서 활성화하여 환경별로 분리한 것으로 이해했습니다. 다만 Swagger 관련 permit-all 경로는 공통 application.yml에 남아 있습니다. Swagger 자체가 비활성화되면 실제 엔드포인트는 노출되지 않겠지만, 환경 분리 관점에서 이 규칙 역시 dev 설정으로 분리하지 않은 이유가 궁금합니다.

@kym8821

kym8821 commented Aug 11, 2026

Copy link
Copy Markdown
Contributor Author

1. 사용할 수 있는 대안
profile에 따라 경로를 분리하는 것 자체는 가능합니다. 예를 들어 profile별로 서로 다른 SecurityFilterChain Bean을 구성할 수 있습니다.

다만 이 방식은 공통으로 사용되는 Security 설정이 중복되는 문제가 있고, 현재 개발/운영 환경에서는 Swagger 관련 경로를 제외하면 API 접근 정책을 동일하게 사용하고 있습니다.

혹은 개발/운영 환경에서 독립적으로 관리되어야 하는 API 접근 정책만 별도로 구성하고, 나머지는 공통 SecurityFilterChain에서 관리하는 방식도 가능합니다. 이 경우 기존 구조를 크게 변경하지 않으면서 환경별 정책을 분리할 수 있습니다.

2. 현재 방식을 채택한 이유

이전에 말씀드린 것처럼 Swagger UI와 관련 endpoint는 dev 환경에서만 활성화되며, Swagger 관련 Bean 역시 dev profile에서만 생성되고 있습니다.

따라서 prod 환경에서 Swagger endpoint가 실제로 노출되지 않는 현재 구조에서는 SecurityFilterChain의 Swagger 경로에 대한 접근 정책까지 환경별로 분리할 실질적인 이점이 크지 않다고 판단했습니다.

이에 따라 불필요한 복잡도를 추가하지 않고, 현재와 같이 공통 SecurityFilterChain에서 Swagger 경로를 permitAll로 관리하는 방식으로 구현했습니다.

이러한 판단에 대한 리뷰어님의 의견 부탁드립니다.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[chore] 개발 / 배포 환경 분리 + API 권한 관리 로직 개선

2 participants