SGTM. @kubernetes/kubectl 이에 대한 생각이 있습니까?

불합리하지는 않지만 사용자 입력을 제어하려면 포드 보안 정책이 필요하고 이름으로 사용자를 허용하지 않아야 할 것입니다(컨테이너에 대해 허용하지 않기 때문에 UID를 지정해야 함).

@sttts 및 @ncdc re exec

합법적인 사용 사례

이에 대한 업데이트가 있습니까?

내 앱 컨테이너 이미지는 빌드팩을 사용하여 빌드됩니다. 쉘을 열고 싶습니다. 내가 할 때 나는 루트이고 모든 환경 변수가 설정됩니다. 그러나 빌드팩 생성 환경은 존재하지 않습니다. 앱 사용자( su -l u22055 )에 대한 로그인 셸을 열면 내 앱 환경이 있지만 이제 kubernetes 환경 변수가 없습니다.

su -l 이 env vars를 복사하지 않았다고 생각했습니다. 명시적으로 복사해야 합니다.
또는 다른 명령을 사용하십시오.

2016년 10월 11일 화요일 오후 5시 26분, Michael Elsdörfer < [email protected]

썼다:

내 앱 컨테이너 이미지는 빌드팩을 사용하여 빌드됩니다. 나는 열고 싶다
껍데기. 내가 할 때 나는 루트이고 모든 환경 변수가 설정됩니다. 하지만
buildpack 생성 환경이 없습니다. 로그인 셸을 열면
앱 사용자(su -l u22055) 내 앱 환경이 있지만 지금은
Kubernetes 환경 변수가 없습니다.

—
언급된 팀에 속해 있기 때문에 이 메시지를 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/30656#issuecomment -253085398,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ABG_p7sIu20xnja2HsbPUUgD1m4gXqVAks5qzCksgaJpZM4Jk3n0
.

@miracle2k - su -m -l u22055 해보셨나요? -m 는 환경 변수를 보존해야 합니다.

@adarshaj @smarterclayton 조언 감사합니다. su -m 자체 문제가 있지만(홈 디렉토리가 잘못됨) 그 동안 작동하게 했습니다. 하지만 요점은 - 그것이 내가 여기에 게시한 이유입니다 - "kubectl exec"이 올바른 일을 하는 것을 보고 싶다는 것입니다. 도커 파일이 정의한 사용자를 사용할 수도 있습니다.

다음은 이 기능이 필요한 예입니다.

공식 Jenkins 이미지는 사용자 Jenkins로 실행됩니다. 크기를 조정해야 하는 영구 디스크가 연결되어 있습니다. kubectl에 --user가 있는 경우 루트 및 크기 조정2fs로 bash할 수 있습니다. 불행히도 그것 없이는 극심한 고통입니다.

추가 사용 사례 - 보안을 의식하고 있으므로 컨테이너 내부에서 실행되는 모든 프로세스에 권한이 부여되지 않습니다. 그러나 지금은 예기치 않게 작동하지 않고 루트로 로그인하여 예를 들어 디버그 유틸리티를 설치하고 라이브 시스템의 문제를 파악하려고 합니다.

디버깅 목적으로 물건을 설치하는 것도 제 사용 사례입니다. 현재 나는 kubernetes를 실행하는 노드에 ssh 를 넣고 docker exec 를 직접 사용합니다.

이에 대한 상태는 어떻습니까? 이 기능은 매우 유용할 것입니다

확인하지 않았지만 --as 및 --as-group 전역 플래그가 여기에 도움이 되나요? exec 에서도 작동합니까? cc @liggitt

확인하지 않았지만 --as 및 --as-group 전역 플래그가 여기에 도움이 됩니까? 그들은 심지어 임원과 함께 일합니까? cc @liggitt

아니요, 이는 exec 호출에 대해 선택한 uid를 알리기 위해 전달하지 않고 kubernetes API에 자신을 식별하는 것과 관련이 있습니다.

사용자 플래그가 없다는 것은 번거로운 일입니다. 사용 사례는 권한이 없는 사용자로 실행되는 컨테이너가 있고 여기에 볼륨을 탑재하지만 볼륨 폴더는 사용자가 소유하지 않는 것입니다. 지정된 권한으로 볼륨을 마운트하는 옵션이 없습니다. 권한이 없는 사용자로 실행되기 때문에 진입점 스크립트를 사용하여 권한을 변경할 수 없습니다. 권한이 없는 사용자로도 실행되기 때문에 lifecycle.preStart 후크를 사용할 수 없습니다. kubectl exec -u root 는 '-u' 옵션이 있으면 그렇게 할 수 있습니다.

컨테이너 사용자가 아닌 'exec'를 허용/차단하려면 추가 RBAC 권한이 있어야 한다고 생각합니다.

이상적으로는 라이프사이클 후크는 컨테이너가 루트로 실행되지 않는 경우에도 컨테이너에서 루트로 실행할 수 있어야 합니다. 현재 가장 좋은 대안은 동일한 마운트에 대해 초기화 컨테이너를 실행하는 것입니다. 컨테이너 시작 시 루트로 한 줄 명령만 필요할 때 별도의 컨테이너를 시작하고 볼륨을 마운트하기 위한 일종의 오버헤드입니다.

/시그널 클립

