Descrição geral de segurança

O Kf tem como objetivo oferecer uma experiência de programador semelhante à do Cloud Foundry, replicando o ciclo de vida de criação, envio e implementação. Isto é feito através da criação de uma camada de experiência do utilizador para programadores com base em tecnologias amplamente conhecidas, usadas e adotadas, como o Kubernetes, o Istio e os registos de contentores, em vez de implementar todas as partes desde o início.

Ao tomar decisões de segurança, o Kf tem como objetivo fornecer soluções completas que sejam nativas dos respetivos componentes e que possam ser aumentadas com outros mecanismos. Analisemos isto:

  • Soluções completas significa que o Kf tenta não fornecer soluções parciais que possam levar a uma falsa sensação de segurança.
  • Nativo significa que as soluções devem fazer parte do componente e não de uma construção Kf para evitar alterações que possam causar problemas.
  • Pode ser aumentado significa que a abordagem que o Kf adota deve funcionar perfeitamente com outras ferramentas do Kubernetes e do Google Cloud para defesa em profundidade.

Aspetos a ter em conta

Além das limitações atuais descritas abaixo, é importante que leia e compreenda os itens descritos nesta secção.

Workload Identity

Por predefinição, o Kf usa a identidade da carga de trabalho para fornecer uma entrega e uma rotação seguras das credenciais da conta de serviço usadas pelo Kf para interagir com o seu Google Cloud projeto. O Workload Identity consegue isto ao mapear uma conta de serviço do Kubernetes (KSA) para uma conta de serviço Google (GSA). O controlador Kf é executado no espaço de nomes kf e usa um KSA denominado controller mapeado para o seu GSA para fazer o seguinte:

  1. Escreva métricas no Stackdriver
  2. Quando é criado um novo espaço Kf (kf create-space), o controlador Kf cria um novo KSA denominado kf-builder no novo espaço e mapeia-o para o mesmo GSA.
  3. O kf-builder KSA é usado pelo Tekton para enviar e extrair imagens de contentores para o Google Container Registry (gcr.io)

Este diagrama ilustra essas interações:

Limitações atuais

  • O Kf não fornece funções RBAC pré-criadas. Até que o Kf forneça esta funcionalidade, use o RBAC.

  • Um programador que envia uma app com Kf também pode criar pods (com kubectl) que podem usar o KSA com as autorizações do GSA associado.kf-builder

  • A implementação no Kf requer acesso de escrita a um registo de contentores. Implemente o Kf num projeto dedicado sem acesso a recursos de produção. Conceda aos programadores acesso para enviar código para o Artifact Repository concedendo-lhes roles/storage.admin no projeto ou nos contentores que o Artifact Repository usa.

  • O Kf usa o mesmo pod para obter, criar e armazenar imagens. Presuma que as credenciais que fornece podem ser conhecidas pelos autores e editores dos buildpacks que usa.

  • O Kf não suporta quotas para proteger contra vizinhos ruidosos. Use quotas de recursos do Kubernetes.

Outros recursos

Geral

Proteções avançadas