Kf는 Cloud Foundry와 유사한 개발자 환경을 제공하고 빌드를 복제하고 수명 주기 동안 푸시하고 배포하는 것을 목표로 합니다. 이를 위해 처음부터 모든 부분을 구현하는 대신 Kubernetes, Istio, Container Registry와 같이 널리 알려지고 사용되는 기술들을 기반으로 개발자 UX 레이어를 구축합니다.
보안 개요
보안 결정을 내릴 때 Kf는 개별 구성에 고유한 솔루션을 제공하고 다른 메커니즘으로 증강할 수 있는 완전한 솔루션을 제공하는 것을 목표로 합니다. 세부 사항 다음과 같습니다.
- 완전한 솔루션은 Kf가 안전하다는 착각으로 이어질 수 있는 부분적인 솔루션을 제공하지 않으려 한다는 것을 의미합니다.
- 고유함은 브레이킹 체인지를 방지하기 위해 솔루션이 Kf 구조보다는 구성요소의 일부여야 한다는 것을 의미합니다.
- 증강 가능은 Kf가 다른 Kubernetes 및 Google Cloud 도구와 빈틈 없이 연동하여 심층 방어를 수행해야 함을 의미합니다.
중요 고려사항
아래에 설명된 현재 제한사항 외에도 이 섹션에 설명된 항목을 읽고 이해하는 것이 중요합니다.
워크로드 아이덴티티
기본적으로 Kf는 워크로드 아이덴티티를 사용하여 Google Cloud 프로젝트와의 상호작용을 위해 Kf에 사용되는 서비스 계정 사용자 인증 정보의 보안 제공 및 순환 기능을 제공합니다. 워크로드 아이덴티티는 Kubernetes 서비스 계정(KSA)을 Google 서비스 계정(GSA)에 매핑하여 이를 수행합니다. Kf 컨트롤러는 kf 네임스페이스에서 실행되며 GSA에 매핑된 controller라는 KSA를 사용하여 다음 작업을 수행합니다.
- Stackdriver에 측정항목 쓰기
- 새 Kf 공간이 생성되었을 때(
kf create-space), Kf 컨트롤러는 새 공간에kf-builder라는 새 KSA를 만들고 이를 동일한 GSA에 매핑합니다. kf-builderKSA는 Tekton에서 컨테이너 이미지를 Google Container Registry (gcr.io)로 push하고 pull하는 데 사용됩니다.
이 다이어그램은 이러한 상호작용을 보여줍니다.
현재 제한사항
- Kf는 사전 빌드된 RBAC 역할을 제공하지 않습니다.
- Kf에서 이를 제공할 때까지는 RBAC를 사용하세요.
- Kf를 사용하여 앱을 푸시하는 개발자는 연결된 GSA의 허가를 받아
kf-builderKSA를 사용할 수 있는 pod (kubectl)를 만들 수도 있습니다. - Kf에 배포하려면 컨테이너 레지스트리에 대한 쓰기 액세스 권한이 필요합니다.
- 프로덕션 리소스에 액세스하지 않고 전용 프로젝트에 Kf를 배포합니다.
- 프로젝트 또는 아티팩트 저장소에 사용되는 버킷에서
roles/storage.admin권한을 부여하는 방식으로 아티팩트 저장소에 코드를 푸시할 수 있는 액세스 권한을 개발자에게 부여합니다.
- Kf는 동일한 pod를 사용하여 이미지를 가져오고, 빌드하고, 저장합니다.
- 사용자가 제공하는 사용자 인증 정보는 사용되는 빌드팩의 작성자 및 게시자에게 알려질 수 있다고 가정합니다.
- Kf는 시끄러운 인접 항목으로부터 보호하기 위한 할당량을 지원하지 않습니다.
- Kubernetes 리소스 할당량을 사용합니다.