이 기능에 대해 +1입니다. 이것이 없으면 디버깅을 훨씬 더 고통스럽게 만듭니다.

이 기능에 대해 +1입니다. 내 도커 컨테이너를 다시 빌드하고 도커 파일에 마지막 줄에 USER 루트가 있는지 확인한 다음 디버그하고 이를 비활성화해야 합니다.

docker 명령줄에 --user 플래그가 있는 것 같습니다.

johnjjung, 노드에 대한 ssh 액세스 권한이 있는 경우 사용자 플래그와 함께 docker를 사용하여 컨테이너에 연결할 수 있으므로 약간의 시간을 절약할 수 있습니다.

흠, 굉장합니다 이것을 시도하겠습니다

2017년 7월 10일 11:34 -0400, BenAbineriBubble [email protected] 에서 다음과 같이 썼습니다.

johnjjung, 노드에 대한 ssh 액세스 권한이 있는 경우 사용자 플래그와 함께 docker를 사용하여 컨테이너에 연결할 수 있으므로 약간의 시간을 절약할 수 있습니다.
—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 보거나 스레드를 음소거하세요.

+1 정말 문제입니다. ssh를 수행한 다음 docker exec를 실행해야 합니다.

/cc @frobware

+1 부탁드립니다. 더 이상 해결 방법으로 docker exec -u를 사용하고 싶지 않습니다.

+1 - kubectl exec은 docker exec에 비해 시간을 엄청나게 절약해 주므로 사용자를 지정하기 위해 docker exec로 되돌아가야 할 때마다 눈물이 납니다.

고려 사항:

• uid는 CRI용 exec 인터페이스의 일부여야 하며 모든 런타임에서 이를 지원해야 합니다.
• 인증 확인이 uid에 대한 포드 보안 정책 제한 사항인지 파악해야 합니다.

이것은 불행히도 우리가 습관적으로 만든 안전하지 않은 해결 방법을 방지하기 때문에 +1입니다(즉, runAsUser를 root로 설정... 그리고 public 😮을 배포할 때 값을 되돌리는 것을 잊음).

+1

나를 위해 +1, 포드에 로그인하고 실행 사용자로 루트를 사용하여 컨테이너를 재배포하지 않고 변경하려면 --user 플래그가 필요합니다.

이 문제는 매우 강력한 지원을 받는 것 같습니다. 우선 순위를 지정하기 위해 할 수 있는 일이 있습니까? (예, 예, 패치가 허용됩니다 :) )

+1 정의된 사용자와 함께 실행할 수 있는 이 기능이 있으면 편리합니다.

보안 문제로 인해 구현이 까다로울 수 있다고 생각합니까? 예를 들어 Dockerfile이 처음에 루트가 아닌 사용자로 설정된 경우 이제 루트 사용자로 명령을 실행하도록 허용해야 합니까? -- docker의 사용자 플래그는 이것을 어떻게 처리했습니까? 그들이 적절하게 처리했다면 kubectl exec 명령을 패치하여 이것을 전달하기만 하면 된다고 생각합니다.

이것이 적절한 전략인지 알려줄 수 있는 사람이 있습니까? 그런 다음 PR을 시작할 수 있습니다.

@johnjjung 예, 여기 전략은 docker --user 플래그를 전달하기 위해 kubectl exec를 패치하는 것입니다.

또한 kubectl에서 연결하기 위해 GCP에서 암시적 인증을 받았기 때문에 보안 문제는 경미해 보입니다.

또한 kubectl에서 연결하기 위해 GCP에서 암시적 인증을 받았기 때문에 보안 문제는 경미해 보입니다.

어때요? 포드 사양에서 허용되는 사용자에 대한 제어가 있습니다. exec 호출에 지정된 모든 사용자 ID에 대해 동등한 제어를 기대합니다. 원래 컨테이너가 아닌 경우 exec를 루트로 실행할 수 있는지 여부에 대해 비슷한 질문이 있습니다. 그렇다면 포드 보안 컨텍스트 및 포드 보안 정책 제어가 이 새로운 옵션에 적용되는 방식에 대한 생각 없이 이를 노출할 수 없습니다.

@liggitt Dockerfile 자체에서 사용자를 설정하는 것과 다르지 않지만 Docker의 사용자 플래그로 여전히 루트로 실행할 수 있습니다.

Docker의 주요 관심사는 _실행 중인_ 컨테이너 _내에서 루트 액세스를 방지하는 것입니다. 어느 시점에서 사용자가 도구를 개발하고 작업할 수 있도록 실제로 신뢰를 제공해야 합니다.

예를 들어 Dockerfile이 처음에 루트가 아닌 사용자로 설정된 경우 이제 루트 사용자로 명령을 실행하도록 허용해야 합니까? -- docker의 사용자 플래그는 이것을 어떻게 처리했습니까?

@johnjjung @jordanwilson230 이 말하는 것과 같습니다. docker 런타임 인수가 Dockerfile 지시문을 재정의합니다. 내 머리 꼭대기에서 이것은 대부분의 런타임 인수가 작동하는 방식입니다(예: 포트 번호).

원래 컨테이너가 아닌 경우 exec를 루트로 실행할 수 있는지 여부에 대해 비슷한 질문이 있습니다.

