9.1. 설정
프로젝트의 연결 상태, API 키, 검사 조건, 애플리케이션 그룹, 알림 채널, 사용자 권한을 한 곳에서 관리합니다.
개요
설정 페이지는 OPENMARU Observability 프로젝트 전반에 걸친 구성을 관리하는 화면입니다. 좌측 사이드바에서 설정 메뉴를 클릭하면 진입할 수 있으며, 상단의 탭으로 기능 영역을 전환합니다.
| 탭 | 내용 |
|---|---|
| 시스템 설정 | 서버 연결 상태 확인 및 API 키 관 리 |
| 검사 조건 설정 | 인시던트(Incident) 발생 기준 임계값 설정 |
| 애플리케이션 카테고리 | 애플리케이션 그룹화 규칙 및 사용자 정의 애플리케이션 설정 |
| 알림채널 연결 | Slack, Teams, Email(SMTP), Webhook 알림 연동 |
| 사용자 및 권한관리 | 사용자 계정 관리 및 RBAC(Role-Based Access Control, 역할 기반 액세스 제어) |
| 보안 설정 | IP 화이트리스트(IP Whitelist) 관리 |
화면 구성
설정 페이지는 다음 영역으로 구성됩니다.
- 페이지 헤더: 설정 아이콘과 페이지 제목
- 탭 바: 6개 기능 탭(시스템 설정, 검사 조건 설정, 애플리케이션 카테고리, 알림채널 연결, 사용자 및 권한관리, 보안 설정) 전환
- 탭 콘텐츠 영역: 선택한 탭에 해당하는 설정 항목
주요 기능
시스템 설정
시스템 설정 탭에서는 프로젝트의 서버 연결 상태를 확인하고 API 키(API Key)를 관리합니다.
노드 상태
노드 상태 섹션에서 프로젝트에 연결된 구성 요소의 연결 상태를 확인할 수 있습니다.
| 항목 | 설명 | 작업 |
|---|---|---|
| VictoriaMetrics | 메트릭(Metric) 저장소 연결 상태 | 미연결 시 설정 링크 표시 |
| openmaru-node-agent | 노드 에이전트 설치 여부 및 탐지된 노드 수 | 설치 버튼 표시 |
| kube-state-metrics | Kubernetes 상태 메트릭 수집기 연결 상태 및 탐지된 애플리케이션 수 | -- |
각 항목의 상태는 색상 표시등으로 확인할 수 있습니다.
- 녹색: 정상 연결
- 빨간색: 연결 실패 또는 미설치
- 회색: 상태를 알 수 없음
openmaru-node-agent가 설치되지 않은 경우 설치 버튼을 클릭하면 에이전트 설치 안내 창이 표시됩니다.
API 키
API 키(API Key)는 에이전트 및 외부 애플리케이션이 이 프로젝트에 측정 데이터를 전송할 때 사용하는 인증 키입니 다.
참고: API 키 관리 기능은 Admin 역할의 사용자만 사용할 수 있습니다. Admin이 아닌 사용자에게는 키 값이 표시되지 않습니다.
API 키 조회
- 시스템 설정 탭을 엽니다.
- API 키 섹션의 테이블에서 각 키의 설명과 마스킹된 값을 확인합니다.
- 눈 모양 아이콘을 클릭하면 전체 키 값이 표시됩니다. 다시 클릭하면 마스킹됩니다.
- 복사 버튼을 클릭하면 API 키가 클립보드에 복사됩니다.
API 키 생성
- API 키 생성 버튼을 클릭합니다.
- 설명 필드에 키의 용도를 입력합니다. (예: "production-agent", "otel-collector")
- 생성 버튼을 클릭합니다.
- 생성된 API 키가 목록에 추가됩니다.
참고: 생성된 API 키는 에이전트 설치 시 사용합니다. 키 값을 안전한 곳에 보관하세요.
API 키 수정
- 수정할 키의 편집 버튼(연필 아이콘)을 클릭합니다.
- 설명 필드를 수정한 후 저장 버튼을 클릭합니다.
API 키 삭제
- 삭제할 키의 삭제 버튼(휴지통 아이콘)을 클릭합니다.
- 삭제 확인 창이 열립니다.
- 삭제 버튼을 클릭하여 확인합니다.
주의: API 키를 삭제하면 해당 키를 사용하는 에이전트나 애플리케이션이 더 이상 측정 데이터를 전송할 수 없습니다. 삭제 전 해당 키를 사용 중인 에이전트가 없 는지 확인하세요.
비용 설정
비-Kubernetes(호스트) 모드가 아닌 프로젝트에서는 비용 설정 섹션이 함께 표시됩니다. 자원 사용량에 대한 단가를 지정하여 자원 현황·예측 보고서의 비용 계산 기준으로 사용합니다. 자세한 내용은 SRE 보고서 장을 참조하세요.
사용자 추정
사용자 추정 설정 섹션에서는 HTTP 트래픽에서 고유 사용자를 식별하는 방법을 설정합니다. 변경 사항은 약 1분 후 모든 node-agent에 반영됩니다. 자세한 내용은 사용자 추정 장을 참조하세요.
검사 조건 설정
검사(Inspection)는 애플리케이션 및 인프라의 상태를 지속적으로 모니터링하는 임계값(Threshold) 조건입니다. 설정한 임계값을 초과하면 인시던트(Incident)가 자동으로 생성됩니다.
검사 항목 목록
검사 조건 설정 탭에는 검사 항목 목록이 테이블 형태로 표시됩니다.
| 컬럼 | 설명 |
|---|---|
| 검사 항목 | 검사 조건의 카테고리와 이름 (예: 가용성, 응답 시간, 서버 CPU 사용률) |
| 조건 | 현재 적용 중인 기본 임계값 조건 |
| 프로젝트 수준 재정의 | 이 프로젝트 전체에 적용할 사용자 정의 임계값 |
| 애플리케이션 수준 재정의 | 개별 애플리케이션에 적용한 사용자 정의 임계값 |
주요 검사 항목:
- 가용성(Availability): 요청 성공률 임계값
- 응답 시간(Latency): 요청 처리 소요 시간 임계값
- 인스턴스 가용성: 인스턴스 정상 동작 여부
- 서버 CPU 사용률: 노드 CPU 사용률 임계값
- 컨테이너 CPU 사용률: 컨테이너 CPU 사용률 임계값
- 메모리 부족(OOM): Out of Memory 발생 탐지
- 메모리 누수: 메모리 지속 증가 탐지
- 디스크 I/O 부하: 디스크 입출력 부하 임계값
- 재시작: 컨테이너 재시작 횟수 임계값
- 배포 상태: 배포 이상 상태 탐지
- 오류: 오류 발생률 임계값
- Redis 가용성 / 응답 시간: Redis 서비스 관련 임계값
- PostgreSQL 가용성 / 응답 시간 / 복제 지연: PostgreSQL 서비스 관련 임계값
- MongoDB 가용성 / 복제 지연: MongoDB 서비스 관련 임계값
- MySQL 가용성 / 복제 지연: MySQL 서비스 관련 임계값
- Memcached 가용성: Memcached 서비스 가용성 임계값
- DNS 응답 시간 / 오류: DNS 관련 임계값
- 로그 오류: ERROR 및 CRITICAL 심각도 로그 메시지 수 임계값
- JVM 가용성: JVM 인스턴스 가용성 임계값
- 네트워크 연결: 업스트림 서비스 RTT 및 가용성 임계값
프로젝트 수준 임계값 재정의
특정 검사 항목의 임계값을 프로젝트 전체에 걸쳐 변경하려면:
- 변경할 검사 항목의 프로젝트 수준 재정의 열에서 재정의 링크를 클릭합니다.
- 설정 창이 열리면 원하는 임계값을 입력합니다.
- 설정 창에는 전역 기본값(Global default), 프로젝트 수준 재정의(Project-level override), 그리고 필요 시 애플리케이션 수준 재정의 행이 표시됩니다.
- 프로젝트 수준 재정의가 설정되지 않은 경우 전역 기본값이 적용되며, 재정의 링크를 클릭하여 사용자 정의 값을 입력할 수 있습 니다.
- 저장 버튼을 클릭합니다.
설정이 완료되면 해당 열에 재정의된 값이 표시됩니다. 재정의 값을 변경하려면 표시된 값 옆의 편집 아이콘을 클릭합니다.
참고: SLO(Service Level Objective, 서비스 수준 목표) 가용성 및 SLO 응답 시간 항목은 프로젝트 수준 재정의를 지원하지 않습니다. 해당 항목은 애플리케이션 상세 페이지에서 개별 설정할 수 있습니다.
애플리케이션별 임계값 재정의
특정 애플리케이션에만 다른 임계값을 적용하려면:
- 애플리케이션 수준 재정의 열에 표시된 해당 애플리케이션 이름의 편집 아이콘을 클릭합니다.
- 설정 창에서 해당 애플리케이션에 적용할 임계값을 입력합니다.
- 저장 버튼을 클릭합니다.
팁: 서비스 특성에 따라 애플리케이션별 임계값을 개별 조정하면 불필요한 인시던트 발생을 줄이고 정확한 경보를 받을 수 있습니다.
SLO 검사 조건 설정
SLO 가용성 및 SLO 응답 시간 항목은 애플리케이션 상세 페이지의 SLO 탭에서 설정합니다. 검 사 조건 설정 창에서는 다음을 구성할 수 있습니다.
SLO 가용성 설정
- 지표(Metrics): 기본 제공되는 인바운드 요청(built-in)을 사용하거나, 사용자 정의 PromQL 쿼리를 지정할 수 있습니다. 사용자 정의를 선택하면 총 요청 쿼리와 실패 요청 쿼리를 별도로 입력합니다.
- 목표값(Objective): 체크박스로 SLO 추적을 활성화하고, 요청 성공률 목표를 퍼센트(%)로 설정합니다. (예:
99%의 요청이 실패하지 않아야 함)
SLO 응답 시간 설정
- 지표(Metrics): 기본 제공 인바운드 요청 또는 사용자 정의 히스토그램 쿼리를 지정할 수 있습니다.
- 목표값(Objective): 요청의 일정 비율이 지정한 응답 시간 이내에 처리되어야 하는 목표를 설정합니다. (예:
99%의 요청이500ms이내에 처리되어야 함) - 대상 버킷: 5ms, 10ms, 25ms, 50ms, 100ms, 250ms, 500ms, 1s, 2s, 3s, 4s, 5s, 6s, 7s, 8s, 9s, 10s 중에서 선택할 수 있습니다(1초 이상은 1초 간격).
경고(Alerting)
SLO 설정 창 하단에 현재 연동된 알림 채널 상태가 표시됩니다. 알림 채널이 설정되지 않은 경우 알림 채널 설정 버튼을 클릭하여 알림채널 연결 탭으로 이동할 수 있습니다.
SLO 검사 조건의 재정의를 삭제하려면 설정 창에서 삭제 아이콘을 클릭합니다.
애플리케이션 카테고리
애플리케이션을 논리적으로 그룹화하여 관리하는 설정입니다. 카테고리(Category)를 정의하면 대시보드, 토폴로지 맵, 애플리케이션 목록 등 여러 화면에서 카테고리 필터로 애플리케이션을 구분하여 볼 수 있습니다.
카테고리 설정
카테고리 목록에는 현재 정의된 카테고리가 표시됩니다.
| 컬럼 | 설명 |
|---|---|
| 카테고리 | 카테고리 이름 |
| 패턴 | 이 카테고리에 포함할 애플리케이션을 매칭하는 Glob 패턴 |
| 배포 알림 | 이 카테고리 애플리케이션의 배포 발생 시 알림 수신 여부 (켜짐/꺼짐) |
| 작업 | 편집 및 삭제 버튼 |
참고: 기본 카테고리(default)는 다른 카테고리에 포함되지 않는 애플리케이션을 담는 카테고리입니다. 기본 카테고리는 삭제할 수 없습니다. 내장(builtin) 카테고리는 이름과 내장 패턴을 변경할 수 없으며, 사용자 정의 패턴만 추가할 수 있습니다.
카테고리 추가
- 카테고리 추가 버튼을 클릭합니다.
- 이름 필드에 카테고리 이름을 입력합니다.
- 사용 자 정의 패턴 필드에 이 카테고리에 포함할 애플리케이션 패턴을 입력합니다.
- 패턴은
네임스페이스/애플리케이션명형식으로 입력합니다. (예:staging/*,test-*/*) - 여러 패턴은 공백으로 구분합니다.
- Glob 패턴 문법을 사용할 수 있습니다.
- 패턴은
- 배포 알림 옵션을 설정합니다. 활성화하면 이 카테고리의 애플리케이션이 배포될 때 설정된 알림 채널로 알림이 전송됩니다.
- 알림 채널이 설정되지 않은 경우 "알림 채널이 설정되지 않았습니다" 메시지가 표시되며, 알림 채널 설정 버튼을 클릭하여 알림채널 연결 탭으로 이동할 수 있습니다.
- 저장 버튼을 클릭합니다.
카테고리 편집 및 삭제
- 편집: 목록에서 카테고리의 편집 버튼(연필 아이콘)을 클릭하여 설정을 변경합니다.
- 삭제: 삭제 버튼(휴지통 아이콘)을 클릭합니다. 내장 카테고리는 삭제할 수 없습니다.
참고: Kubernetes 애플리케이션의 경우, Kubernetes 객체에 주석(annotation)을 달아서 카테고리를 정의할 수도 있습니다.
사용자 정의 애플리케이션
OPENMARU Observability는 기본적으로 다음 방법으로 컨테이너를 애플리케이션으로 자동 그룹화합니다.
- Kubernetes 메타데이터: Pod이 Deployment, StatefulSet 등으로 그룹화됩니다.
- Kubernetes 이외의 컨테이너: Docker 컨테이너 또는 Systemd 유닛은 이름 기준으로 그룹화됩니다. 예를 들어 여러 서버에서 실행 중인
mysql서비스는 하나의mysql애플리케이션으로 묶입니다.
이 기본 방식이 적합하지 않은 경우, 사용자 정의 애플리케이션 설정으로 인스턴스 이름 패턴을 정의하여 원하는 컨테이너를 하나의 애플리케이션으로 묶을 수 있습니다.
| 컬럼 | 설명 |
|---|---|
| 애플리케이션 이름 | 사용자 정의 애플리케이션의 이름 |
| 인스턴스 패턴 | 이 애플리케이션에 포함할 인스턴스를 매칭하는 Glob 패턴 |
| 작업 | 편집 및 삭제 버튼 |
사용자 정의 애플리케이션 추가
- 애플리케이션 추가 버튼을 클릭합니다.
- 이름 필드에 애플리케이션 이름을 입력합니다.
- 인스턴스 패턴 필드에 포함할 인스턴스 이름 패턴을 입력합니다.
- 인스턴스 이름 기준으로 매칭합니다. (예:
mysql@node1,cassandra@cass-node*) - 여러 패턴은 공백으로 구분합니다.
- 인스턴스 이름 기준으로 매칭합니다. (예:
- 저장 버튼을 클릭합니다.
참고: 사용자 정의 애플리케이션 설정은 Kubernetes 환경이 아닌 컨테이너(Docker 컨테이너, Systemd 유닛 등)에 적용됩니다. Kubernetes 워크로드에는 적용되지 않습니다.
네임스페이스 규칙
비-Kubernetes 워크로드(Docker, Systemd, 호스트 프로세스)에 대해 container_id를 Glob 패턴으로 매칭하여 사용자 지정 네임스페이스를 부여합니다. 규칙은 순서대로(첫 매칭 우선) 평가되며, 사용자 수 추정과 보안 공격 탐지가 지정한 네임스페이스로 집계됩니다.
숨긴 애플리케이션
모든 화면(리스트, 토폴로지, 헬스, 인시던트)에서 숨긴 애플리케이션을 관리합니다. 숨김은 되돌릴 수 있고 데이터는 그대로 유지되므로, 언제든 다시 표시하여 애플리케이션을 복원할 수 있습니다.
알림채널 연결
인시던트 및 배포 이벤트가 발생했을 때 외부 채널로 알림(Notification)을 전송하도록 설정합니다.
기본 URL 설정
알림 메시지에 포함되는 링크의 기준이 되는 URL입니다. 외부에서 이 시스템에 접근할 수 있는 URL을 입력합니다.
- 기본 URL 입력 필드에 URL을 입력합니다.
- 저장 버튼을 클릭합니다.
참고: 기본 URL이 설정되지 않은 경우, 현재 접속 중인 브라우저의 URL이 자동으로 설정됩니다.
알림 채널 목록
지원되는 알림 채널이 테이블에 표시됩니다.
| 컬럼 | 설명 |
|---|---|
| 유형 | 알림 채널 종류 (Slack, MS Teams, Email(SMTP), Webhook) |
| 인시던트 알림 | 인시던트 발생 시 이 채널로 알림 전송 여부 |
| 배포 알림 | 배포 발생 시 이 채널로 알림 전송 여부 |
| 알림 | 알림 규칙 발화 시 이 채널로 전송 여부 |
| 작업 | 설정, 편집, 삭제 버튼 |
아직 설정되지 않은 채널에는 설정 버튼이 표시되고, 이미 설정된 채널에는 편집(연필 아이콘) 및 삭제(휴지통 아이콘) 버튼이 표시됩니다.
Slack 연동
Slack 채널로 인시던트 및 배포 알림을 수신하려면:
- Slack 항목의 설정 버튼을 클릭합니다.
- Slack 앱 생성: Create Slack app 버튼을 클릭하여 Slack에서 앱을 생성합니다. 앱이 생성되면 Slack에서 Install to workspace를 클릭하여 승인합니다.
- Slack 봇 사용자 OAuth Token: Slack 앱의 OAuth & Permissions 페이지에서 Bot User OAuth Token을 복사하여 입력합니다.
- Slack 채널 이름: Slack에서 공용 채널을 생성한 후,
#뒤에 채널 이름을 입력합니다. - 알림 유형: 인시던트 및 배포 체크박스로 수신할 알림 유형을 선택합니다.
- 테스트 알림 보내기 버튼을 클릭하여 설정이 올바른지 확인합니다.
- 저장 버튼을 클릭합니다.
Microsoft Teams 연동
Microsoft Teams 채널로 알림을 수신하려면:
- Teams에서 대상 채널을 선택합니다(또는 새 채널을 생성합니다).
- 상단 탐색 메뉴에서 점 세 개(...)를 클릭하고 Connectors를 선택합니다.
- Incoming Webhook을 검색하고 Configure 버튼을 누릅니다.
- Webhook 이름을 입력하고 Create 버튼을 누릅니다.
- 생성 된 Webhook URL을 복사합니다.
- 설정 페이지에서 Teams 항목의 설정 버튼을 클릭합니다.
- Webhook URL 필드에 복사한 URL을 붙여넣습니다.
- 알림 유형: 인시던트 및 배포 체크박스로 수신할 알림 유형을 선택합니다.
- 테스트 알림 보내기 버튼을 클릭하여 설정이 올바른지 확인합니다.
- 저장 버튼을 클릭합니다.
Webhook 연동
커스텀 Webhook으로 알림을 전송하여 외부 시스템과 자유롭게 연동할 수 있습니다.
- Webhook 항목의 설정 버튼을 클릭합니다.
- Webhook URL을 입력합니다.
- 필요 시 다음 고급 옵션을 설정합니다.
- TLS 검증 건너뛰기: 자체 서명 인증서 사용 시 활성화 (HTTPS URL인 경우에만 활성화 가능)
- HTTP 기본 인증: 사용자 이름과 비밀번호를 입력하여 인증 설정
- 사용자 정의 HTTP 헤더: 헤더 이름과 값을 추가합니다. 여러 헤더를 추가할 수 있습니다.
- 알림 유형: 인시던트 및 배포 체크박스로 수신할 알림 유형을 선택합니다.
- 인시던트 템플릿: 인시던트 발생 시 전송할 메시지 형식을 설정합니다.
- 배포 템플릿: 배포 발생 시 전송할 메시지 형식을 설정합니다.
- 테스트 알림 보내기 버튼을 클릭하여 설정이 올바른지 확인합니다.
- 저장 버튼을 클릭합니다.
Email(SMTP) 연동
사내 메일 서버로 알림을 받습니다. 외부 SaaS로 나갈 수 없는 폐쇄망에서 쓸 수 있는 통로입니다.
- Email (SMTP) 항목의 설정 버튼을 클릭합니다.
- 메일 서버의 호스트와 포트를 입력합니다.
- 암호화 방식을 선택합니다. 방식을 고르면 포트 기본값이 함께 바뀌지만, 포트를 직접 입력한 뒤에는 덮어쓰지 않습니다.
| 방식 | 기본 포트 | 설명 |
|---|---|---|
| STARTTLS | 587 | 평문으로 연결한 뒤 암호화로 전환합니다. 서버가 지원하지 않으면 실패합니다 |
| TLS | 465 | 첫 바이트부터 암호화합니다 |
| 없음 | 25 | 암호화하지 않습니다. 암호화되지 않은 연결에서는 인증이 거부됩니다 |
- 사설 인증기관이 발급한 인증서를 쓴다면 TLS 인증서 검증 건너뛰기를 켭니다.
주의: 이 옵션을 켜면 어떤 인증서든 받아들입니다. 신뢰하는 사 설 인증기관 환경에서만 사용하세요.
- 인증의 사용자 이름과 비밀번호를 입력합니다. 인증이 필요 없는 릴레이라면 비워 둡니다.
- 주소를 입력합니다. 보내는 주소와 보내는 사람 이름, 받는 주소(여러 명이면 쉼표로 구분)를 지정합니다.
- 묶음 발송 간격을 분 단위로 지정합니다. 0이면 건별로 즉시 보냅니다.
주의: 묶음 발송은 심각도를 구분하지 않습니다. 장애 알림도 최대 이 시간만큼 늦게 도착합니다. 급한 알림을 놓치면 안 되는 채널이라면 0으로 두세요.
- 알림 언어를 선택합니다(한국어 / English).
- 알림 대상에서 장애·배포·알림 중 받을 유형을 고릅니다.
참고: 배포 알림을 처음 켜면 최근 24시간 배포에 대한 알림이 한 번 발송됩니다. 묶음 발송을 켜 두었다면 한 통으로 묶여 옵니다.
- 테스트 알림 보내기 버튼으로 설정이 올바른지 확인합니다.
- 저장 버튼을 클릭합니다.
설정이 맞지 않을 때 나오는 문구
메일 설정은 한 번에 맞는 일이 드뭅니다. 테스트 발송이 실패하면 화면에 원인이 그대로 표시됩니다.
| 문 구에 포함된 말 | 원인 |
|---|---|
connection refused 또는 i/o timeout | 호스트·포트가 틀렸거나 방화벽에 막힘 |
certificate 또는 x509 | 인증서를 신뢰할 수 없음. 사설 인증서라면 검증 건너뛰기를 켠다 |
Must issue a STARTTLS command first | 서버가 암호화를 요구하는데 없음으로 설정함 |
Authentication credentials invalid | 사용자 이름·비밀번호가 틀림 |
보고서 첨부
SRE 보고서의 정기 보고서를 SMTP로 받으면 PDF·Excel이 첨부로 옵니다. 첨부가 상한(기본 20MB)을 넘으면 첨부를 빼고 본문에 그 사유를 적어 보냅니다.
채널 수정 및 삭제
- 편집: 설정된 채널의 편집 버튼(연필 아이콘)을 클릭하여 설정을 변경합니다.
- 삭제: 삭제 버튼(휴지통 아이콘)을 클릭하여 연동을 해제합니다.
사용자 및 권한관리
프로젝트에 접근할 수 있는 사용자를 관리하고, RBAC를 통해 각 사용자의 권한을 설정합니다.
사용자 관리
등록된 사용자 목록이 테이블 형태로 표시됩니다.
| 컬럼 | 설명 |
|---|---|
| 이메일(로그인) | 사용자 로그인 이메일 주소 |
| 이름 | 사용자 이름 |
| 역할 | 할당된 역할 (Admin, Editor, Viewer) |
| 작업 | 편집 및 삭제 버튼 |
사용자 추가
- 사용자 추가 버튼을 클릭합니다.
- 사용자 추가 창이 열리면 다음 정보를 입력합니다.
- 이메일(로그인): 사용자의 로그인 이메일 주소
- 이름: 사용자 이름
- 역할: 부여할 역할 선택 (Admin, Editor, Viewer)
- 비밀번호: 초기 비밀번호 설정
- 생성 버튼을 클릭합니다.
사용자 수정
- 수정할 사용자의 편집 버튼(연필 아이콘)을 클릭합니다.
- 이메일, 이름, 역할, 비밀번호를 수정한 후 저장 버튼을 클릭합니다.
참고: 비밀번호 필드를 비워두면 기존 비밀번호가 유지됩니다.
사용자 삭제
- 삭제할 사용자의 삭제 버튼(휴지통 아이콘)을 클릭합니다.
- 삭제 확인 창에서 삭제 버튼을 클릭합니다.
참고: 읽기 전용(readonly)으로 표시된 사용자는 편집 및 삭제가 불가능합니다.
역할 기반 액세스 제어 (RBAC)
RBAC를 통해 각 역할이 수행할 수 있는 작업을 관리합니다.
OPENMARU Observability는 세 가지 기본 역할을 제공합니다.
| 역할 | 설명 |
|---|---|
| Admin | 모든 기능에 대한 완전한 접근 권한. 사용자 관리, 설정 변경, 데이터 조회 모두 가능. |
| Editor | 대부분의 모니터링 기능 사용 가능. 일부 관리 기능(사용자 관리 등)은 제한됨. |
| Viewer | 모니터링 데이터 조회만 가능. 설정 변경 불가. |
역할 기반 액세스 제어(RBAC) 섹션의 테이블에서 각 역할이 수행할 수 있는 작업 항목을 확인할 수 있습니다.
- 체크 표시(녹색): 해당 역할에서 허용되는 작업
- 목록 아이콘(녹색): 특정 객체에 한정하여 허용되는 작업 (아이콘에 마우스를 올리면 허용 대상 목록이 툴팁으로 표시됩니다)
- X 표시(빨간색): 해당 역할에서 허용되지 않는 작업
주요 작업 항목은 다음과 같습니다.
| 작업 | Admin | Editor | Viewer |
|---|---|---|---|
| 사용자 관리 | 허용 | 거부 | 거부 |
| 역할 관리 | 허용 | 거부 | 거부 |
| 프로젝트 설정 변경 | 허용 | 거부 | 거부 |
| 알림 채널 설정 | 허용 | 거부 | 거부 |
| 카테고리 설정 | 허용 | 허용 | 거부 |
| 사용자 정의 애플리케이션 설정 | 허용 | 허용 | 거부 |
| 검사 조건 설정 | 허용 | 허용 | 거부 |
| 분산추적 조회 | 허용 | 허용 | 허용 |
| 위험요소 조회 | 허용 | 허용 | 허용 |
| 위험요소 편집 | 허용 | 거부 | 거부 |
| 애플리케이션 조회 | 허용 | 허용 | 허용 |
| 서버 조회 | 허용 | 허용 | 허용 |
참고: 커스텀 역할을 가진 사용자가 존재할 경우 RBAC 테이블에 해당 역할이 함께 표시됩니다. 커스텀 역할의 편집 버튼(연필 아이콘)을 클릭하면 Scope, Action, Object 단위의 세분화된 권한 정책을 확인할 수 있습니다.
보안 설정
보안 설정 탭에서는 IP 화이트리스트(IP Whitelist)를 관리합니다. 허용할 IP 주소 또는 CIDR 대역을 등록하면, 해당 출발지에서 들어오는 트래픽은 보안 공격 탐지 대상에서 제외됩니다. 사내 스캐너, 헬스 체크, 신뢰할 수 있는 게이트웨이 등 정상 트래픽이 공격으로 오탐되는 것을 방지하는 데 사용합니다.
허용 항목을 추가하려면 IP 주소 또는 CIDR 대역을 입력한 후 저장하고, 더 이상 필요하지 않은 항목은 목록에서 삭제합니다.
참고: 보안 공격 탐지 및 보안 이벤트에 대한 자세한 내용은 보안 장을 참조하세요.