26M15d

Young-Kyoo Kim·약 23시간 전

제가 보기엔 지금 필요한 것은 개별 policy를 더 잘 쓰는 방법보다, 버킷/프리픽스 정책을 “상품 카탈로그 + 정책 장부 + GitOps 변경관리”로 운영하는 체계입니다.
즉, 요청이 올 때마다 JSON을 새로 만드는 방식이 아니라, 요청자는 정해진 정책 타입을 선택하고, 운영자는 예외만 심사하는 구조로 바꾸는 것이 좋습니다.

아래는 MinIO AIStor 기준으로 바로 적용 가능한 운영 모델입니다.

1. 먼저 “policy” 범위를 나눠야 함

MinIO AIStor에서 버킷/프리픽스 운영 정책은 크게 5종류로 분리해서 관리하는 것이 좋습니다.

구분	예	관리 단위	운영 장부 필요 여부
Access Policy	read-only, read-write, ingest-only, delete-deny	user/group/service account + bucket/prefix	필수
Lifecycle / ILM	expire 28d, transition 365d, noncurrent expire 90d	bucket/prefix	필수
Replication	bucket replication, prefix replication, batch replication	bucket/prefix	필수
Versioning / Object Lock	versioning enabled, excluded prefixes, WORM	bucket 중심	필수
Anonymous/Public Policy	public read, download-only	bucket/prefix	예외 관리

MinIO AIStor의 access control은 IAM 호환 JSON policy를 사용하는 PBAC 구조이고, mc admin policy로 policy 생성/관리, user/group 연결을 수행합니다. OpenID/OIDC 사용 시 JWT claim의 policy 값을 통해 policy를 매핑할 수 있고, AD/LDAP 사용 시에는 user DN 또는 group DN에 policy를 연결할 수 있습니다. (MinIO AIStor Documentation)

따라서 정책 장부도 단순히 “누가 어느 버킷을 읽을 수 있음” 정도가 아니라, 권한 + ILM + replication + versioning + retention + owner + 만료일 + 승인 이력을 함께 담아야 합니다.

2. 권장 운영 원칙

원칙 1. 버킷은 “용도별 프로파일”로 먼저 분류

첨부 가이드의 Type A/B/C 분류를 정책 체계의 최상위 기준으로 삼는 것이 좋습니다. Type A는 Hot-only + replication 중심의 활성 데이터, Type B는 Hot→Warm ILM 중심의 수명 관리 데이터, Type C는 Warm-only archive로 분류되어 있고, prefix 기반 ILM도 지원되지만 prefix rule의 기간이 기본 bucket rule보다 길면 기본 rule이 먼저 적용될 수 있다는 주의점이 있습니다.

권장 분류는 다음과 같습니다.

Bucket Profile	용도	Versioning	Replication	ILM	Object Lock
`active-dr`	중요 서비스/DR 대상	Enabled	Enabled	transition 없음	선택
`lakehouse-table`	Iceberg/Spark/Trino table	보통 Disabled 또는 제한	요구 시만	app lifecycle과 연계	비권장
`sandbox`	사용자/팀별 실험 공간	Disabled 또는 제한	없음	expire 중심	비권장
`ingest`	외부/앱 업로드 landing	선택	선택	짧은 보존/전환	보통 비권장
`archive-hot-warm`	오래된 데이터 warm 전환	선택	주의	transition 중심	보통 비권장
`warm-tier-target`	Hot ILM remote tier target	Disabled 권장	없음	별도 직접 설정 금지	비권장
`worm-audit`	감사/규제/WORM	Enabled	필요 시	retention 이후	Enabled

특히 replication과 ILM tiering을 같은 bucket에 섞는 경우에는 주의해야 합니다. 첨부 가이드는 tiering 완료 후 Hot에는 data bytes가 없고 stub metadata만 남으며, 이후 replication target에도 stub만 복제될 수 있어 target에서 직접 읽으면 오류가 날 수 있다고 설명합니다.

원칙 2. 프리픽스는 “디렉터리”가 아니라 “정책 경계”로 설계

프리픽스 정책은 반드시 표준 구조를 가져야 합니다.

예를 들어:

s3://lakehouse-prod/
  domain=finance/
    zone=raw/
    zone=curated/
    zone=mart/
  domain=risk/
    zone=raw/
    zone=curated/
  tmp/
  checkpoint/
  archive/