@liggitt 명확히 하자면, Pod 사양에 정의된 사용자 ID의 역할은 변경되지 않고 의도한 효과를 계속 유지합니다. 컨테이너(및 해당 프로세스)가 해당 사용자로 시작됩니다. 여기서 제기된 문제는 (이미) 인증된 사용자가 루트로 실행하거나 주로 디버깅 목적으로 모든 사용자를 실행할 수 있는 수동 옵션을 허용하는 것입니다.

여기서 제기된 문제는 (이미) 인증된 사용자가 루트로 실행하거나 주로 디버깅 목적으로 모든 사용자를 실행할 수 있는 수동 옵션을 허용하는 것입니다.

그리고 제 요점은 사용자가 컨테이너를 루트로 실행하는 것을 방지하기 위해 오늘날 우리가 가지고 있는 컨트롤이 루트로 실행되는 것을 방지하기 위해 여기에도 적용해야 한다는 것입니다.

@liggitt 죄송합니다. 더 명확하게 설명하는 방법을 잘 모르겠습니다. 위의 의견과 관련하여 다음을 시도하십시오.

• 포드를 실행하는 노드에 ssh(내 포드는 Kafka를 실행하고 kafka 사용자는 pod.spec에도 설정됨)
  jordan@gke-my-default-pool-dsioiaag-i9f3 ~ $ docker exec -it -u root myKafkaContainer bash root@kafka-0:/# echo "I've exec'd into my container as $(whoami) despite defining the kafka user in pod.spec...." I've exec'd into my container as root despite defining the kafka user in pod.spec.... root@kafka-0:/#
  이것이 GKE 관점에서 이미 가능하다는 것을 확인한 후(심각하게 성가신 방식이지만) 어떤 새로운 보안 문제를 생각하고 있습니까? 이 문제는 바퀴를 재발명하는 것이 아니라 편의를 제공하는 것입니다.

이것이 GKE 관점에서 이미 가능하다는 것을 확인한 후(심각하게 성가신 방식이지만) 어떤 새로운 보안 문제를 생각하고 있습니까?

문제는 현재 존재하지 않는 kubernetes API를 통해 권한을 노출하는 것입니다. 사용자가 API를 통해 워크로드를 실행할 수 있고 노드에 대한 ssh 액세스가 허용되지 않는 것은 정상입니다.

다음과 같은 경우 API를 통해 기능을 사용하는 것이 좋습니다.

1. 클러스터 관리자는 정책을 통해 허용 여부를 제어할 수 있습니다.
2. 정책이 표현되는 방식은 기존 정책과 일관성이 있습니다(이 경우 동일한 PodSecurityPolicy 메커니즘을 기반으로 하는 것이 이상적임).
3. 새 기능은 이전에 보안된 시스템의 구멍을 열지 않습니다(기본값이 꺼져 있거나 기존 정책에 따라 차단됨).

@liggitt 절대적으로 맞습니다. 따라서 보안 영향의 범위를 _node_ 액세스로 좁혔으므로 우리( @johnjjung 및 기타)는 마침내 실행 가능한 내용에 대해 이 토론을 사용할 수 있습니다. GKE 플랫폼에서 루트로 실행하기 위해 kubectl 플러그인을 시작했습니다. AWS와 다른 사람들을 만나려면 약간의 시간이 걸릴 것입니다. @johnjjung 그래도 끝낼 의향이 있나요?

@liggitt 편집한 내용을 방금 보았는데 앞으로 유용할 것입니다. 감사 해요.

