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.

Descrição geral de segurança

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 o Kf também pode criar pods (com kubectl) que podem usar o kf-builder KSA com as autorizações do respetivo GSA associado.
  • 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 repositório de artefactos concedendo-lhes a função roles/storage.admin no projeto ou nos contentores que o repositório de artefactos usa.
  • O Kf usa o mesmo pod para obter, criar e armazenar imagens.
    • Parta do princípio de que as credenciais que fornecer podem ser conhecidas pelos autores e publicadores dos buildpacks que usa.
  • O Kf não suporta quotas para proteger contra vizinhos ruidosos.

Outros recursos

Geral

Proteções avançadas