프리픽스는 다음 4가지를 결정하는 단위가 됩니다.

owner
access role
lifecycle
replication 여부

프리픽스 지정 시에는 반드시 trailing slash(/)를 표준으로 삼아야 합니다. 첨부 사례에서도 lsf/가 아니라 lsf처럼 쓰면 lsf_stg 같은 유사 prefix까지 포함될 수 있다고 주의하고 있습니다.

원칙 3. custom policy 생성을 최소화

가장 큰 문제는 요청이 올 때마다 새로운 policy JSON을 만드는 것입니다.
대신 다음처럼 정책 카탈로그를 만들고, 요청자는 카탈로그에서 선택하게 해야 합니다.

Policy Class	이름 예	의미
Access	`ro`	List + Get
Access	`rw-no-delete`	List + Get + Put, Delete 금지
Access	`rw-delete`	List + Get + Put + Delete
Access	`ingest-only`	Put 중심, List/Get 제한
Access	`admin-bucket`	bucket owner 운영 권한
Access	`version-restore`	version 조회/복구 가능
Access	`deny-delete-version`	`DeleteObjectVersion` 금지
ILM	`expire-28d`	28일 후 삭제
ILM	`transition-365d-warm`	365일 후 Warm 이동
ILM	`noncurrent-90d`	non-current version 90일 후 삭제
Replication	`replicate-all`	전체 bucket replication
Replication	`replicate-prefix`	특정 prefix만 replication
Retention	`worm-compliance-365d`	COMPLIANCE 365일

MinIO AIStor는 bucket replication 설정 시 prefix/tag 기반 object filter를 둘 수 있고, mc replicate add는 bucket 또는 bucket prefix 경로에 replication rule을 생성할 수 있습니다. 또한 server-side bucket replication은 AIStor↔AIStor 간에 동작하며, 다른 S3-compatible 대상에는 batch/mirror 계열 접근이 필요합니다. (MinIO AIStor Documentation)

3. 정책 장부는 “엑셀”보다 YAML/CSV + Git이 좋음

처음에는 Excel로 시작해도 되지만, 운영 반영은 Git 기준으로 하는 것이 좋습니다.
권장 구조는 다음과 같습니다.

aistor-policy-registry/
  README.md

  catalogs/
    access-profiles.yaml
    ilm-profiles.yaml
    replication-profiles.yaml
    bucket-profiles.yaml
    exception-rules.yaml

  buckets/
    prod/
      lakehouse-prod.yaml
      sandbox-prod.yaml
      audit-prod.yaml
    dev/
      lakehouse-dev.yaml

  policies/
    rendered/
      prod/
        p-prod-lakehouse-finance-curated-ro.json
        p-prod-lakehouse-finance-curated-rw-no-delete.json

  bindings/
    oidc-keycloak/
      prod-group-policy-bindings.yaml
    ldap/
      prod-ldap-policy-bindings.yaml
    service-accounts/
      prod-service-accounts.yaml

  jobs/
    ilm/
      prod-lakehouse-prod.yaml
    replication/
      prod-lakehouse-prod.yaml

  audit/
    snapshots/
      2026-05-14/
        policies.txt
        policy-entities.txt
        ilm-rules.txt
        replication-rules.txt
        versioning.txt

핵심은 source of truth를 Git으로 고정하고, MinIO Console이나 CLI에서 직접 바꾼 값은 “drift”로 감지하는 것입니다.

4. 정책 장부 필드 예시

아래 정도는 반드시 장부에 들어가야 합니다.

apiVersion: aistor.policy/v1
kind: BucketPolicyRegistry
metadata:
  env: prod
  cluster: aistor-hot-prod
  bucket: lakehouse-prod
  ownerTeam: data-platform
  dataOwner: finance-data-owner
  businessService: cloud-native-lakehouse
  ticket: REQ-2026-00123
  createdAt: "2026-05-14"
  reviewCycle: quarterly

bucketProfile:
  type: lakehouse-table
  tier: hot
  versioning: disabled
  objectLock: disabled
  encryption: sse-kms
  replicationProfile: none
  ilmProfile: none