관련 토론은 별도로 지정된 사용자 ID를 포함하여 기존 포드에서 임의의 컨테이너를 실행할 수 있도록 하는 제안( https://github.com/kubernetes/community/pull/1269 )을 참조하십시오.

실행하려는 것의 보안 측면이 원래 컨테이너에서 멀어질수록 전체 사양이 기존 승인 메커니즘에 의해 일관된 컨테이너로 검증될 수 있다는 것이 더 중요합니다.

@jordanwilson230 코드베이스를 검토하다가 kubectl exec 명령에 대한 통합 지점을 찾았습니다. 이는 좋은 출발점입니다. docker를 허용할 수 있는 다른 kubernetes 코드베이스에서 어디를 변경해야 하는지 잘 모르겠습니다. 유 플래그. 즉, 어딘가에서 시작하여 클러스터 관리자/포드 보안 정책 등으로 이 문제로 다시 돌아갈 수 있다고 생각합니다. 한 번에 한 단계씩.

누구든지 kubernetes가 docker --user 플래그를 실행하는 위치를 변경할 수 있는 위치를 알고 있다면 도움이 될 것입니다.

안녕하세요 @johnjjung입니다. 옛날 옛적에(<1.6) Kubernetes kubelets 는 Docker를 직접 사용했으며 이와 같은 옵션을 전달할 수 있었습니다. 이제 여러 런타임을 지원하는 표준 인터페이스인 CRI가 있습니다. Docker와 같은 런타임에 전달할 수 있는 명령을 결정하는 것은 CRI의 기능입니다.

Kubernetes는 다양한 컨테이너 런타임( dockershim +Docker+ containerd , cri-containerd + containerd , rkt, cri-o, lxd, Frakti 등)에 무엇을 해야 하는지 알려줍니다. CRI 인터페이스 를 사용하십시오. cri-o 런타임 구현을 위해 직접 또는 dockershim 또는 cri-containerd 와 같은 shim을 통해. 따라서 여기에서 원하는 작업을 수행할 수 있으려면(컨테이너가 시작된 것과 다른 사용자로 실행 중인 기존 컨테이너에 프로세스 추가) 먼저 해당 옵션을 지원하도록 CRI 사양 을 확장해야 합니다(예: ExecSync 는 uid 옵션이 필요하고 LinuxContainerSecurityContext 는 금지하지 않아야 합니다. @liggitt 가 위에서 많이 말한 것 같습니다).

그런 다음 각 컨테이너 런타임 또는 런타임 shim은 계속 진행하여 이에 대한 지원을 구현할 수 있습니다. Docker의 경우 이는 dockershim 구현을 확장하여 CRI 사양/인터페이스에 대한 추가를 지원함을 의미합니다. 그러나 dockershim +Docker가 더 이상 사용되지 않고 cri-containerd + containerd 가 추가 릴리스될 것으로 예상하므로 cri-containerd 에 집중하는 것이 좋습니다.

http://blog.kubernetes.io/2017/11/containerd-container-runtime-options-kubernetes.html

https://github.com/kubernetes/community/blob/master/contributors/devel/container-runtime-interface.md

또한 디버그 컨테이너 제안 으로 이 토론과 관련이 있습니다. 새로운 kubectl debug 명령을 사용하여 동일한 Pod 공간에서 두 번째 컨테이너 이미지를 실행할 수 있어야 합니다. 추가 컨테이너를 다른 사용자로 실행할 수 있습니까?

@whereisaaron 귀하의 게시물은 큰 도움이 됩니다. 자세히 적어주셔서 감사합니다.

@whereisaaron 자세한 내용 감사합니다. 내가 당신을 이해한다면, 디버그 제안(만일 그것이 통과된다면)이 하루가 끝날 때 이것을 두는 가장 좋은 장소가 될 것 같습니다. 작업 승인 여부는 확실하지 않지만 기본적으로 선택한 컨테이너를 해당 포드에 연결하여 해당 포드를 디버그할 수 있지만(굉장히 들립니다) 원래 컨테이너 내에서 사용자를 변경할 수 있습니까? 또한 기다리거나 cri-containerd를 사용하여 패치를 진행해야 합니까?

이것이 아직 구현되지 않은 이유 중 하나는 다른 영역에서 작업하는 여러 그룹이 있는 여러 저장소가 있기 때문인 것 같습니다.

@johnjjung 디버그 컨테이너가 Kubernetes 1.9에서 '알파' 기능으로 구현되도록 승인되었다고 생각합니다(해당 기능을 명시적으로 활성화하지 않는 한 해제됨). 나는 그들이 1.9에 그것을 만들었다라고 생각하지 않는다. 따라서 아마도 1.10 또는 그 이후까지는 아닐 것입니다.

내가 이해하는 것처럼 디버그 컨테이너는 '디버깅 중인' 대상 포드 내에서 프로세스로 실행되므로 포드와 동일한 커널 보안 컨텍스트에 있으며 자체 컨테이너 이미지/파일 시스템만 있습니다. 따라서 모든 프로세스를 디버그하고 Pod에 있는 모든 볼륨을 탑재할 수 있습니다. 그러나 동일한 보안 컨텍스트에 있으므로 Pod에서 사용할 수 있는 uid에 대해 동일한 커널 제한 제한이 있는지 궁금합니다. 거기에 대해 잘 모르겠지만 작업 중인 #sig-node 사람들에게 물어봐야 합니다.

CRI 확장과 관련하여 이를 수행하려면 #sig-node의 많은 지원이 필요하고 cri-containerd 및 cri-o 와 같은 다양한 런타임 프로젝트의 반대가 없어야 합니다. 그런 다음 지원을 구현해야 합니다.

오늘 시간이 많지 않았지만 GKE에서 실행되는 사용자를 위해 사용자 [-u] 플래그로 실행하기 위한 임시 kubectl 플러그인을 만들었습니다.

https://github.com/jordanwilson230/kubectl-plugins

설치 스크립트를 실행하여 해당 플러그인 또는 모든 플러그인을 자유롭게 수정/복사하십시오. @johnjjung 및 다른 사람들이 더 많은 작업을 수행할 수 있을 때까지 임시 솔루션일 뿐입니다.

GCP와 관련이 없는 대체 솔루션이 있습니다. 이것은 SSH를 전혀 사용하지 않으며 kubectl 작업만 필요합니다.

https://github.com/mikelorant/kubectl-exec-user

kubectl-exec-user의 포드는 그것을 사용하는 사람이 셸을 요청하는 컨테이너에 액세스할 수 있는지 확인합니까?

kubernetes API가 허용하는 액세스로 대체됩니다. RBAC가 컨테이너가 노드 도커 소켓을 마운트하도록 허용하는 경우에만 작동합니다.

SSH를 요구하지 않고 컨테이너에서 노드로 나가는 창의적인 방법을 내 솔루션을 고려하십시오. 모든 동일한 보안 조건을 고려해야 하지만 최소한 kubernetes API 서버 제한 사항을 준수합니다.

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

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

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

/remove-lifecycle 부실

이것은 매우 환영할 일입니다. 보안 의식이 있고 모든 프로세스를 루트가 아닌 것으로 실행하는 것에 대해 불이익을 받는 것은 쿨하지 않습니다. (https://github.com/kubernetes/kubernetes/issues/30656#issuecomment-272055993)

/ 서명 노드

https://github.com/kubernetes/kubernetes/pull/59092에서 이 기능에 대해 리베이스가 필요한 미완성 PR이 있는 것 같습니다. 그것을 집어들고 마무리할 수 있는 사람이 있습니까? CC @louyihua

+1
( @SimenB 와 같은 문제가 발생했습니다. 디버깅 목적으로 설치하고 싶습니다. 그런데 "도커를 직접 사용" 힌트에 감사드립니다.)

이것이 제대로 지원되기를 기다리는 동안 중간 솔루션은 su-exec (Dockerfile 또는 K8s 매니페스트에서)로 도커 CMD를 실행하는 것입니다. su-exec의 무게는 고작 20k(알파인에서)에 불과하며 kubectl exec에 루트를 유지하면서 앱이 권한 없이 실행됩니다.

+1

나는 또한 그러한 -u 플래그에 감사드립니다. +1.

그냥 아이디어:

예를 들어 --conainer-type 와 같은 것은 지원되는 모든 인수를 기본 컨테이너 구현에 직접 전달할 수 있도록 하는 큰 장점이 될 것입니다.

kubectl exec --container-type=docker -it -u 0 NAME

이렇게 하면 kubectl에서 컨테이너 런타임의 기본 기능 중 일부만 사용하는 것을 방지할 수 있습니다. 또한 지원되는 모든 컨테이너 유형에 대해 kubelet 계층에서 컨테이너까지 지원되는 인수를 매핑하고 추상화할 필요가 없기 때문에 노력을 절약할 수 있습니다.

따라서 요약하자면 --container-type 플래그가 없으면 kubectl에서 추상화된 인수만 사용할 수 있으며 기본 컨테이너 유형은 완전히 투명합니다. 플래그를 사용하면 컨테이너 특정 인수를 전달할 수 있습니다. 컨테이너 유형에 바인딩할지 여부는 kubectl 사용자에게 달려 있습니다.

BTW: @SimenB 에게 노드에 ssh하고 Docker를 직접 사용하라는 힌트를 주셔서 감사합니다. 그것은 일시적으로 내 문제를 해결했습니다. Minikube를 사용하여 다음을 수행하여 루트로 로그인할 수 있었습니다.
minikube ssh "docker exec -it -u 0 <container-id> bash"
어쩌면 이것은 누군가에게 도움이 될 수 있습니다.

불쾌감을 자동화하는 해결 방법 스크립트. 노드에 대한 SSH 액세스가 필요합니다.

용법:

```./shell-into-pod-as-root.sh[껍데기]
./shell-into-pod-as-root.sh 포드 이름
./shell-into-pod-as-root.sh 포드 이름 sh

Enjoy!

!/usr/bin/env bash

설정 -xe

POD=$(kubectl 설명 포드 "$1")
NODE=$(에코 "$POD" | grep -m1 노드 | awk -F'/' '{프린트 $2}')
CONTAINER=$(에코 "$POD" | grep -m1 '컨테이너 ID' | awk -F 'docker://' '{인쇄 $2}')

CONTAINER_SHELL=${2:-bash}

세트 +e

ssh -t "$NODE" sudo docker exec --user 0 -it "$CONTAINER" "$CONTAINER_SHELL"

만약 [ "$?" -gt 0 ]; 그 다음에
설정 +x
echo '파드에 SSH로 연결하지 못했습니다. "$PATH에서 실행 파일을 찾을 수 없음"과 유사한 오류 메시지가 표시되면 다음을 시도하십시오.'
echo "$0 $1 쉬"
파이
```

@Nowaker 어떻게 네임스페이스를 처리합니까?

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

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

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

/remove-lifecycle 부실

나는 또한 그러한 -u 플래그에 감사드립니다. +1.

그냥 아이디어:

예를 들어 --conainer-type 와 같은 것은 지원되는 모든 인수를 기본 컨테이너 구현에 직접 전달할 수 있도록 하는 큰 장점이 될 것입니다.

kubectl exec --container-type=docker -it -u 0 NAME

이렇게 하면 kubectl에서 컨테이너 런타임의 기본 기능 중 일부만 사용하는 것을 방지할 수 있습니다. 또한 지원되는 모든 컨테이너 유형에 대해 kubelet 계층에서 컨테이너까지 지원되는 인수를 매핑하고 추상화할 필요가 없기 때문에 노력을 절약할 수 있습니다.

따라서 요약하자면 --container-type 플래그가 없으면 kubectl에서 추상화된 인수만 사용할 수 있으며 기본 컨테이너 유형은 완전히 투명합니다. 플래그를 사용하면 컨테이너 특정 인수를 전달할 수 있습니다. 컨테이너 유형에 바인딩할지 여부는 kubectl 사용자에게 달려 있습니다.

BTW: @SimenB 에게 노드에 ssh하고 Docker를 직접 사용하라는 힌트를 주셔서 감사합니다. 그것은 일시적으로 내 문제를 해결했습니다. Minikube를 사용하여 다음을 수행하여 루트로 로그인할 수 있었습니다.
minikube ssh "docker exec -it -u 0 <container-id> bash"
어쩌면 이것은 누군가에게 도움이 될 수 있습니다.

예 - docker exec를 사용하여 이 작업을 수행하는 것은 사소한 일입니다. 대부분 일관성에 관한 것입니다. 다중 사용자 도커 컨테이너는 실제로 약간의 농담입니다. VM을 컨테이너로 변환하는 것의 유산입니다.

현재 grafana로 이 문제를 처리하고 있습니다. 이 작업은 시간이 지나면 지날 것입니다.

@bryanhuntesl 노드에 수동 ssh'ing이 필요하지 않은 해결 방법에 대한 논의가 있습니다. 이 플러그인을 사용해 볼 수도 있습니다 -- https://github.com/jordanwilson230/kubectl-plugins

사용자가 노드에 ssh하는 것을 허용하지 않으려면 어떻게 해야 합니까? 사용자에게 노드에 대한 ssh 액세스를 허용하고 도커에 대한 액세스를 허용하는 것은 보안 위험이 될 수 있습니다. Docker는 네임스페이스 또는 k8s 권한에 대해 아무것도 모릅니다. 사용자가 docker exec 를 실행할 수 있으면 _any_ 네임스페이스의 포드로 실행할 수 있습니다.

SSH는 적절한 솔루션이 아닙니다. IMHO.

사용자가 노드에 ssh하는 것을 허용하지 않으려면 어떻게 해야 합니까? 사용자에게 노드에 대한 ssh 액세스를 허용하고 도커에 대한 액세스를 허용하는 것은 보안 위험이 될 수 있습니다. Docker는 네임스페이스 또는 k8s 권한에 대해 아무것도 모릅니다. 사용자가 docker exec 를 실행할 수 있으면 _any_ 네임스페이스의 포드로 실행할 수 있습니다.

SSH는 적절한 솔루션이 아닙니다. IMHO.

나는 두 번째로, 대역 외 메커니즘을 사용하여 직접 액세스 권한을 얻는 것은 잠재적인 공격 영역을 증가시킨다는 의견입니다.

사용자가 노드에 ssh하는 것을 허용하지 않으려면 어떻게 해야 합니까? 사용자에게 노드에 대한 ssh 액세스를 허용하고 도커에 대한 액세스를 허용하는 것은 보안 위험이 될 수 있습니다. Docker는 네임스페이스 또는 k8s 권한에 대해 아무것도 모릅니다. 사용자가 docker exec 를 실행할 수 있으면 _any_ 네임스페이스의 포드로 실행할 수 있습니다.

SSH는 적절한 솔루션이 아닙니다. IMHO.

SSH @gjcarneiro가 필요하지 않은 솔루션이 있습니다. 또한 사용자는 먼저 Compute Metadata에 공개 SSH 키를 추가해야 노드(GCP의 경우) @bryanhuntesl에 대한 SSH 액세스가 허용됩니다.

@liggitt 이 주제가 시작된지 3년이 지났는데 결론은?

이 솔루션이 이전에 언급되었는지 확실하지 않지만 해결 방법으로 수행한 것은 모든 컨테이너에 올바른 사용자로 로그인하는 스크립트가 포함되도록 하는 것입니다. 플러스 모드:

도커 파일:

USER root
RUN echo "su -s /bin/bash www-data" >> /root/.bashrc
# this exit statement here is needed in order to exit from the new shell directly or else you need to type exit twice
RUN echo "exit" >> /root/.bashrc
# /var/www is www-data's home directory
COPY motd.sh /var/www/.bashrc

motd.sh:

RED='\033[0;31m'
YELLOW='\033[0;33m'

echo -e "${RED}"
echo "##################################################################"
echo "#        You've been automatically logged in as www-data.        #"
echo "##################################################################"
echo -e "${YELLOW} "
echo "If you want to login as root instead:"
echo -e "$(if [ "$KUBERNETES_PORT" ]; then echo 'kubectl'; else echo 'docker'; fi) exec -ti $(hostname) -- bash --noprofile -norc"

TEXT_RESET='\033[0m'

echo -e "${TEXT_RESET} "

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

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

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

/remove-lifecycle 부실

[exec-as] kubectl 플러그인 사용:

kubectl krew install exec-as

위에서 언급했듯이 이것은 보안 영향에 대한 KEP와 논의가 정말로 필요합니다. 그것이 반드시 나쁜 생각은 아닙니다. 단지 시스템에 상당한 영향을 미치고 코딩을 시작하기 전에 설계가 필요합니다.

이를 위해 KEP를 검토하고 관리하는 데 도움을 드리고 싶지만 확실히 문제가 있고 시간이 걸릴 수 있습니다.

@miracle2k - su -m -l u22055 해보셨나요? -m 는 환경 변수를 보존해야 합니다.

@miracle2k (trying to exec as root user) 시도했지만 No passwd entry for user '0' 얻었습니다.

$ su -m -l 0
No passwd entry for user '0'

여보세요. 이 문제를 해결하기 위해 "kpexec" CLI를 개발했습니다.
피드백을 주세요.

• https://github.com/ssup2/kpexec

포드를 실행하는 노드에서:

docker exec -u 0 -it \
    `kubectl -n NAMESPACE get pod \
          -l label=value \
          -o jsonpath='{range .items[*].status.containerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3` \
sh

@cristichiru 내가 운영한 대부분의 클러스터에는 기본 노드에 대한 직접 셸 액세스가 없습니다. 나는 종종 다른 사람들도 마찬가지라고 생각합니다.

이러한 경우 kubectl 플러그인과 같은 여기에 제시된 다른 옵션이 유일한 방법일 수 있습니다. 도커 데몬에 대한 액세스도 없다고 가정합니다.

+1

KEP 템플릿은 https://github.com/kubernetes/enhancements/tree/master/keps/NNNN-kep-template 에 있습니다.

하나를 작성하는 것이 얼마나 많은 작업인지 알 수 있을 거라 생각했는데... 네 저는 이 글을 쓰는 사람이 아닙니다. 템플릿은 체크리스트 항목 1에서 저를 잃어버렸습니다 **Pick a hosting SIG.** 프로세스에 더 익숙한 사람은 원합니다 초안을 시작하려면? 나는 단지 활성 Kubernetes 사용자로서 제안을 지원하기 위해 내 👍를 붙일 자리를 원합니다.

이것은 경솔하게 들릴지 모르지만 이 문제에 대해 약 6개의 잘 코딩/스크립트/문서화된 해결 방법을 보았으므로 나보다 제안된 기술 솔루션의 초안을 작성하는 데 더 나은 위치에 있는 사람들이 _있습니다_ 있습니다.

나는 Kubernetes가 PROCESS 때문에 합리적인 시간 안에 아무것도 달성할 수 없는 새로운 OpenStack이 된 것처럼 느낍니다.

@VikParuchuri 의 원래 사용 사례는 컨테이너 자체가 신뢰할 수 없는 사용자로 실행 중이더라도 루트로 컨테이너를 디버그/문제 해결하는 것입니다. 좋은 사용 사례입니다. 해결되면 루트가 아닌 사용자로 컨테이너를 실행할 수 있기 때문입니다. 🎉

docker exec 에 대한 KEP를 준비하기 전에 k8s 임시 디버그 컨테이너 가 이 사용 사례를 처리하지 않는지 빠르게 확인하십시오.

docker exec --user 는 해당 사용 사례를 해결하는 한 가지 방법일 뿐이며 사용 중인 도커 런타임에 의존합니다. k8s가 containerd 로 이동함에 따라 dockerd 및 친구는 선택 사항이거나 더 이상 설치되지 않았으므로 미래 지향적인 옵션이 아닐 수 있습니까?

이 사용 사례를 해결하는 또 다른 k8s 기본 방법은 임시 디버그 컨테이너입니다. 신뢰할 수 없는 사용자로 실행 중인 컨테이너가 있다고 가정합니다. 디버그 컨테이너를 사용하면 대상 컨테이너 와 동일한 프로세스 공간에서 임시 컨테이너를 시작할 수 있지만 루트(또는 누구든지)로 실행됩니다. 이 접근 방식은 exec 접근 방식에 비해 몇 가지 중요한 이점이 있습니다. 특히 디버그 컨테이너의 이미지에 필요한 모든 디버그 도구 및 유틸리티를 가져올 수 있습니다. 따라서 (🐑 .., 유죄!) 실행해야 하는 경우에 대비하여 유틸리티 및 편집기 등으로 대상 컨테이너 이미지를 부풀리는 대신, 대신 멋진 큰 스위스 군용 칼 디버그 컨테이너 이미지를 갖고 애플리케이션 이미지를 깨끗하게 유지할 수 있습니다. . 대상에 sh 만 있는 경우 디버그 컨테이너에서 bash 를 사용할 수 있습니다. 단일 바이너리 컨테이너 또는 배포 없는 컨테이너 와 같이 실행할 셸이 전혀 없는 컨테이너도 디버그할 수 있습니다.

예를 들어 busybox 를 사용하여 컨테이너를 루트로 디버그합니다.

kubectl alpha debug -it ephemeral-demo --image=busybox --target=ephemeral-demo

나는 이것이 컨테이너를 격리된 프로세스로 취급하고, 셸에 들어가는 미니 VM이 아니라 디버깅을 위해 '연결'한다는 점에서 틀림없이 더 나은 모델이라고 생각합니다. 단점은 외부 마운트 또는 '빈' 마운트를 공유할 수 없다면 대상의 파일 시스템을 검사할 수 없다고 생각합니다. 프로세스 네임스페이스를 대상과 공유하므로 /proc/$pid/root 를 통해 대상 컨테이너의 파일 시스템에 액세스할 수도 있습니다.

임시 디버그 컨테이너는 이미 PROCESS :-)를 탐색하고 구현되었습니다. 이 컨테이너는 ~1.16 및 1.18 kubectl 에 alpha debug 명령이 포함된 알파 버전입니다. 추가 정보:

참조:

• https://medium.com/01001101/ephemeral-containers-the-future-of-kubernetes-workload-debugging-c5b7ded3019f
• https://kubernetes.io/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral -container
• https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/
• https://www.shogan.co.uk/kubernetes/enabling-and-using-ephemeral-containers-on-kubernetes-1-16/

사려깊은 답변 감사합니다 @whereisaaron :) 나는 그것이 물건을 꽤 잘 포착한다고 생각합니다.

