Vault Overview
HashiCorp Vault는 API 기반의 클라우드에 종속되지 않는 비밀 관리 시스템입니다.
하이브리드 클라우드 환경에서 민감한 데이터를 안전하게 저장하고 관리할 수 있습니다.
또한 Vault를 사용하여 동적 단기 자격 증명 (credentials)을 생성하거나 애플리케이션 데이터를 즉석에서 암호화할 수 있습니다.
Vault는 SaaS (HCP)와 설치 모델 두가지를 제공합니다.
Vault License
Vault 라이센스 종류는 OSS와 Enterprise 로 나누어져 있습니다.
엔터프라이즈 라이센스의 주요 기능
엔터프라이즈 라이센스의 주요 기능은 다음과 같습니다.
네임스페이스
- 하나의 Vault 시스템에 또 다른 Vault 시스템을 구성하여, 서로 격리된 정책, ID&PW, 보안데이터를 관리
- 보안, 규정 준수를 위한 멀티 테넌트 환경
- 격리된 Vault 시스템 별 규정 준수 시행
MFA
- Vault는 다양한 인증 유형을 사용하여 MFA를 지원하며, TOTP (Time-based one-time password)를 제공
- Vault TOTP 암호화 토큰을 조합하여 유사한 TOTP 유틸리티를 활용
- Okta, Duo, PingID 인증 유형 사용
DR
- 주센터와 DR센터에 Vault 시스템을 구성하여, 통합된 보안데이터를 복제
- 센터간의 복제는 네트워크로 수행
- Async 방식으로 복제되며, 주기적으로 데이터 동기화 진행
성능 복제 (Performance Replication)
- Vault는 보안 데이터의 고도화된 이중화 환경을 위해 멀티 데이터 센터 복제 방식을 제공
- 다중 데이터센터 복제 - 1 : N 제공
- 복제되는 모든 Vault 시스템은 중앙에서 통합하여 관리
복제 필터
- 서로 다른 클러스터 간 복제 대상과, 복제가 되지 않아야 하는 대상을 설정하여, 복제 성능을 향상
- 복제 대상을 Path를 등록하여 설정
- 복제를 하지 않는 대상을 Path로 등록하여 설정
리드 리플리카 (Read Replicas)
- Vault 클러스터의 Active 서버는 Read/Write를 수행하고, 나머지 서버에서 Read 수행
- Read I/O 분산 처리로 고성능 제공
- Vault 서버 장애 시에도 남은 서버로 서비스가 되는 무중단 운영 환경
Sentinel Integration
- 비밀 정보는 Path로 구성되며, Path 마다 RBAC를 설정하여, 고도화된 보안 환경 구축
- 비밀 정보 Path 마다, create, read, write, update, delete중 필요한 정책 적용
- 세밀한 보안 정책 적용 가능
임대 카운트 쿼터 (Lease Count Quotas)
- 시스템 안정성 및 대규모 스토리지 성능을 보호하기 위해 생성 된 키들의 수를 제한
- 비밀 정보 Path 마다 생성될 수 있는 키의 수를 제안 (Quota)
- 필요 이상으로 생성된 불필요한 키 관리
Vault 를 사용하면 좋은 점
- 하드코딩된 자격증명 보안 이슈 및 수동관리의 어려움을 대체할 수 있다.
- 네트워크 경계 전반에 걸쳐 보안을 확장할 수 있는 ID 기반 규칙출처를 유지하기 위한 개별 계정
- 쉽게 무효화될 수 있는 자격 증명 (credentials) 및 엔터티(Entities)
- 자주 교체되는 동적 단기 자격 증명
- 많은 시스템에 대해 사용자와 응용 프로그램을 인증할 수 있도록 지원한다.
사용법
- Vault 는 CLI 를 제공하며 보안 읽기, 쓰기 등 수행할 수 있습니다.
- Vault 서버는 두 가지 모드로 실행할 수 있습니다.
- "Dev" mode : 개발 목적으로 만 사용
- 유의할 점: 볼트의 데브 모드는 안전하지 않습니다.Vault는 자동으로 봉인 해제됩니다."Dev" 모드에서 실행되는 서버에 실제 비밀을 저장하지 마십시오.
- 루트 토큰은 시작하기 전에 지정할 수 있습니다.
- 메모리에 모든 것을 저장합니다.
- "Prod" mode : QA와 운영 목적으로 사용
- "Prod" 모드에서 Vault 서버를 실행하려면 여러 단계를 거쳐야 합니다.
- Config file에서 구성을 지정합니다.
- 서버를 시작합니다.
- Unseal keys와 initial root token을 얻기 위해 서버를 초기화합니다.
- Unseal keys로 Vault 서버의 봉인을 해제합니다.
- "Prod" 모드에서 Vault 서버를 실행하려면 여러 단계를 거쳐야 합니다.
- "Dev" mode : 개발 목적으로 만 사용
- Vault 는 Vault UI 가 지원됩니다.
- UI를 사용하려면 처음에 로그인을 해야합니다.
- 새 Vault 서버는 처음에 토큰 인증 방법만 활성화됩니다.
- 토큰 인증 방법을 사용하고 ”root"를 토큰으로 지정하는 방법이 있습니다.
- Vault 는 Vault API를 제공합니다.
- JSON 출력 형식을 지정하기 위해 jq가 뒤에 오는 간단한 curl 명령어를 사용하여 Vault의 상태를 확인할 수 있습니다.
- Command 예: curl http://localhost:8200/v1/sys/health | jq
# Result
{
"initialized": true,
"sealed": false,
"standby": false,
"performance_standby": false,
"replication_performance_mode": "disabled",
"replication_dr_mode": "disabled",
"server_time_utc": 1655600004,
"version": "1.10.4+ent",
"cluster_name": "vault-cluster-92ffexxx",
"cluster_id": "3522f7f4-a977-9547-2cf2-xxxxxxxxxx",
"last_wal": 61334,
"license": {
"state": "autoloaded",
"expiry_time": "2023-06-10T23:59:59Z",
"terminated": false
}
}
Vault API 인증은 X-Vault-Token 헤더와 함께 Vault 토큰으로 수행됩니다.
- 볼트 컨피그를 구성하고 프로덕션 서버 시작하기
- "Prod" 모드에서 Vault 서버를 실행하려면 여러 단계를 거쳐야 합니다.
- Vault configuration files 은 HCL 또는 JSON으로 지정할 수 있습니다.
- listener
- seal
- uicluster_addr
- api_addr
- log_level
- storage
- 일반적인 구성 설정은 다음과 같습니다.
- 서버를 시작합니다.
- Unseal keys와 initial root token을 얻기 위해 서버를 초기화합니다.
- Unseal keys로 Vault 서버의 봉인을 해제합니다.
- -dev 옵션 없이 vault server 명령어로 Production 서버를 시작합니다.
- Config file에서 구성을 지정합니다.
- "Prod" 모드에서 Vault 서버를 실행하려면 여러 단계를 거쳐야 합니다.
- 볼트 클러스터 초기화하기
- Vault 클러스터는 여러 Vault 서버를 실행하여 구성합니다.이는 Vault의 vault operator init 으로 수행됩니다.이 명령은 클러스터에 대한 unseal keys와 initial root token을 반환합니다.
- 키 공유 수와 키 임계값은 –key-shares 및 key-threshold 옵션을 사용하여 지정할 수 있습니다.
- 각 Vault 클러스터는 한 번 초기화해야 합니다.
- 각 Vault 서버는 시작할 때마다 봉인(Seal)을 해제해야 합니다.이는 클러스터를 초기화할 때 반환된 unseal keys를 사용하여
vault operator unseal 명령어로 수행됩니다. - 봉인을 해제할 때까지 서버를 사용할 수 없습니다.
- vault status 명령어로 상태 확인 가능하며 봉인 되었는지 아닌지 확인 가능합니다.
$ vault status
WARNING! VAULT_ADDR and -address unset. Defaulting to https://127.0.0.1:8200.
Error checking seal status: Get "https://127.0.0.1:8200/v1/sys/seal-status": http: server gave HTTP response to HTTPS client
$ export VAULT_ADDR='http://127.0.0.1:8200' # no tls for this test demo
$ vault status
Key Value
--- -----
Seal Type shamir
Initialized true
Sealed false
Total Shares 1
Threshold 1
Version 1.17.0
Build Date 2024-06-10T10:11:34Z
Storage Type inmem
Cluster Name vault-cluster-445bxxxx
Cluster ID 6748b197-b91c-89a2-36f3-a78cxxxxxxxx
HA Enabled false
- 볼트 시크릿 엔진
- 대부분의 Vault 비밀 엔진은 명시적으로 활성화해야 합니다.각 비밀 엔진에는 기본 경로가 있습니다.그러면 CLI 명령 및 API 호출에서 사용자 지정 경로를 지정해야 합니다.
vault write aws/config/root 대신 vault write aws-east/config/root - 여러 인스턴스를 활성화하기 위해 대체 경로(path)를 지정할 수 있습니다.
vault secrets enable -path=aws-east aws - vault secrets enable 명령어로 수행됩니다.
- 볼트 엔진 버전은 현재 두가지가 있습니다.
- KV v1(버전 관리 없음)
- KV v2(버전 관리 포함)
- Dev mode는 Vault 서버에 대해 KV v2 엔진의 인스턴스가 자동으로 활성화됩니다.
- Vault는 "Prod" mode 서버에서 KV 시크릿 엔진의 인스턴스를 자동으로 활성화하지 않습니다. 따라서 직접 활성화해야 합니다.
- 기본 경로 kv에 KV v2 secrets 엔진의 인스턴스를 마운트하는 방법
vault secrets enable -version=2 kv- vault kv list는 지정된 경로에 있는 보안 비밀을 나열합니다.vault kv get은 지정된 경로에서 보안 비밀을 읽습니다.
- vault kv delete는 지정된 경로에서 보안 비밀을 삭제합니다.
- vault kv put은 지정된 경로에 보안 비밀을 작성합니다.
- 대부분의 Vault 비밀 엔진은 명시적으로 활성화해야 합니다.각 비밀 엔진에는 기본 경로가 있습니다.그러면 CLI 명령 및 API 호출에서 사용자 지정 경로를 지정해야 합니다.
볼트 인증
- 볼트 인증 방법은 유저, 어플리케이션 대상 두가지로 나눠져 있습니다.
- Methods for UsersGitHubJWT/OIDC
- Okta
- LDAP
- Userpass
- Methods for ApplicationsAWSGoogle Cloud
- Kubernetes
- Azure
- AppRole
- 대부분의 Vault 인증 방법은 명시적으로 활성화해야 합니다.각 인증 방법에는 기본 경로가 있습니다.CLI 명령 및 API 호출에서 사용자 지정 경로를 지정해야 합니다.
vault write aws/config/root 대신 vault write aws-east/config/root - 여러 인스턴스를 활성화하기 위해 대체 경로를 지정할 수 있습니다.
vault auth enable -path=aws-east aws - 이는 vault auth enable 명령어로 수행됩니다.
볼트 정책(Policy)
- Vault Policies는 사용자와 애플리케이션이 액세스할 수 있는 secrets (비밀) 을 제한합니다.
- Vault는 기본적으로 액세스를 거부하는 최소 권한 관행을 따릅니다.
- Vault 관리자는 정책 설명을 사용하여 특정 경로에 대한 사용자 및 애플리케이션 액세스 권한을 명시적으로 부여해야 합니다.
- 경로를 지정하는 것 외에도 정책은 해당 경로에 대한 기능 집합도 지정합니다.
- Policies 는 HashiCorpConfiguration Language (HCL)로 작성됩니다.
- 예시:
# Allow tokens to look up their own properties
path "auth/token/lookup-self" {
capabilities = ["read"]
}
정책 경로는 Vault API 경로에 매핑됩니다.
Vault의 CLI, UI 또는 API를 사용하여 Vault 서버에 Vault 정책을 추가할 수 있습니다.
CLI로 정책을 추가하는 명령어는 vault policy write 입니다
정책을 생성하고 사용자와 연결하는 예시:
vault policy write lob-A-dept-1 lob-A- dept-1-policy.hcl
vault write auth/userpass/users/joe/policies Policies=lob-A-dept-1사용법
먼저 볼트를 ec2 linux 에 설치해 봅니다.
sudo yum install -y yum-utils
# Add repo
sudo yum-config-manager --add-repo https://rpm.releases.hashicorp.com/AmazonLinux/hashicorp.repo
# Install Vault
sudo yum -y install vault
Installed:
vault-1.17.0-1.aarch64
Complete!
$ vault version
Vault v1.17.0 (72850df1bc10581b74ba5f0f7b373xxxxxxx), built 2024-06-10T10:11:34Z간단한 테스트를 위해, dev mode를 활성화하여 볼트를 시작합니다.
$ vault server -dev
==> Vault server configuration:
Administrative Namespace:
Api Address: http://127.0.0.1:8200
Cgo: disabled
Cluster Address: https://127.0.0.1:8201
Environment Variables: BASH_FUNC_which%%, DBUS_SESSION_BUS_ADDRESS, GOTRACEBACK, HISTCONTROL, HISTSIZE, HOME, HOSTNAME, LANG, LESSOPEN, LOGNAME, LS_COLORS, MAIL, MOTD_SHOWN, NVM_BIN, NVM_CD_FLAGS, NVM_DIR, NVM_INC, NVM_RC_VERSION, OLDPWD, PATH, PWD, SELINUX_LEVEL_REQUESTED, SELINUX_ROLE_REQUESTED, SELINUX_USE_CURRENT_RANGE, SHELL, SHLVL, SSH_CLIENT, SSH_CONNECTION, SSH_TTY, SYSTEMD_COLORS, S_COLORS, TERM, USER, XDG_RUNTIME_DIR, XDG_SESSION_CLASS, XDG_SESSION_ID, XDG_SESSION_TYPE, _, which_declare
Go Version: go1.22.4
Listener 1: tcp (addr: "127.0.0.1:8200", cluster address: "127.0.0.1:8201", disable_request_limiter: "false", max_request_duration: "1m30s", max_request_size: "33554432", tls: "disabled")
Log Level:
Mlock: supported: true, enabled: false
Recovery Mode: false
Storage: inmem
Version: Vault v1.17.0, built 2024-06-10T10:11:34Z
Version Sha: 72850df1bc10581b74ba5f0f7b3xxxxxxxx
==> Vault server started! Log data will stream in below:
...
WARNING! dev mode is enabled! In this mode, Vault runs entirely in-memory
and starts unsealed with a single unseal key. The root token is already
authenticated to the CLI, so you can immediately begin using Vault.
You may need to set the following environment variables:
$ export VAULT_ADDR='http://127.0.0.1:8200'
The unseal key and root token are displayed below in case you want to
seal/unseal the Vault or re-authenticate.
Unseal Key: lS0Xa99RlRkP/g2reElBKYhnJggXcOtxxxxxxxxx
Root Token: hvs.EI1TksGnXihdxxxxxxxx
Development mode should NOT be used in production installations!
볼트 서버 상태를 확인합니다.
$ export VAULT_ADDR='http://127.0.0.1:8200'
$ vault status
Key Value
--- -----
Seal Type shamir
Initialized true
Sealed false
Total Shares 1
Threshold 1
Version 1.17.0
Build Date 2024-06-10T10:11:34Z
Storage Type inmem
Cluster Name vault-cluster-44xxxxx
Cluster ID 6748b197-b91c-89a2-36f3-axxxxxxxx
HA Enabled false
key value 로 시크릿을 생성하기 위해 kv 명령어를 실행합니다.
$ vault kv put -mount=secret hello team=banana
== Secret Path ==
secret/data/hello
======= Metadata =======
Key Value
--- -----
created_time 2024-06-23T06:53:49.203123729Z
custom_metadata <nil>
deletion_time n/a
destroyed false
version 1
dev 모드로 볼트 서버를 시작한 경우, 기본 Mount path은 자동으로 생성됩니다.
data hello가 secret/data/hello 로 key value 로 마운트 되었습니다.
kv put으로 여러 key value를 입력할 수 있습니다.
$ vault kv put -mount=secret hello team=banana homework=yes
== Secret Path ==
secret/data/hello
======= Metadata =======
Key Value
--- -----
created_time 2024-06-23T06:57:10.424550787Z
custom_metadata <nil>
deletion_time n/a
destroyed false
version 2이제 시크릿을 get 으로 읽어봅니다.
$ vault kv get -mount=secret hello
== Secret Path ==
secret/data/hello
======= Metadata =======
Key Value
--- -----
created_time 2024-06-23T06:57:10.424550787Z
custom_metadata <nil>
deletion_time n/a
destroyed false
version 2
====== Data ======
Key Value
--- -----
homework yes
team banana특정 키의 value 값만 읽습니다. 옵션과 명령어 넣을때 순서를 인식합니다.
$ vault kv get -mount=secret hello -field=homework
Command flags must be provided before positional arguments. The following arguments will not be parsed as flags: [-field=homework]
Too many arguments (expected 1, got 2)
$ vault kv get -mount=secret -field=homework hello
yes
이제 AWS 엔진을 활성화 하고 동적 AWS 시크릿을 생성해 봅니다.
동적 비밀은 액세스할 때 생성됩니다. 동적 시크릿은 읽을 때까지 존재하지 않으므로 누군가가 이를 훔치거나 동일한 비밀을 사용하는 다른 클라이언트가 발생할 위험이 없습니다.
Vault에는 취소 메커니즘이 내장되어 있으므로 동적 시크릿은 사용 후 즉시 취소되어 비밀이 존재하는 시간을 최소화할 수 있습니다.
일단 aws 엔진을 다음 명령어로 활성화합니다.
$ vault secrets enable -path=aws aws
Success! Enabled the aws secrets engine at: aws/
이제 AWS 시크릿 엔진을 구성해봅니다.
참고로 STS 페더레이션 토큰을 사용하려는 경우 IAM 역할 자격 증명으로 볼트를 인증할 수 없습니다.
역할과 연결된 임시 보안 자격 증명에는 GetFederationToken을 사용할 권한이 없기 때문입니다.
대안으로 identity token audience 를 사용하는 방법이 있는데 무료 커뮤니티 버전은 지원이 안됩니다.
$ vault write aws/config/root \
identity_token_audience="http://127.0.0.1:8200" \
role_arn="arn:aws:iam::539666729110:role/gepp-demo01-ssm-assume-ec2-role"
Error writing data to aws/config/root: Error making API request.
URL: PUT http://127.0.0.1:8200/v1/aws/config/root
Code: 400. Errors:
* failed to generate plugin identity token: plugin workload identity not supported in Vault community edition
export 한 access key value를 써서 구성해봅니다.
$ vault write aws/config/root \
access_key=$AWS_ACCESS_KEY_ID \
secret_key=$AWS_SECRET_ACCESS_KEY \
region=ap-southeast-1
Success! Data written to: aws/config/root이제 IAM Role을 생성해봅니다. 크레덴셜이 가리키는 유저가 수행할 역할이며 ec2 에 대한 권한을 주었습니다.
$ vault write aws/roles/gepp-vault-demo-test-role \
credential_type=iam_user \
policy_document=-<<EOF
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1426528957000",
"Effect": "Allow",
"Action": [
"ec2:*"
],
"Resource": [
"*"
]
}
]
}
EOF
Success! Data written to: aws/roles/gepp-vault-demo-test-role
확인해 봅니다.
암호화된 access_key, secret_key 정보가 확인됩니다. (실제값과 다른 암호화된 값, 아래는 추가 보안을 위해 임의 스트링 집어넣음)
$ vault read aws/creds/gepp-vault-demo-test-role
Key Value
--- -----
lease_id aws/creds/gepp-vault-demo-test-role/mOw57QlxKdPeZvZAdlxxxxx
lease_duration 768h
lease_renewable true
access_key AKIXABCDABxxxxxxx
secret_key ARABCDABCDABCDABxxxxxxxxx
session_token <nil>이제 액세스 및 비밀 키를 사용하여 AWS 내에서 EC2 작업을 수행할 수 있습니다.
이 키는 위에서 말했듯이 새로운 값이며 이전에 입력한 키가 아닙니다.
명령을 두 번째로 실행하면 또 달라진 새 액세스 키 쌍을 얻게 됩니다.
aws/creds/:name에서 읽을 때마다 Vault는 AWS에 연결하고 새로운 IAM 사용자 및 키 쌍을 생성합니다.
해당 access key로 다시 aws credential 을 export 하고 aws cli를 날리면 자원이 생성됩니다.
즉 실제 값이 아닌 시크릿 값으로 사용할 수 있습니다.
실제로 볼트 시크릿 값으로 명령을 실행해 봅니다.
$ vault read aws/creds/gepp-vault-demo-test-role
Key Value
--- -----
lease_id aws/creds/gepp-vault-demo-test-role/HqC1JKt1F48xvzMrAxxxxxx
lease_duration 768h
lease_renewable true
access_key AKIAX3JVEZCXXXXXXX // <- 임의로 X 로 가림
secret_key oBQHHrE+wfTd6LTQa+80UV7LiHHpdXXXXXXXXXX
session_token <nil>
$ export AWS_ACCESS_KEY_ID=AKIAX3JVEZCLXXXXXXX
$ export AWS_SECRET_ACCESS_KEY=oBQHHrE+wfTd6LTQa+80UV7LiHHpd7gXXXXXXXX
$ aws ec2 run-instances \
> --image-id ami-001f48902dxxxxx \
> --count 1 \
> --key-name gepp-demo01-key \
> --subnet-id subnet-0aedd5xxxxxxx \
> --security-group-ids sg-024ebxxxxxxxx \
> --instance-type t4g.nano
{
"Groups": [],
"Instances": [
{
"AmiLaunchIndex": 0,
"ImageId": "ami-001f489xxxxxxxxx",
"InstanceId": "i-0b00d5xxxxxxxxx",
"InstanceType": "t4g.nano",
"KeyName": "gepp-demo01-key",
"LaunchTime": "2024-06-23T07:45:52+00:00",
"Monitoring": {
"State": "disabled"
},
"Placement": {
"AvailabilityZone": "ap-southeast-1a",
"GroupName": "",
"Tenancy": "default"
},
"PrivateDnsName": "ip-192-168-0-xx.ap-southeast-1.compute.internal",
"PrivateIpAddress": "192.168.0.xx",
"ProductCodes": [],
"PublicDnsName": "",
"State": {
"Code": 0,
"Name": "pending"
},출력에 있는 이 Lease_id 값의 전체 경로를 복사해서 갱신, 해지 및 검사에 사용할 수 있습니다.
시크릿 철회(Revoke)하기
Vault는 768시간 후에 이 사용자 인증 정보를 자동으로 취소하지만(출력의 lease_duration 참조)
조기에 취소하고 싶은 경우,
시크릿을 취소하려면 실행 시 볼트 읽기에서 출력된 임대 ID와 함께 볼트 임대 취소를 수행하면 됩니다.
비밀이 취소되면 해당 시크릿의 액세스 키는 더 이상 유효하지 않습니다.
$ vault lease revoke aws/creds/gepp-vault-demo-test-role/mOw57QlxKdPeZvZAdlxxxxxx
All revocation operations queued successfully!
# 서버 로그
2024-06-23T16:33:59.115+0900 [INFO] expiration: revoked lease: lease_id=aws/creds/gepp-vault-demo-test-role/mOw57QlxKdPeZvZAdlxxxxx위의 취소했던 시크릿의 액세스키 값으로 export 하고 ec2를 다시 생성해봅니다.
임대 취소된 값:
Key Value
--- -----
lease_id aws/creds/cnp-soyip-vault-demo-test-role/mOw57QlxKdPeZvZxxxxx
lease_duration 768h
lease_renewable true
access_key AKIAX3JVEZCLNXXXX. // ← export
secret_key ARVWzrUjYCIcnF/WZFnRAiWrOML+mh6vPXXXXXX
session_token <nil>
$ export AWS_ACCESS_KEY_ID=AKIAX3JVEZCLNPU6XXXX
$ export AWS_SECRET_ACCESS_KEY=ARVWzrUjYCIcnF/WZFnRAiWrOML+mh6vPH7XXXXX
$ aws ec2 run-instances --image-id ami-001f48902dca0ecb9 --count 1 --key-name cnp-soyip-bastion01-key --subnet-id subnet-0aedd591757a7ea1f --security-group-ids sg-024eb29d41a2d037e --instance-type t4g.nano
An error occurred (AuthFailure) when calling the RunInstances operation: AWS was not able to validate the provided access credentials
// 임대 취소되어 해당값으로 생성 불가이외 참고 문서
Vault pricing: https://www.hashicorp.com/products/vault/pricing
Vault Tutorial: https://developer.hashicorp.com/vault/tutorials/getting-started/getting-started-intro
Vault AWS cred: https://developer.hashicorp.com/vault/docs/secrets/aws#assumed_role
'devops > ETC' 카테고리의 다른 글
| 교차 계정 AMP 설정하기 (EKS Prometheus pods to Amazon Managed Prometheus service in Cross Account) (0) | 2024.06.28 |
|---|---|
| Pulumi with a simple demo (0) | 2024.06.23 |
| Istio - service mesh (2) | 2024.06.15 |
| Aqua Security / Trivy (2) | 2024.06.15 |
| Cross Plane 이란 (0) | 2024.06.15 |