prefixes:
  - prefix: domain=finance/zone=raw/
    ownerTeam: finance-analytics
    dataClass: internal
    workload: spark-iceberg
    access:
      - principalType: oidc-group
        principal: kc-aistor-prod-finance-raw-ro
        profile: ro
        policyName: p-prod-lakehouse-finance-raw-ro
      - principalType: service-account
        principal: spark-finance-prod
        profile: rw-no-delete
        policyName: p-prod-lakehouse-finance-raw-rw-no-delete
    ilm:
      profile: expire-365d
    replication:
      profile: none
    notes: "Iceberg table path. Object Lock 금지. 임의 expire 금지."

  - prefix: tmp/
    ownerTeam: data-platform
    dataClass: transient
    access:
      - principalType: oidc-group
        principal: kc-aistor-prod-platform-admin
        profile: rw-delete
    ilm:
      profile: expire-7d
    versioningOverride: excluded

이 장부 하나에서 다음을 생성할 수 있어야 합니다.

1. IAM JSON policy
2. mc admin policy create/update 명령
3. Keycloak/OIDC 또는 LDAP group mapping 문서
4. mc ilm rule add 명령
5. mc replicate add 명령
6. 운영자용 정책 현황표
7. drift audit 기준

5. Access Policy 표준 템플릿

5-1. prefix read-only

