입학 컨트롤러 코드는 https://github.com/kubernetes/kubernetes/pull/24600 에서 검토 중입니다.

이 기능은 OpenShift에서 처음 노출되었기 때문에 베타로 바로 건너뜁니다.

kubernetes/kubernetes#24600에서는 기본적으로 비활성화됩니다. 그런 다음 PSP를 사용자에게 연결하기 위해 승인 컨트롤러를 변경해야 합니다.

https://github.com/kubernetes/kubernetes/pull/20573 을 PSP(주제 수준 액세스)의 다음 단계에 대한 종속성으로 표시

이 상태는? 첫 번째 댓글의 설명이 최신 정보입니까?

첫 번째 댓글의 설명이 최신 정보입니까?

아니요(업데이트 권한이 없습니다). 모든 알파 요구 사항이 충족되었다고 생각합니다. 초기 유형, API 및 테스트가 병합되었습니다. 승인 컨트롤러는 기본적으로 활성화되어 있지 않습니다.

IMO 베타/1.4에 대한 나머지 작업은 권한에 대한 인증 통합, 제한하려는 새 필드(seccomp - 진행 중, sysctl) 및 필요한 문서/자습서에 대한 업데이트입니다.

그리고 e2 테스트.

2016년 7월 12일 화요일 오전 6시 23분에 Paul Weil [email protected] 은 다음과 같이 썼습니다.

첫 번째 댓글의 설명이 최신 정보입니까?

아니요(업데이트 권한이 없습니다). 나는 모든 알파를 믿는다
요구 사항이 충족되었습니다. 초기 유형, API 및 테스트는 다음과 같습니다.
병합. 승인 컨트롤러는 기본적으로 활성화되어 있지 않습니다.

IMO 베타/1.4에 대한 나머지 작업은 권한에 대한 인증 통합입니다.
제한하려는 새 필드에 대한 업데이트(seccomp - 진행 중,
sysctl) 및 필요한 모든 문서/자습서.

—
스레드를 작성했기 때문에 이 메시지를 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/kubernetes/features/issues/5#issuecomment -232045429,
또는 스레드 음소거
https://github.com/notifications/unsubscribe/AHuudqFwephlYk0Y1PS77y0xxA5QW0_-ks5qU5U7gaJpZM4IaU8n
.

클라우드 공급자와의 상호 작용은 어떻습니까? 실제로 필요한 클라우드 서비스의 하위 집합에만 액세스할 수 있도록 각 포드에 서로 다른 IAM 역할을 쉽게 할당하는 것이 좋을 것입니다. 범위 내에 있습니까? 아니면 SecurityContext 세부 정보로 간주됩니까?

@therc 는 ServiceAccount를 통해 수행해야 합니다.

@goltermann 나는 이것이 알파로 표시되어 있음을 알았지 만 https://github.com/kubernetes/features/issues/5#issuecomment -217939650을 기반으로 한 베타 태그가 필요할 것이라고 생각합니다.

@erictune 은 @pweil- comment를 기반으로 베타 사운드가 제대로 들리나요?

@goltermann 기술적으로 이것은 1.3에서 베타였을 것이라고 생각합니다. 개발이 진행 중이지만 1.4에서는 새로운 것이 아닙니다.

네, 베타가 맞습니다. 제가 오늘 일찍 알파라고 했을 때 틀렸습니다.

좋아, 고쳤어

@pweil- 문서가 준비되었습니까? 문서를 https://github.com/kubernetes/kubernetes.github.io 로 업데이트한 다음 PR 번호를 추가하고 문제 설명에서 문서 상자를 선택하십시오.

@janetkuo 문서 홍보 https://github.com/kubernetes/kubernetes.github.io/pull/1150

편집: https://github.com/kubernetes/kubernetes.github.io/pull/1206 이 올바른 1.4 PR입니다.

cc @kubernetes/feature-reviewers

