O objetivo do Kf é fornecer uma experiência de desenvolvedor semelhante ao Cloud Foundry, replicando o ciclo de criação, push e implantação. Ele faz isso criando uma camada de UX de desenvolvedor com base em tecnologias amplamente conhecidas e amplamente adotadas, como Kubernetes, Istio e Container Registry, em vez de implementar todas as partes do zero.
Visão geral da segurança
Ao tomar decisões de segurança, o Kf tem como objetivo fornecer soluções completas que são nativas dos respectivos componentes e podem ser aumentadas com outros mecanismos. Detalhamento:
- Soluções completas significa que o Kf tenta não fornecer soluções parciais que podem levar a uma falsa sensação de segurança.
- Nativo significa que as soluções precisam fazer parte do componente em vez de uma construção Kf para evitar alterações interruptivas.
- Pode ser aumentado significa que a abordagem do Kf precisa funcionar perfeitamente com outras ferramentas do Kubernetes e do Google Cloud para defesa com profundidade.
Considerações importantes
Além das limitações atuais descritas abaixo, é importante ler e entender os itens descritos nesta seção.
Workload Identity
Por padrão, o Kf usa a Identidade da carga de trabalho para fornecer entrega e rotação seguras das credenciais da conta de serviço usadas pelo Kf para interagir com o projeto do Google Cloud. A Identidade da carga de trabalho consegue isso ao mapear uma conta de serviço do Kubernetes (KSA) para uma conta de serviço do Google (GSA). O controlador Kf é executado no namespace kf
e usa uma KSA chamada controller
e mapeada para o GSA para fazer o seguinte:
- Gravar métricas no Stackdriver
- Quando um novo espaço do Kf é criado (
kf create-space
), o controlador do Kf cria uma nova KSA chamadakf-builder
no novo espaço e a mapeia para a mesma GSA. - A KSA
kf-builder
é usada pela Tekton para enviar e extrair imagens de contêiner para o Google Container Registry (gcr.io)
Esse diagrama ilustra essas interações:
Limitações atuais
- O Kf não fornece papéis RBAC predefinidos.
- Até que o Kf forneça isso, use o RBAC.
- Um desenvolvedor que envia um aplicativo com o Kf também pode criar pods (com
kubectl
) que podem usar o KSAkf-builder
com as permissões da GSA associada. - A implantação no Kf requer acesso de gravação a um registro de contêiner.
- Implante o Kf em um projeto dedicado sem acesso a recursos de produção.
- Conceda aos desenvolvedores acesso para enviar código ao repositório do artefato concedendo a eles
roles/storage.admin
no projeto ou aos buckets usados pelo repositório de artefatos.
- O Kf usa o mesmo pod para buscar, criar e armazenar imagens.
- Suponha que todas as credenciais fornecidas por você sejam conhecidas pelos autores e editores das versões usadas.
- O Kf não é compatível com cotas para proteger contra vizinhos com ruídos.
- Use as cotas de recursos do Kubernetes.
Outros recursos
Geral
- Visão geral de segurança do GKE
- Multilocação de cluster do GKE
- Identidade da carga de trabalho
- Políticas do GKE e do IAM