Prometheus 대시보드의 API 호출 수와 월말 청구서 금액이 맞지 않는다면, 문제는 "측정이 부족해서"가 아니라 측정의 목적을 섞었기 때문일 수 있습니다.

엔지니어는 "지금 시스템이 괜찮은가"를 보고, 재무 담당자는 "얼마를 받을 수 있는가"를 봅니다. 둘 다 시계열 데이터를 수집하지만, 요구되는 정확도·보존 기간·감사 가능성은 완전히 다릅니다. 같은 숫자처럼 보여도, 신뢰할 수 있는 대상이 다릅니다.

본 문서는 시크릿을 어디에 두고 어떻게 생명주기를 관리할지에 대한 개념과 설계 관점을 다룹니다. Vault 버전별 설치·튜닝·API 세부는 HashiCorp Vault 공식 문서를 우선합니다.

현대 애플리케이션은 API 키, 데이터베이스 비밀번호, TLS 인증서, 클라우드 자격 증명 등 상호 연결을 위해서 비밀 값(secret) 에 의존합니다. 이를 개발 단계에서 애플리케이션 코드나 빌드되는 이미지에 하드코딩 방식은 배포가 빠르지만, 유출 시 피해가 크고 회전(rotation)·감사(audit)가 어렵습니다. Secret Management는 이런 비밀을 중앙에서 안전하게 저장하고, 접근을 통제하며, 필요할 때만 짧게 나눠 주는 행위를 가리킵니다.

마이크로서비스, 컨테이너 오케스트레이션, 클라우드 등 동적·이기종 환경에서는 IP·호스트명만으로는 “어떤 워크로드가 요청하는지”를 일관되게 식별하기 어렵습니다. SPIFFE(Secure Production Identity Framework for Everyone)는 이런 환경에서 소프트웨어 워크로드에 암호학적으로 검증 가능한 신원을 부여하기 위한 오픈 표준입니다.

SPIFFE의 핵심: SPIFFE ID와 SVID

개념 문서: HashiCorp Vault — SPIFFE auth method
HTTP API: SPIFFE auth method (API)

참고 URL : https://developer.hashicorp.com/vault/tutorials/vault-agent/agent-env-vars

Vault Agent Template vs Environemnt based execution

서비스 및 파드용 DNS 참고

svc.cluster.local은 쿠버네티스 클러스터 내부에서 서비스(Service) 간 통신을 위해 사용하는 기본 도메인 접미사(Internal Cluster Domain)입니다. CoreDNS에 의해 관리되며, 서비스명과 네임스페이스를 조합하여 <서비스명>.<네임스페이스>.svc.cluster.local 형태의 고유한 내부 FQDN(Fully Qualified Domain Name)을 제공하여 파드 간 통신을 용이하게 합니다.

1. 개요

HashiCorp Vault는 시작 시 Sealed(봉인된) 상태로 시작합니다. 이 상태에서는 물리적 스토리지에 접근할 수 있지만, 저장된 데이터를 복호화할 수 없습니다. Unsealing(봉인해제)은 Vault가 데이터를 복호화하기 위해 필요한 root key에 접근하는 과정입니다.

2. 암호화 계층 구조

Vault는 3단계 암호화 계층 구조를 사용하여 데이터를 보호합니다:

2.1 각 키의 역할

개요

모든 컴퓨팅 시스템의 필수 기능 중 하나는 I/O입니다: 디스크, 테이프, 프린터, 네트워크와 같은 외부 장치에 대한 읽기와 쓰기입니다. 이 모듈에서는 z/OS에서 I/O가 어떻게 작동하는지 살펴봅니다.

학습 목표

이 모듈을 완료한 후, 다음을 수행할 수 있습니다:

• Channel Subsystem의 기능과 작동 방식을 설명할 수 있습니다.
• OSA Communications와 Channel Subsystem의 차이점을 설명할 수 있습니다.
• SMC와 RoCE가 무엇이고 시스템 간 통신에 어떻게 사용되는지 설명할 수 있습니다.

개요

IBM Z 메인프레임은 동시에 여러 시스템을 실행할 수 있습니다. 단일 CPC(Central Processor Complex)는 세 개의 z/OS 시스템을 실행할 수 있습니다.

여러 z/OS 시스템을 실행할 때, 이러한 시스템들은 데이터셋, 데이터베이스, 보안 정보 등과 같은 리소스를 공유하는 경우가 많습니다.

이 모듈에서는 단일 CPC에서 여러 운영 체제가 어떻게 실행되는지 탐구하고, 여러 z/OS 시스템이 리소스를 공유하는 방법을 소개합니다.

학습 목표

개요

단일 z/OS 시스템은 동시에 수천 개의 다양한 작업을 실행합니다. 이러한 작업들은 모두 CPU와 같은 리소스를 공유하고 경쟁해야 합니다. z/OS는 이러한 작업들이 리소스를 공유하는 방법을 제어하는 기능을 제공하며, 어떤 작업이 더 많은 리소스를 받고 어떤 작업이 더 적은 리소스를 받을지 결정합니다.

이 모듈에서는 이러한 기능들을 탐구하고, 이들이 어떻게 작동하는지 알아봅니다.

학습 목표

이 모듈을 완료한 후, 다음을 수행할 수 있습니다:

• Workload Management(WLM)가 무엇인지, 그리고 리소스를 어떻게 제어하는지 설명할 수 있습니다.
• WLM이 어떻게 작동하는지 설명할 수 있습니다.