나는 하나를 작성하는 것이 얼마나 많은 작업을 하는지 알 수 있을 것이라고 생각했고... 예, 나는 이것을 작성하는 사람이 아닙니다. 템플릿은 체크리스트 항목 1에서 저를 잃어버렸습니다 . 호스팅 SIG를 선택하십시오. 프로세스에 대해 더 잘 알고 있는 사람이 초안을 시작하고 싶습니까? 나는 단지 활성 Kubernetes 사용자로서 제안을 지원하기 위해 내 👍를 붙일 자리를 원합니다.

KEP 는 상당히 어려울 수 있지만 이에 대한 약간의 컨텍스트를 제공하고자 합니다. Kubernetes 자체는 매우 큽니다. 잠재적인 변경 사항은 기고자 기반과 사용자 모두에게 매우 큰 폭발 반경을 갖습니다. 새로운 기능은 구현하기 쉬워 보이지만 두 그룹에 광범위하게 영향을 미칠 가능성이 있습니다.

우리는 코드 베이스의 일부를 SIG에 위임합니다. 그리고 하나 이상의 SIG가 기능에 대해 합의할 수 있는 것은 KEP를 통해서입니다. 기능이 수행하는 작업에 따라 API 검토를 거쳐 확장성 문제 등을 평가할 수 있습니다.

