☰

선택기를 충족하는 개체로 역할을 제한할 수 있나요?

tag-icon • tag-icon kubernetes authorization
선택기를 충족하는 개체로 역할을 제한할 수 있나요?

특정 네임스페이스 내에서 특정 라벨이 있는 객체만 생성, 나열, 삭제 등의 작업을 수행할 수 있도록 서비스 계정을 어떻게 제한할 수 있나요?

우리는 서비스(kubernetes 네임스페이스에 매핑) 및 구성 요소( persona다양한 객체의 레이블로 표시)의 계층 구조를 설계했으며, 귀하가 액세스할 수 있는 비밀이 서비스에 특정하도록 Vault와 통합했습니다. 구성 요소 쌍. 이는 사물을 분리하는 데 도움이 됩니다. 예를 들어, 여러 배포를 관리하고 그 중 일부만 PII 데이터를 처리하는 팀을 상상해 보세요. 해당 레이블을 사용하여 해당 비밀에 대한 액세스 권한을 선택적으로 부여할 수 있습니다.

# only approximatively k8s objects
---
kind: Deployment
metadata:
  name: backend
  namespace: banana
  labels:
    persona: backend
spec: ...
# pods in this deployment have access to banana§backend secrets via a vault sidecar
---
kind: Deployment
metadata:
  name: frontend
  labels:
    persona: frontend
spec: ...
# pods in this deployment have access to banana§frontend secrets via a vault sidecar

하지만 이는 단지 관리할 수 있는 서비스 계정을 만들고 싶지 않다는 의미입니다.모두해당 네임스페이스의 포드 — 해당 서비스 계정의 비밀이 유출되면 공격자는 이를 사용하여 악성 이미지로 포드를 시작하고 PII에 액세스할 수 있습니다.

그래서 나는 다음과 같은 것을 갖고 싶습니다. (서비스 계정, 역할 및 역할 바인딩에 대한 나의 지식은 극히 제한되어 있습니다.)

# even more approximatively so k8s objects
kind: Role
metadata:
  name: deploy-frontend
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
  selector:
    labels:
      persona: frontend
# even if compromised, this service account cannot access banana§backend secrets

k8s 같은데~할 것 같다예를 들어 특정 리소스 이름 목록을 제공하여 이와 같은 모호한 것을 지원합니다(#), 그러나 이것은 현재 k8s가 지원하는 것이 아니라는 것입니까? 아니면 내가 뭔가를 놓치고 있는 걸까?

우리의 유일한 대안은 모든 것에 폭넓게 액세스할 수 있는 클러스터 전체 서비스 계정을 설정한 다음 토큰이 사용되기 전에 자체 사용자 정의 인증 및 권한 부여 루틴을 수행하는 웹 서비스를 실행하는 것입니까? 그렇다면 어떻게 하면 이 "신 계정"의 범위를 최대한 제한할 수 있을까요?

답변1

Kubernetes에는목록객체별로 동사. 컬렉션을 나열할 수 있으면 해당 컬렉션의 모든 개체를 읽을 수 있습니다.

언젠가는 바뀔 수도 있지만 지금 당장은 컬렉션 및 읽기 액세스 측면에서 Kubernetes가 작동하는 방식입니다. 여기에는 비밀에 대한 읽기 액세스가 포함됩니다.

그러나 제한하고 싶다면쓴다객체에 그렇게 할 수 있습니다. 다음을 사용하여 특정 명명된 개체에 쓰기 기능을 제한할 수 있습니다.

  • 외부 검증 승인 웹훅
  • (베타) ValidatingAdmissionPolicy
  • 인증 웹훅

또는 신중하게 만들어진 RBAC 규칙을 사용합니다.

액세스를 관리하는 데 도움이 될 수 있는 것은계층적 네임스페이스 컨트롤러, 팀이 관리할 수 있도록 허용세트각각 고유한 제한 사항이 있는 네임스페이스입니다. 클러스터가 ValidatingAdmissionPolicies를 지원하는 경우 이를 사용하여 쓰기 액세스에 대한 액세스 및 제한을 추가로 위임할 수 있습니다(아주 복잡한 주제임).

작업을 수행할 수 있는 하나의 ServiceAccount를 갖고 싶지만 이러한 작업에 대한 제어를 위임하려는 경우 RoleBinding을 사용하여 각 대상 네임스페이스에 ServiceAccount를 만든 다음 전체 ServiceAccount가 특정 ServiceAccount를 가장하도록 허용할 수 있습니다. 다시 말하지만, 이는 다루기가 상당히 복잡한 일이지만 가능합니다.

관련 정보