Visão geral da segurança

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.

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:

  1. Gravar métricas no Stackdriver
  2. Quando um novo espaço do Kf é criado (kf create-space), o controlador do Kf cria uma nova KSA chamada kf-builder no novo espaço e a mapeia para a mesma GSA.
  3. 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 KSA kf-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. Usar as cotas de recursos do Kubernetes

Outros recursos

Geral

Proteções avançadas