MinIO AIStor의 s3:ListBucket은 s3:prefix condition을 지원하고, object 접근은 arn:aws:s3:::bucket/prefix/* 형태로 제한할 수 있습니다. 공식 문서에도 OIDC/LDAP 변수 기반 prefix 제한 예시가 있으며, wildcard가 의도치 않게 여러 bucket/prefix에 매칭될 수 있다고 경고합니다. (MinIO AIStor Documentation)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListOnlyTargetPrefix",
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::lakehouse-prod"
      ],
      "Condition": {
        "StringLike": {
          "s3:prefix": [
            "domain=finance/zone=curated/*"
          ]
        }
      }
    },
    {
      "Sid": "ReadObjectsInTargetPrefix",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject"
      ],
      "Resource": [
        "arn:aws:s3:::lakehouse-prod/domain=finance/zone=curated/*"
      ]
    }
  ]
}

5-2. prefix read-write, delete 금지

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListOnlyTargetPrefix",
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:ListBucketMultipartUploads"
      ],
      "Resource": [
        "arn:aws:s3:::lakehouse-prod"
      ],
      "Condition": {
        "StringLike": {
          "s3:prefix": [
            "domain=finance/zone=raw/*"
          ]
        }
      }
    },
    {
      "Sid": "ReadWriteObjectsInTargetPrefix",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:AbortMultipartUpload",
        "s3:ListMultipartUploadParts"
      ],
      "Resource": [
        "arn:aws:s3:::lakehouse-prod/domain=finance/zone=raw/*"
      ]
    },
    {
      "Sid": "DenyDeletes",
      "Effect": "Deny",
      "Action": [
        "s3:DeleteObject",
        "s3:DeleteObjectVersion"
      ],
      "Resource": [
        "arn:aws:s3:::lakehouse-prod/domain=finance/zone=raw/*"
      ]
    }
  ]
}

Multipart upload를 쓰는 Spark, Iceberg, 대용량 업로드 앱은 AbortMultipartUpload, ListMultipartUploadParts, ListBucketMultipartUploads 같은 action이 필요할 수 있으므로 access profile에 별도로 포함시키는 것이 좋습니다. MinIO AIStor access policy 문서는 multipart 관련 action을 별도 action으로 정의합니다. (MinIO AIStor Documentation)

5-3. versioned bucket에서 versionId 영구 삭제 금지

첨부 고객사 D 사례처럼, versioning은 켜되 versionId를 지정한 영구 삭제를 막고 싶다면 s3:DeleteObjectVersion을 명시적으로 deny하는 profile을 표준화할 수 있습니다. 해당 사례에서도 Object Lock compliance 대신 IAM Policy로 DeleteObjectVersion을 차단하는 방식이 사용되었습니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyDeleteObjectVersion",
      "Effect": "Deny",
      "Action": [
        "s3:DeleteObjectVersion"
      ],
      "Resource": [
        "arn:aws:s3:::important-bucket/*"
      ]
    }
  ]
}

이 profile은 active-dr, video-vault, audit 계열 bucket에는 유용하지만, Iceberg/Spark 임시 경로나 고변경 workload에는 신중히 적용해야 합니다.

6. Keycloak/OIDC, LDAP 연결 방식

사용자별로 MinIO policy를 직접 붙이는 방식은 금방 관리가 깨집니다.
권장 구조는 다음입니다.

Keycloak Group / LDAP Group
        ↓
표준 MinIO Policy Name
        ↓
bucket/prefix access

예시:

IdP Group	MinIO Policy	Scope
`kc-aistor-prod-finance-raw-ro`	`p-prod-lakehouse-finance-raw-ro`	`lakehouse-prod/domain=finance/zone=raw/`
`kc-aistor-prod-finance-raw-rw`	`p-prod-lakehouse-finance-raw-rw-no-delete`	같은 prefix
`kc-aistor-prod-platform-admin`	`p-prod-platform-bucket-admin`	운영 bucket
`kc-aistor-prod-audit-ro`	`p-prod-audit-ro`	audit bucket

Keycloak을 OIDC provider로 사용할 경우 MinIO AIStor는 JWT claim을 통해 어떤 policy를 부여할지 판단할 수 있고, Keycloak 가이드에서는 policy user attribute와 token claim mapping을 구성하는 방식을 설명합니다. AD/LDAP의 경우에는 user DN 또는 group DN에 policy를 연결하며, group query가 구성되면 사용자의 group membership에 따라 policy가 부여됩니다. (MinIO AIStor Documentation)

7. Lifecycle/ILM 정책도 Access Policy와 같이 장부화

Access policy만 체계화하고 ILM을 따로 관리하면 다시 주먹구구식이 됩니다.
ILM도 반드시 profile화해야 합니다.

ILM Profile	적용 대상	예
`none`	Iceberg active table 등	ILM 없음
`expire-7d`	tmp, staging, failed job output	7일 후 삭제
`expire-28d`	로그/임시 분석 산출물	28일 후 삭제
`transition-90d-warm`	archive prefix	90일 후 Warm tier
`transition-365d-warm`	장기 보관 데이터	365일 후 Warm tier
`noncurrent-90d`	versioning bucket	non-current 90일 후 삭제
`noncurrent-keep-3`	checkpoint/version 보존	최신 3개 non-current만 유지
`delete-marker-purge`	Iceberg vacuum 후 정리	topmost delete marker 정리

공식 문서상 MinIO AIStor Lifecycle Management는 시간/날짜 기반 object transition 또는 expiry rule을 만들 수 있고, transition은 remote tier로 이동, expiry는 object 삭제를 수행합니다. 또한 같은 bucket 또는 prefix에 expiry와 transition rule을 함께 둘 수 있으므로, 충돌 가능성을 mc ilm rule ls로 확인해야 합니다. (MinIO AIStor Documentation)

첨부 사례에서는 Iceberg vacuum 후 delete marker와 non-current version이 누적되는 문제가 있었고, Object Lock 없는 bucket에서는 --purge-all-object-versions-days와 --purge-all-object-versions-delete-marker 조합을 사용했으며, Object Lock bucket에서는 ILM 제약 때문에 Batch Expiry를 사용했습니다.

8. Versioning/Object Lock은 “요청자가 선택”하게 하면 안 됨

Versioning과 Object Lock은 운영 영향이 크므로 요청자가 임의로 선택하게 하면 안 됩니다.

첨부 가이드에 따르면 versioning이 활성화된 상태에서 object를 삭제하면 실제 데이터가 바로 삭제되지 않고 delete marker만 기록되며, noncurrent version 정리 rule이 없으면 데이터와 이전 version이 남습니다. 또한 version 수가 많아지면 metadata, scanner, LIST, healing 부담이 증가합니다.

따라서 장부에 다음 규칙을 강제해야 합니다.

조건	강제 규칙
Versioning enabled	반드시 non-current cleanup profile 필요
Replication enabled	versioning 영향 및 cleanup rule 검토
Iceberg/Spark table	기본적으로 Object Lock 금지
tmp/log/cache prefix	versioning excluded prefix 권장
Object Lock enabled	별도 bucket 생성 승인 필요
WORM bucket	retention owner, legal hold 담당자 필수
Warm tier target	app 직접 접근 policy 금지

첨부 가이드도 변경이 잦은 tmp/, logs/, cache/ prefix는 versioning 제외 대상으로 두고, versioning을 켰다면 --noncurrent-expire-newer 또는 --noncurrent-expire-days 같은 정리 rule을 반드시 함께 설정하라고 설명합니다.

9. 정책 요청서를 표준화

요청자는 아래 양식만 제출하게 만드는 것이 좋습니다.

request:
  requester: hong.gildong
  team: finance-analytics
  ticket: REQ-2026-00123
  env: prod
  purpose: "Spark job에서 finance raw data read/write"
  duration: permanent
  expiryDate: null

target:
  bucket: lakehouse-prod
  prefix: domain=finance/zone=raw/
  dataClass: internal
  workload: spark-iceberg

access:
  principalType: oidc-group
  principal: kc-aistor-prod-finance-raw-rw
  requestedProfile: rw-no-delete
  needDelete: false
  needList: true
  needMultipart: true

lifecycle:
  requestedProfile: none
  reason: "Iceberg table path. App lifecycle에서 관리."

replication:
  requestedProfile: none
  needDRRead: false

versioning:
  required: false

objectLock:
  required: false

approval:
  dataOwner: finance-data-owner
  securityReviewer: security-team
  storageReviewer: object-storage-team

요청서에서 가장 중요한 필드는 needDelete, needMultipart, workload, lifecycle, replication, versioning, objectLock입니다.
이 값으로 자동 검증을 돌릴 수 있습니다.

10. GitOps 반영 절차

권장 절차는 다음입니다.

1. 요청 접수
2. bucket/prefix 장부에 신규 entry 추가
3. 표준 profile 선택
4. CI에서 정책 검증
5. 보안/데이터오너/스토리지오너 승인
6. MinIO policy JSON render
7. mc로 dev/stage 적용
8. smoke test
9. prod 적용
10. 적용 결과 snapshot 저장
11. 주기적 drift check

반영 명령 예시는 다음과 같습니다.

# policy 생성 또는 갱신
mc admin policy create aistor-prod \
  p-prod-lakehouse-finance-raw-rw-no-delete \
  policies/rendered/prod/p-prod-lakehouse-finance-raw-rw-no-delete.json

# MinIO managed group에 연결하는 경우
mc admin policy attach aistor-prod \
  p-prod-lakehouse-finance-raw-rw-no-delete \
  --group finance-raw-rw

# LDAP group에 연결하는 경우
mc idp ldap policy attach aistor-prod \
  p-prod-lakehouse-finance-raw-rw-no-delete \
  --group 'cn=finance-raw-rw,ou=groups,dc=example,dc=com'

mc admin policy attach는 MinIO-managed user/group용이고, OIDC 사용자는 OIDC access management, AD/LDAP 사용자는 mc idp ldap policy attach를 사용해야 합니다. (MinIO AIStor Documentation)

11. CI 검증 규칙

정책이 Git에 올라오면 최소한 아래 검증을 자동으로 돌리면 좋습니다.

검증 항목	실패 조건
Prefix 형식	`/`로 끝나지 않는 prefix
Wildcard	`arn:aws:s3:::`, `bucket` 사용
Delete 권한	`rw-no-delete` profile인데 `DeleteObject` 포함
Versioning	versioning enabled인데 noncurrent cleanup 없음
Object Lock	lakehouse/tmp/sandbox bucket에 objectLock 요청
ILM	Iceberg table path에 단순 age-based expire 적용
ILM 충돌	bucket default transition 30d, prefix transition 365d
Replication + ILM	DR direct read 필요인데 transition rule 있음
Warm target	app access policy 또는 anonymous policy 존재
Public access	anonymous policy가 예외 승인 없이 존재
Principal	Keycloak/LDAP group naming rule 위반
만료일	임시 권한인데 expiryDate 없음

공식 문서는 * wildcard가 의도치 않게 여러 bucket/prefix에 적용될 수 있고, data* 같은 resource pattern이 data, data_private, data_internal까지 매칭될 수 있다고 경고합니다. 따라서 wildcard는 CI에서 강하게 막는 것이 좋습니다. (MinIO AIStor Documentation)

12. 운영 중 drift check

주기적으로 MinIO 실제 상태를 긁어서 Git 장부와 비교해야 합니다.

# 전체 policy 목록
mc admin policy ls aistor-prod

# 특정 policy에 연결된 user/group 확인
mc admin policy entities aistor-prod p-prod-lakehouse-finance-raw-ro

# LDAP mapping 확인
mc idp ldap policy entities aistor-prod

# anonymous/public policy 확인
mc anonymous list aistor-prod/lakehouse-prod

# ILM rule 확인
mc ilm rule ls aistor-prod/lakehouse-prod

# versioning 확인
mc version info aistor-prod/lakehouse-prod

# replication rule 확인
mc replicate ls aistor-prod/lakehouse-prod
mc replicate status aistor-prod/lakehouse-prod
mc replicate backlog aistor-prod/lakehouse-prod

MinIO AIStor 공식 문서도 mc admin policy ls로 policy 목록을 조회하고, mc admin policy entities로 policy에 연결된 user/group을 확인할 수 있다고 설명합니다. LDAP/AD 구성의 entity 확인은 LDAP 전용 command를 사용해야 합니다. (MinIO AIStor Documentation)

drift check 결과는 다음처럼 분류하면 됩니다.

Drift 유형	조치
Git에는 있는데 MinIO에 없음	apply 누락, 재적용
MinIO에는 있는데 Git에 없음	비인가 변경, 회수 또는 장부 등록
policy JSON 불일치	승인 없는 변경 여부 확인
group binding 불일치	IdP/LDAP mapping 검토
ILM rule 불일치	데이터 삭제 위험 검토 후 수정
replication rule 불일치	DR 영향 검토

13. 2-tier 환경에서 반드시 넣어야 할 예외 규칙

현재 Hot/Warm 2-tier 구성을 고려하면 아래 규칙은 장부와 CI에 반드시 들어가야 합니다.

13-1. DR direct-read bucket에는 ILM transition 금지

if bucket.replication.enabled == true
and bucket.drDirectReadRequired == true
then ilm.transition == forbidden

이유는 앞서 말한 stub-only replication 문제 때문입니다. 첨부 가이드는 transition 후 replication target에 실제 data가 아니라 xl.meta stub만 복제될 수 있고, target이 Warm tier에 접근할 수 없으면 GetObject 오류가 발생한다고 설명합니다.

13-2. Replication + ILM Expiry 조합에는 `edge-sync-before-expiry` 확인

if replication.enabled == true
and ilm.expiry.enabled == true
then replication.edgeSyncBeforeExpiry == true

첨부 가이드에 따르면 ILM expiry와 replication이 함께 있을 때 replication 완료 전에 expiry가 먼저 실행되는 race condition이 생길 수 있고, EdgeSyncBeforeExpiry=true로 replication 완료 전 삭제를 보류하는 패턴이 권장됩니다.

13-3. Warm tier target bucket에는 app access 금지

if bucket.profile == warm-tier-target
then access.appPolicies == forbidden
and anonymous == forbidden
and lifecycle.directRule == forbidden

Warm target은 Hot AIStor의 ILM remote tier target이지, 일반 app이 직접 쓰는 archive bucket이 아닙니다. mc ilm tier add 예시에서도 remote tier는 target bucket과 prefix, 그리고 해당 bucket/prefix에 대한 read/write/list/delete 권한을 가진 credential로 구성됩니다. (MinIO AIStor Documentation)

14. 운영 조직/RACI

정책 장부를 유지하려면 역할을 분리해야 합니다.

역할	책임
Requester	요청 목적, bucket/prefix, 필요 권한 제출
Data Owner	데이터 접근 승인
App Owner	workload 특성 설명, delete/list/multipart 필요 여부 확인
Security	public, delete, object lock, cross-domain access 검토
Storage Owner	MinIO policy/ILM/replication 적용
Platform Owner	GitOps pipeline, drift detection 운영
Compliance/Legal	WORM, retention, legal hold 승인

특히 DeleteObject, DeleteObjectVersion, PutBucketPolicy, PutBucketVersioning, PutObjectRetention, BypassGovernanceRetention, ReplicateDelete 같은 권한은 일반 access profile에 넣지 말고 별도 승인 profile로 관리하는 것이 좋습니다. MinIO AIStor policy 문서도 versioning/retention, lifecycle, replication 관련 action을 일반 object read/write와 별도 action으로 정의합니다. (MinIO AIStor Documentation)

15. 추천 운영 모델 요약

최종 구조는 이렇게 잡는 것이 좋습니다.

[요청자]
  "finance raw prefix에 Spark RW 권한 필요"

        ↓

[정책 요청서]
  bucket = lakehouse-prod
  prefix = domain=finance/zone=raw/
  profile = rw-no-delete
  workload = spark-iceberg
  lifecycle = none
  delete = false
  multipart = true

        ↓

[정책 장부 Git PR]
  buckets/prod/lakehouse-prod.yaml 수정

        ↓

[CI 검증]
  prefix slash 확인
  wildcard 금지
  delete 금지 확인
  Iceberg path ILM expire 금지
  versioning/object lock 충돌 확인

        ↓

[승인]
  data owner + security + storage owner

        ↓

[자동 생성]
  IAM JSON policy
  mc admin policy create
  Keycloak/LDAP binding
  ILM/replication command

        ↓

[적용 후 snapshot]
  mc admin policy ls
  mc admin policy entities
  mc ilm rule ls
  mc replicate ls
  mc version info

        ↓

[주기적 drift check]
  Git 장부와 MinIO 실제 상태 비교

가장 현실적인 시작점은 아래 3가지를 먼저 만드는 것입니다.

Bucket/Profile 장부
active-dr, lakehouse-table, sandbox, archive-hot-warm, warm-tier-target, worm-audit 같은 bucket 유형 정의
Access Profile 카탈로그
ro, rw-no-delete, rw-delete, ingest-only, version-restore, deny-delete-version, bucket-admin
Prefix Registry
각 prefix별 owner, principal, access profile, ILM profile, replication profile, 만료일, 승인 ticket 기록

이렇게 해두면 신규 요청이 와도 “새 policy를 만들 것인가?”가 아니라 “어느 표준 profile을 어느 prefix에 붙일 것인가?”로 바뀝니다. 그러면 운영 일관성, 감사 대응, 장애 분석, 권한 회수, ILM/replication 영향 분석이 훨씬 쉬워집니다.

Young-Kyoo Kim

engineer

이전 포스트

26M15c

다음 포스트

26M15d

1. 먼저 “policy” 범위를 나눠야 함

2. 권장 운영 원칙

원칙 1. 버킷은 “용도별 프로파일”로 먼저 분류

원칙 2. 프리픽스는 “디렉터리”가 아니라 “정책 경계”로 설계

원칙 3. custom policy 생성을 최소화

3. 정책 장부는 “엑셀”보다 YAML/CSV + Git이 좋음

4. 정책 장부 필드 예시

5. Access Policy 표준 템플릿

5-1. prefix read-only

5-2. prefix read-write, delete 금지

5-3. versioned bucket에서 versionId 영구 삭제 금지

6. Keycloak/OIDC, LDAP 연결 방식

7. Lifecycle/ILM 정책도 Access Policy와 같이 장부화

8. Versioning/Object Lock은 “요청자가 선택”하게 하면 안 됨

9. 정책 요청서를 표준화

10. GitOps 반영 절차

11. CI 검증 규칙

12. 운영 중 drift check

13. 2-tier 환경에서 반드시 넣어야 할 예외 규칙

13-1. DR direct-read bucket에는 ILM transition 금지

13-2. Replication + ILM Expiry 조합에는 `edge-sync-before-expiry` 확인

13-3. Warm tier target bucket에는 app access 금지

14. 운영 조직/RACI

15. 추천 운영 모델 요약

26M15c

26M15e

0개의 댓글

26M15d

1. 먼저 “policy” 범위를 나눠야 함

2. 권장 운영 원칙

원칙 1. 버킷은 “용도별 프로파일”로 먼저 분류

원칙 2. 프리픽스는 “디렉터리”가 아니라 “정책 경계”로 설계

원칙 3. custom policy 생성을 최소화

3. 정책 장부는 “엑셀”보다 YAML/CSV + Git이 좋음

4. 정책 장부 필드 예시

5. Access Policy 표준 템플릿

5-1. prefix read-only

5-2. prefix read-write, delete 금지

5-3. versioned bucket에서 versionId 영구 삭제 금지

6. Keycloak/OIDC, LDAP 연결 방식

7. Lifecycle/ILM 정책도 Access Policy와 같이 장부화

8. Versioning/Object Lock은 “요청자가 선택”하게 하면 안 됨

9. 정책 요청서를 표준화

10. GitOps 반영 절차

11. CI 검증 규칙

12. 운영 중 drift check

13. 2-tier 환경에서 반드시 넣어야 할 예외 규칙

13-1. DR direct-read bucket에는 ILM transition 금지

13-2. Replication + ILM Expiry 조합에는 edge-sync-before-expiry 확인

13-3. Warm tier target bucket에는 app access 금지

14. 운영 조직/RACI

15. 추천 운영 모델 요약

26M15c

26M15e

0개의 댓글

13-2. Replication + ILM Expiry 조합에는 `edge-sync-before-expiry` 확인