이 모든 것은 생산된 제품이 성공할 가능성이 가장 높고 SIG가 기꺼이 지원할 수 있는 방식으로 개발되도록 하기 위한 것입니다. 원저자(들)가 자리를 비울 경우, 이를 유지 관리하는 책임은 SIG에 있습니다. 예를 들어 기능이 안정적인 것으로 승격된 다음 사용 중단 플래그가 지정된 경우 사용 중단 정책 에 따라 제거되기까지 최소 1년이 걸립니다.

기능에 대한 수요가 충분할 경우 일반적으로 KEP 프로세스에 더 익숙한 사람이 이를 진행하고 진행하는 데 도움을 주겠다고 제안하지만 여전히 이를 주도할 사람이 필요합니다.

어떤 경우든 기능을 병합하는 것과 관련된 프로세스가 있는 이유에 대한 최소한의 정보를 제공하기를 바랍니다. :+1: 질문이 있는 경우 언제든지 직접 문의하세요.

단점은 외부 마운트 또는 '빈' 마운트를 공유할 수 없다면 대상의 파일 시스템을 검사할 수 없다고 생각합니다.

나에게 루트로 파일 시스템을 검사하고 루트로 파일 시스템과 상호 작용할 수 있는 유틸리티를 실행하는 것은 요청된 기능에 대한 지원을 원하는 가장 큰 이유입니다. 요컨대, 이 제안은 내 문제를 전혀 해결하지 못합니다.