@pweil- 이 PR은 실제라고 생각합니다 - https://github.com/kubernetes/kubernetes.github.io/pull/1206?

옳은

90일 동안 사용하지 않으면 문제가 부실해집니다.
/remove-lifecycle stale 를 사용하여 문제를 최신으로 표시합니다.
부실 문제는 추가로 30일 동안 사용하지 않으면 썩고 결국 닫힙니다.

/lifecycle frozen 주석으로 이슈가 자동으로 닫히지 않도록 합니다.

이 문제를 지금 종료해도 안전하다면 /close 로 종료하십시오.

sig-testing, kubernetes/test-infra 및/또는 @fejta 에 피드백을 보내십시오.
/수명 주기 부실

1.10에서 PSP를 비확장 API 그룹으로 이동하는 작업이 진행 중입니다.
cc @php-coder

@erictune 문서 업데이트 부탁드립니다. [1.10 기능 추적 스프레드시트[(https://docs.google.com/spreadsheets/d/17bZrKTk8dOx5nomLrD1-93uBfajK5JS-v1o-nCLJmzE/edit#gid=0)]도 참조하세요. 질문이 있으시면 lmk. 3/9까지 문서 PR을 검토하고 병합해야 합니다. 감사 해요!

@php-coder ^^

@Bradamant3 @liggitt 어떤 문서 업데이트가 필요합니까?

API 그룹 전환과 관련된 변경 사항에 대해서는 https://github.com/kubernetes/website/pull/7562 , https://github.com/kubernetes/examples/pull/206 및 https://github.com/kubernetes/examples/pull/206 을 제출했습니다 . /github.com/kubernetes/examples/pull/208

저는 PSP Doc 업데이트의 올바른 소유자가 아닙니다.

2018년 3월 2일(금) 오전 11:26 Vyacheslav Semushin <
[email protected]>은 다음과 같이 썼습니다.

@Bradamant3 https://github.com/bradamant3 @liggitt
https://github.com/liggitt 어떤 문서 업데이트가 필요합니까?

API 그룹 전환과 관련된 변경 사항에 대해 다음을 제출했습니다.
쿠버네티스/웹사이트#7562 https://github.com/kubernetes/website/pull/7562 ,
쿠버네티스/예제#206 https://github.com/kubernetes/examples/pull/206 ,
및 kubernetes/examples#208
https://github.com/kubernetes/examples/pull/208

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/kubernetes/features/issues/5#issuecomment-370026485 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AHuudtBCup17Kt91pqJzBRpKWStoXUt-ks5taZzcgaJpZM4IaU8n
.

그게 우리에게 필요한 전부입니다. 추적 스프레드시트에 PR을 추가했습니다. 감사 해요!

@php-coder @liggitt @tallclair
1.11에서 이에 대한 계획이 있습니까?

그렇다면 해당 기능이 최신 상태인지 확인할 수 있습니까?

• 설명
• 중요한 단계
• 양수인
• 라벨:
  
  
  
  • stage/{alpha,beta,stable}
  
  
  • sig/*
  
  
  • kind/feature
  
  

cc @idvoretskyi

@php-coder 여기에서 하고 있는 작업으로 @justaugustus 의 의견에 응답할 수 있습니까? 정책 그룹 이동 외에 변경된 사항이 있나요?

정책 그룹 이동 외에 변경된 사항이 있나요?

아니요, 이것만 작업했습니다.

@liggitt 가 시간이 있을 때 설명을 업데이트하기를 바랍니다(나는 적절한 권한이 없기 때문에).

완료.

@tallclair 를 명확히 하기 위해 1.11의 대상으로 안정적으로 추적하고 있습니다. 맞습니까?
레이블을 업데이트했지만 확인하려는 것뿐입니다.

아니요, 아직 베타 버전입니다. PodSecurityPolicy가 안정적으로 전환될지(즉, 다른 것으로 대체될지) 확신할 수 없지만 다른 사람들은 이에 대해 동의하지 않을 수 있습니다.

알았어요. 업데이트해주셔서 감사합니다, @tallclair!

@justaugustus 1.11 이정표에서 제거하겠습니다. 현재 릴리스에서는 큰 진전이 없을 것이기 때문입니다.

1.12 업데이트 예정 없음

@tallclair 1.12에서 RunAsGroup PSP 손잡이를 얻을 수 있습니다.

확인. 이것은 아직 베타 버전일 것입니다. 현재로서는 PSP가 GA로 이동할 계획이 없습니다. 이 작업을 진행하기 전에 해결해야 하는 몇 가지 주요 사용성 문제가 있습니다. (https://github.com/kubernetes/kubernetes/issues/60001 및 https://github.com/kubernetes/kubernetes/issues/56174 참조)

/할당 해제

/할당 @tallclair

안녕
이 개선 사항은 이전에 추적되었으므로 Kubernetes 1.13의 졸업 단계에 대한 계획이 있는지 확인하고 확인하고 싶습니다. 이 릴리스는 더 '안정적'인 것을 목표로 하며 공격적인 일정을 갖습니다. 다음 마감일을 충족할 것이라고 확신하는 경우에만 이 개선 사항을 포함하십시오.

• 문서(열린 자리 표시자 PR): 11/8
• 코드 슬러시: 11/9
• 코드 동결 시작: 11/15
• 문서 작성 및 검토: 11/27

나중에 추적할 수 있도록 원본 게시물의 이정표를 업데이트하고 1.13 개선 사항 추적 시트 에 포함해야 하는 경우 @kacole2 로 핑하십시오.

감사 해요!

1.13에서 계획된 변경 사항이 없습니다.

90일 동안 사용하지 않으면 문제가 부실해집니다.
/remove-lifecycle stale 를 사용하여 문제를 최신으로 표시합니다.
부실 문제는 추가로 30일 동안 사용하지 않으면 썩고 결국 닫힙니다.

이 문제를 지금 종료하는 것이 안전하다면 /close 로 종료하십시오.

sig-testing, kubernetes/test-infra 및/또는 fejta 에 피드백을 보내십시오.
/수명 주기 부실

/remove-lifecycle 부실

@tallclair 안녕하세요 - 저는 1.14에 대한 개선 사항의 리더이며 1.14 릴리스에 대해 어떤 작업(있는 경우)이 계획되고 있는지 확인하기 위해 이 문제를 확인하고 있습니다. 개선 사항 동결은 1월 29일이며 모든 개선 사항에는 KEP가 있어야 함을 상기시키고 싶습니다.

1.14에 대한 계획은 없습니다.

이것이 GA가 되기 위한 공백은 무엇입니까? 몇 가지를 생각할 수 있지만 설명에 어떤 기준도 표시되지 않습니다.

GA로 이동하기 전에 다음 문제를 해결해야 합니다.

1. 결함 있는 권한 부여 모델 - PSP 사용은 RBAC를 통해 부여되며 사용자 또는 생성된 포드에게 부여될 수 있습니다. 이를 사용자에게 부여하는 것은 직관적인 접근 방식이지만 문제가 있습니다(설명 참조). 이 접근 방식에는 몇 가지 보안 문제도 있습니다.
2. 롤아웃의 어려움 - 포드는 기본적으로 거부되기 때문에 모든 클러스터에 PSP를 롤아웃하지 않고는 롤아웃할 수 없습니다. 마찬가지로, PSP를 활성화하려는 사용자는 활성화하기 전에 모든 작업 부하를 완전히 커버해야 하므로 활성화하기 어렵습니다(따라서 사용량이 상대적으로 적음). 기능을 명시적으로 활성화해야 하기 때문에 적절한 테스트 범위가 없습니다(기능 매트릭스가 너무 복잡함).
3. 일관되지 않은 API - 근본적인 문제는 적지만 장기간에 걸친 k8s 릴리스에 걸친 PSP API의 발전으로 인해 사용하기 어렵게 만드는 여러 불일치가 발생했습니다. 특히 돌연변이는 유효성 검사와 함께 일괄 처리되므로 포드가 여러 PSP에 액세스할 때 예기치 않은 결과가 발생할 수 있습니다.

@liggitt 와 나는 이 문제를 해결하는 방법에 대한 몇 가지 아이디어가 있지만 이것이 핵심 Kubernetes에 속하는지 여부에 대한 열린 질문이 있습니다. 다음 달에 GA로의 전환 계획이나 지원 중단 계획에 대한 로드맵을 발표하고 싶습니다.

정보를 공유해 주셔서 감사합니다!

포드는 기본적으로 거부되기 때문에 PSP를 중단하지 않고 모든 클러스터에 PSP를 롤아웃할 수 없습니다.

꼭 그렇지는 않은 것 같아요. 먼저 충분히 열려 있는(또는 모두 열려 있는) PodSecurityPolicy를 만든 다음 점진적으로 개선하여 이를 수행했습니다.

@zhouhaibing089 Kubrenetes 사용자는 정책을 제어하기 때문에 작동하는 해당 방법을 사용할 수 있습니다. 그러나 PodSecurityPolicy는 클러스터만 열기 때문에 Kubernetes 기본값으로 롤아웃할 수 없습니다. 즉, 시스템 제어 허용 PSP를 관리하기가 매우 어렵습니다.

안녕하세요 @liggitt @tallclair , 저는 1.15의 Enhancement Lead입니다. 이 기능이 1.15에서 알파/베타/안정 단계를 졸업하게 됩니까? 제대로 추적하고 스프레드시트에 추가할 수 있도록 알려주세요. 커뮤니티 제안은 1.15에 포함하기 위해 KEP로 마이그레이션되어야 합니다.

코딩이 시작되면 이 호에 있는 모든 관련 k/k PR을 나열하여 올바르게 추적할 수 있도록 하십시오.

1.15에 대한 변경 계획 없음

@tallclair 1.16에서 이 땅을 GA로 보고 싶습니다. 그게 가능한가요?

@lachie83 아니요, PodSecurityPolicy가 GA로 전환되기를 원하는지 잘 모르겠습니다. 이것이 Kubernetes 코어에서 해결해야 하는 사용 사례인지 명확하지 않으며 우리는 코어 외 대안을 찾고 있습니다. 더 자세히 논의하고 싶다면 SIG-Auth에 좋은 주제입니다.

@tallclair Open Policy Agent의 게이트키퍼 와 같은 것이 아래로 향하는 더 나은 경로입니까?

네, 맞습니다. 그것이 주요 경쟁자일 수 있으며, 저는 해당 팀과 긴밀하게 협력하여 이러한 사용 사례를 다룰 수 있는지 확인하고 있습니다.

내가 기다려온 한 가지는 잠재적으로 PodSecurityPolicy --> OPA rego 정책을 번역할 수 있는 도구입니다. 그렇게 하면 당신의 관점에서 그들을 비추천하는 것이 훨씬 더 쉬워질 것입니다.

@tallclair 는 신속한 응답에 감사드립니다.

@SEJeff가 동의했습니다. 기능 패리티 및 마이그레이션 경로가 명확하게 대체될 때까지 PodSecurityPolicy를 더 이상 사용하지 않습니다.

@tallclair님 , GA 로드맵이나 지원 중단 계획을 언급 하셨습니다. 우리는 후자에 치우친 것 같습니다.

PSP를 솔루션으로 보고 있는 사람들을 돕기 위해 작성된 내용이 있습니까?

아직 아님. 주저하는 부분 중 하나는 명확한 대체가 있을 때까지 다른 것을 선호하여 더 이상 사용하지 않을 것이라고 말하고 싶지 않다는 것입니다. 게이트키퍼가 마음에 들긴 하지만 아직 PSP를 대체하는 데 필요한 기능(또는 안정성)이 없습니다. 또 다른 가능성은 PSP를 트리 밖으로 옮기고 GA에 승인 웹훅으로 가져올 수 있다는 것입니다(두 옵션은 상호 배타적이지 않음). 우리는 아직 공식적으로 로드맵을 제시하지 않았습니다.

무게

안녕하세요 @tallclair 는 1.16에서도 아무 일도 일어나지 않는 것 같으므로 그대로 유지하겠습니다.

안녕하세요 @tallclair -- 1.17 Enhancement 리드 -- 1.17에서 그대로 유지되는 것 같습니다. 변경되는 경우 주저하지 말고 저에게 찌르면 추적 시트에 추가할 수 있습니다 👍

PSP의 미래에 대한 명확한 경로에 대해 더 이상 논의가 없었습니까?

네, 맞습니다. 그것이 주요 경쟁자일 수 있으며, 저는 해당 팀과 긴밀하게 협력하여 이러한 사용 사례를 다룰 수 있는지 확인하고 있습니다.

@tallclair - Kyverno에서 대부분의 PSP 검사를 구현했습니다. 살펴보는 것을 도와주시겠습니까? 아이디어와 세부 사항을 논의하고 싶습니다.

https://github.com/nirmata/kyverno/blob/master/samples/README.md

Gatekeeper 프로젝트는 또한 PSP 이후의 세계가 어떤 모습일지 살펴보고 있습니다. 우리의 초기 접근 방식은 PSP 리소스를 개별 제약 조건 으로 나누는 것이었습니다. 우리는 이 접근 방식에 대한 커뮤니티의 생각이 궁금했습니다. 이러한 정책이 어떻게 구성되어 있는지 다시 생각해 볼 수 있는 좋은 시간이 되지 않을까요? 신규 사용자와 기존 PSP 사용자 모두를 위한 마이그레이션도 중요합니다.

cc @maxsmythe @sozercan @tsanall

정책을 개별 제약 조건으로 나누는 것에 대해 몇 가지 우려가 있습니다. 즉, 더 많은 제약 조건 개체를 만들어야 한다는 것입니다. 다른 워크로드에 대해 이를 복제하거나 변경해야 한다고 생각하면 매우 복잡해지지 않을까 걱정됩니다.

가장 좋은 접근 방식은 사용자 중심의 접근 방식일 것이라고 생각합니다. PSP가 어떻게 사용되는지에 대한 실제 피드백을 얻을 수 있고 이러한 대체 플러그인에서 유사한 설정이 어떻게 보이는지 확인할 수 있다면 디자인을 형성하는 데 도움이 될 수 있습니다.

@tallclair 우리가 추구하는 사용 사례 중 하나는 네임스페이스 기반 멀티 테넌시와 관련이 있습니다. 목적은 정책을 사용하여 제한을 적용하고 네임스페이스가 올바르게 구성되었는지 확인하는 것입니다.

GA로 이동하기 전에 다음 문제를 해결해야 합니다.

1. 결함 있는 권한 부여 모델 - PSP 사용은 RBAC를 통해 부여되며 사용자 또는 생성된 포드에게 부여될 수 있습니다. 이를 사용자에게 부여하는 것은 직관적인 접근 방식이지만 문제가 있습니다(설명 참조). 이 접근 방식에는 몇 가지 보안 문제도 있습니다.

@tallclair , 위의 사항이 궁금합니다. 이 접근 방식이 어떻게 문제가 되거나 보안 문제가 있는지 자세히 설명해 주시겠습니까?

정보를 더 많이 알고 있는 사람이 이 트윗을 확인해 주시겠습니까?

https://twitter.com/TechJournalist/status/1197658440040165377

그리고 그것이 사실이라면 오늘날 Linux 기능을 제한하기 위해 PSP를 사용하는 사람들은 앞으로 어떻게 해야 합니까?

안녕하세요 여러분,
이것은 매우 흥미로운 토론이며 현재 Kubernetes 클러스터에서 Pod 생성을 보호하기 위한 솔루션을 찾고 있습니다.

OPA 게이트키퍼와 PodSecurityPolicies와 OPA 제약 조건에서 PSP를 다시 구현하려는 노력을 살펴보았습니다.
이 비교에서 발견한 근본적인 문제는 두 개의 반대 모델을 다루고 있다는 것입니다.

• OPA Gatekeeper는 모든 것이 허용되고 관리자가 제약 조건이 있는 특정 항목을 금지하는 기본 공개 모델을 따릅니다.
• PSP는 모든 것이 금지되고 관리자가 정책에 따라 특정 항목을 허용하는 기본 폐쇄형 모델을 따릅니다.

보안 관점에서 PSP 모델이 더 낫다고 주장하지만 모든 워크로드가 이를 준수해야 하므로 기존 클러스터로 가져오기가 더 어렵습니다.

PSP와 Constraint Framework 사이의 아키텍처의 근본적인 격차를 어떻게 메울 계획입니까?

/cc @ritazh PSP 기능을 OPA로 이식하는 작업을 했기 때문에 이에 대한 귀하의 의견을 듣고 싶습니다.

다른 접근 방식은 확실히 마이그레이션을 더 복잡하게 만듭니다. 우리는 전환을 더 원활하게 만들기 위해 다양한 방법을 모색하고 있습니다.

완벽한 세상에서는 기본적으로 모두 거부가 더 안전한 접근 방식이라는 데 동의합니다. 그러나 PSP를 사용하고 출시하기 어렵게 만드는 요소 중 하나입니다. 실제로는 점진적으로 권한을 낮추는 것이 더 실현 가능하다고 생각하며 "최고의 보안은 사용하는 보안"이라는 오래된 격언이 있습니다.

참고로, 제약 조건에 대한 예외를 옵트아웃/제외/얻는 방법(예: kube-system 네임스페이스 보호)에 대해서도 논의하고 있습니다. 작동 방식에 따라 모든 것을 잠근 다음 예외를 허용하여 기본 거부 접근 방식을 구현할 수 있습니다. 그것이 우리가 디자인하고 싶은 유스 케이스인지 확실하지 않습니다 ...

@tallclair 1.18에서 이에 대한 진전이 있을 것으로 예상하십니까? 저는 릴리스의 개선 사항 섀도우이며 이를 추적해야 하는지 알고 싶습니다.

1.18에 대한 변경 계획 없음

90일 동안 사용하지 않으면 문제가 부실해집니다.
/remove-lifecycle stale 를 사용하여 문제를 최신으로 표시합니다.
부실 문제는 추가로 30일 동안 사용하지 않으면 썩고 결국 닫힙니다.

이 문제를 지금 종료하는 것이 안전하다면 /close 로 종료하십시오.

sig-testing, kubernetes/test-infra 및/또는 fejta 에 피드백을 보내십시오.
/수명 주기 부실

/remove-lifecycle 부실

@tallclair 안녕하세요 팀. 1.19에서 이에 대한 계획이 있습니까?

v1.19에 대한 계획은 없지만 v1.20 기간에 약간의 움직임이 있기를 바랍니다.

Open Policy Agent를 사용하여 Kubernetes Pod 보안 정책을 우연히 발견했습니다. @tallclair 는 우리를 방해하는 요소와 도움이 필요한 부분을 공유할 수 있으며 기꺼이 기여할 수 있습니다.

우리를 막고 있는 것을 공유할 수 있습니까

기본적으로 우리는 앞으로 나아갈 길에 대한 결정을 내리기만 하면 됩니다. 현재로서는 PSP가 현재 형태로 GA되지 않아야 한다는 데 동의했지만 아직 교체에 대해 결정하지 않았습니다. 논의한 옵션:

1. 교체 없음 - 입학 웹훅이 있는 타사 옵션에서 선택하는 것이 좋습니다. 최근에 게시된 Pod 보안 표준 문서에서는 동등한 기능을 홍보하여 ​​이를 더 원활하게 만들려고 합니다.
2. 대체 내장 컨트롤
   
   
   
   1. @deads2k 는 업스트림 오픈시프트 SecurityContextConstraints를 제안했습니다.
   
   
   2. 위에 링크된 표준 정책만 시행하는 최소 구성 기능을 제안했습니다(더 많은 구성 가능성이 필요한 경우 타사 솔루션 권장).
   
   
3. 포드 보안 정책 수정 - 일부 문제는 설계에 충분히 핵심적이지만, 이는 이전 버전과 호환되지 않아야 하며, 이 시점에서 (2)의 새로운 대안이 될 수 있습니다.

https://github.com/kubernetes/kubernetes/pull/90603 을 올바르게 읽고 있습니까? 포드 보안 표준이 게시되어 있기 때문에 API 서버에서 PSP에 대한 계획된 교체가 없으며 모든 교체가 외부 시스템으로 구현되어야 합니다.

https://github.com/kubernetes/enhancements/issues/5#issuecomment -637066475 참조

1.22의 현재 베타 버전에 대한 사용 중단 일정은 표준 포드 보안 프로필의 트리 내 구현이 제공되는지 여부와 무관합니다. 아직 결정되지 않았습니다.

감사 합니다 @liggitt 는 아무것도 설정되지 않았음을 확인했습니다. 원래 대체품이 나올 때까지 더 이상 사용되지 않을 것이라고 생각했습니다. 어떤 식으로든 결정이 내려졌는지는 분명하지 않았습니다.

지원 중단 일정은 PSP에만 국한되지 않으며 https://github.com/kubernetes/enhancements/tree/master/keps/sig-architecture/1635-prevent-permabeta 의 일부로 추가되었습니다.

내가 이것을 올바르게 읽고 있다면 사용 중단을 추진하는 것은 API가 9개월 이상 동일한 베타 버전에 있어야 하므로 PSP가 승격되거나 사용 중단되어야 하고 psp의 새로운 베타 또는 GA가 없기 때문에 교체가 결정되지 않은 경우에도 사용 중단을 위한 궤도에 올라야 합니까?

내가 이것을 올바르게 읽고 있다면 지원 중단을 추진하는 것은 API가 9개월 이상 동일한 베타 버전에 있어야 한다는 것입니다.

바로 그거죠. 모든 내장 API의 향후 모든 베타 버전은 처음 도입될 때 미리 사용 중단 및 제거 대상과 함께 제공됩니다.

안녕하세요 @tallclair

개선 사항은 여기로 연결됩니다. 1.20에서 이에 대한 계획이 있습니까?

감사 해요,
커스틴

v1.20에 대한 계획이 없습니다.

이 상황은 높은 보안 클러스터를 실행해야 하는 사람들에게 매우 실망스럽습니다. 우리의 옵션은 다음과 같습니다:

1. PSP가 더 이상 사용되지 않을 때까지 앉아서 기다리십시오.
2. OPA는 Rego로 완전히 제한적인 PSP 교체를 실행하는 방법을 문서화하지 않기 때문에 공급업체(Styra)에 워크로드 런타임 보안 적용을 아웃소싱합니다.

그래서 우리 회사는 완전히 잠긴 PSP를 구현했습니다. 그것들은 구현하기 쉽지 않고 디버깅하는 것이 귀찮은 일이지만 기능이 뛰어나고 실제로 작동합니다. 이러한 방식으로 사용할 수 있는 방법과 예외가 발생했을 때 처리하는 방법을 자세히 설명하는 블로그 게시물도 게시했습니다.

IMO, PSP 베타는 그대로 메인라인 쿠버네티스 코어에 병합되어야 합니다. 내 이유는 다음과 같습니다.

1. PSP에는 결함이 있지만 작동하며 10개 릴리스에서 작동했습니다.
2. 프로젝트로서의 Kubernetes는 워크로드 런타임 보안에 관심을 가져야 합니다. 컨테이너 탈출은 너무 쉽습니다. PSP는 공격자가 이를 더 어렵게 만드는 몇 안 되는 도구 중 하나입니다.
3. 완벽한 것은 Done의 적입니다. PSP를 있는 그대로 병합하고 "더 나은" 구현을 policy/v2로 푸시합니다.
4. 마지막으로 가장 중요한 것은 OSS 개발자가 Styra와 같은 공급업체를 감당할 수 있는 회사뿐만 아니라 더 높은 수준의 보안 클러스터를 실행할 수 있다는 것입니다.

@ zapman449 "완전히 제한적인 PSP 교체"가 무엇을 의미하는지 명확히 할 수 있습니까?

Gatekeeper PSP 라이브러리 를 통해 PSP에서 사용하는 것과 유사한 규칙을 쉽게 적용할 수 있기를 바랍니다. 나는 당신이 보고 있는 모든 기능적 격차에 확실히 관심이 있습니다.

@zapman449 혹시 그 블로그 포스트에 대한 링크가 있으신가요?

@christianhuening https://developer.squareup.com/blog/kubernetes-pod-security-policies

@maxsmythe 나는 Gatekeeper PSP가 하는 일을 따라잡지 못했고 검토할 것입니다.

그러나 내가 의미하는 바는 다음과 같습니다.

1. NET_BIND_SERVICE, SYS_ADMIN 등과 같은 프로세스 기능에 대한 완전한 제어
2. UID/GID/FSGroup을 0이 아닌 값으로 제한
3. 마운트할 수 있는 호스트 경로의 명시적 목록
4. 허용되는 볼륨 마운트 유형의 명시적 목록
5. 권한 있는 차단, 권한 상승 차단
6. 호스트 수준 프로세스 간 통신 기본 요소에 대한 액세스 차단
7. 호스트 네트워킹에 대한 액세스 차단
8. 허용되는 호스트 포트 제한
9. readOnlyRootFilesystem 시행
10. SELinux용 연결 지점

이들은 현재 PSP와 함께 제공됩니다.

위시리스트를 요청한다면 다음과 같이 하고 싶습니다.

1. 컨테이너의 SysCall에 대한 스마트 기본값. 대부분의 컨테이너에 필요한 전체 Linux 시스템 호출 목록의 작은 비율이 있습니다. 대부분의 컨테이너를 해당 목록으로 제한한 다음 특정 서비스 계정이 소유한 특정 팟(Pod)에 대한 특정 호출을 명시적으로 허용하거나 특정 서비스 계정에 특정 권한을 부여하도록 허용하겠습니다.
2. 조금 더 꿈을 꾸게 하고 뭔가 생각해낼게. ;-)

@zapman449 - 못 보셨다면 지난 sig-auth 회의에서 PSP의 미래에 대해 논의했습니다. ). 가능하다면 12월 9일 회의에서 논의를 계속할 것이지만 제안서를 메일링 리스트로 보내지 않고는 최종 결정을 내리지 않을 것입니다.

여기에서 우리의 의도는 누군가를 높고 건조한 상태로 두지 않는 것입니다. 우리는 PSP가 Kubernetes에 대한 중요한 보안 요구 사항을 해결한다는 것을 알고 있으며 이러한 논의의 목적은 미래에 이러한 요구 사항을 충족하는 가장 좋은 방법이 무엇인지 파악하는 것입니다.