단점은 대상의 파일 시스템을 검사할 수 없다고 생각합니다.

주입된 디버그 컨테이너가 대상 컨테이너와 프로세스 네임스페이스를 공유하기 때문에 디버그 컨테이너에서 대상 컨테이너에 있는 모든 프로세스의 파일 시스템에 액세스할 수 있습니다. 그리고 여기에는 컨테이너 파일 시스템과 해당 컨테이너에 마운트된 모든 파일 시스템이 모두 포함됩니다.

컨테이너 파일 시스템은 /proc/$pid/root 링크를 통해 포드의 다른 컨테이너에서 볼 수 있습니다.

https://kubernetes.io/docs/tasks/configure-pod-container/share-process-namespace/#understanding -process-namespace-sharing

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

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

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

/remove-lifecycle 부실

kubectl 알파 디버그 -it ephemeral-demo --image=busybox --target=ephemeral-demo

error: ephemeral containers are disabled for this cluster

@whereisaaron 대부분의 클라우드 제공업체가 이를 지원하지 않는 것 같으며 온프레미스의 경우 노드로 이동하여 컨테이너에 docker exec 를 넣을 수 있습니다. 다시 말하지만 유용성은 상당히 제한적입니다.

또한 /proc/$pid/root 를 통한 액세스는 내가 원하는 것이 아닙니다. "사이드 윈도우"가 아닌 직접 액세스를 원합니다. 예를 들어 apt/apk _in continer_ 와 같은 유틸리티를 실행하는 것은 루트 파일 시스템이 원하는 위치에 없을 때 쉽지 않습니다.

비슷한 문제가 있었습니다. 공식 helm 차트(jenkins)에서 배포한 공식 이미지에 일부 디렉토리, 링크 및 권한을 추가해야 했습니다.

exec-as 플러그인을 사용하여 해결할 수 있었습니다.

계획된 Docker 지원 중단 및 후속 제거와 함께 언제 이 문제가 해결됩니까? 임시 컨테이너는 아직 알파 버전입니다. Docker를 CRI로 사용하지 않고 안정적인 대안은 무엇입니까?

알파가 되는 것 외에도 임시 컨테이너는 단순히 kubectl exec --user 보다 사용하기가 훨씬 더 복잡합니다.

이에 대한 또 다른 사용 사례는 컨테이너에서 스크립트를 수동으로 실행하는 것입니다. 예를 들어 NextCloud의 occ 유지 관리 스크립트는 www-data로 실행해야 합니다. 이미지에 sudo 또는 이와 유사한 것은 없으며 문서에서는 Docker 환경에서 docker exec -u 33 를 사용하도록 권장합니다.

다음을 실행하여 nextcloud의 문제를 해결할 수 있습니다.

su -s /bin/bash www-data

그러나 이것은 이상적이지 않습니다.