Boletins de segurança

De vez em quando, lançaremos boletins de segurança relacionados ao Kubernetes Engine. Todos esses comunicados estão descritos nesta página.

Geralmente, as vulnerabilidades são mantidas sob sigilo e não podem ser divulgadas até que as partes afetadas tenham a oportunidade de solucioná-las. Nesses casos, as notas da versão do GKE mencionarão "atualizações de segurança" até que a divulgação seja liberada. No momento da liberação, as notas serão atualizadas para indicar a vulnerabilidade solucionada pelo patch.

Inscreva-se para receber os boletins de segurança do GKE. Inscreva-se

11 de fevereiro de 2019 (RunC)

Descrição Gravidade Observações

A Open Containers Initiative (iniciativa que cria padrões para contêineres, OCI, na sigla em inglês) descobriu recentemente uma nova vulnerabilidade de segurança, CVE-2019-5736, no RunC que permitia que um contêiner inserisse caracteres de escape para conseguir privilégios raiz no nó host.

Seus nós Ubuntu do Kubernetes Engine (GKE) são afetados por essas vulnerabilidades. Recomendamos que você faça upgrade para a versão com patch mais recente assim que possível, conforme detalhado abaixo.

O que fazer?

Para fazer upgrade dos seus nós, primeiro você precisa atualizar sua instância mestre para a versão mais recente. Esse patch está disponível para Kubernetes 1.10.12-gke.7, 1.11.6-gke.11, 1.11.7-gke.4, 1.12.5-gke.5 e para as versões mais recentes. Acompanhe a disponibilidade desses patches nas notas da versão.

Apenas os nós do Ubuntu no GKE são afetados. Nós que executam COS não são afetados.

A nova versão do RunC tem uso maior de memória e pode exigir a atualização da memória alocada para contêineres se você tiver limites baixos (< 16MB) configurados.

Qual vulnerabilidade é corrigida por esse patch?

O patch reduz os riscos da seguinte vulnerabilidade:

O CVE-2019-5736 descreve uma vulnerabilidade no RunC que permite que um contêiner mal-intencionado (com interação mínima do usuário na forma de exec) substitua o binário RunC do host e, assim, consiga execução de código no nível raiz no nó host. Contêineres não executados como raiz não são afetados. Isso é classificado como uma vulnerabilidade de alto nível de gravidade.

Alto CVE-2019-5736

11 de fevereiro de 2019 (Go)

Descrição Gravidade Observações

A linguagem de programação Go recentemente descobriu uma nova vulnerabilidade de segurança, CVE-2019-6486, que é uma negação de serviço (DoS) nas implementações de criptografia/elípticas das curvas elípticas P-521 e P-384. No Google Kubernetes Engine (GKE), isso liberaria um usuário a criar solicitações mal-intencionadas que consomem uma quantidade excessiva de CPU no servidor da API Kubernetes, potencialmente reduzindo a disponibilidade do plano de controle do cluster. Para mais detalhes, consulte a divulgação da Linguagem de programação Go.

Todas as instâncias mestre do Google Kubernetes Engine (GKE) são afetadas por essas vulnerabilidades. A versão mais recente do patch inclui a mitigação desta vulnerabilidade. Faremos upgrade automático dos clusters mestres para a versão com patch aplicado nas próximas semanas, no ritmo normal de atualização.

O que fazer?

Nenhuma ação é necessária. Faremos upgrade das instâncias mestres do automaticamente e no ritmo normal de atualização. Se quiser fazer isso antes, inicie o upgrade da instância mestre manualmente.

Esse patch está disponível no 1.10.12-gke.7, 1.11.6-gke.11, 1.11.7-gke.4, 1.12.5-gke.5 e nas versões mais recentes.

Qual vulnerabilidade é corrigida por esse patch?

O patch reduz os riscos da seguinte vulnerabilidade:

CVE-2019-6486 é uma vulnerabilidade nas implementações de criptografia/elípticas das curvas elípticas P-521 e P-384. Isso permite que um usuário crie entradas que consomem uma quantidade excessiva de CPU.

Alto CVE-2019-6486

3 de dezembro de 2018

Descrição Gravidade Observações

Recentemente foi descoberta no Kubernetes uma nova vulnerabilidade de segurança CVE-2018-1002105 que permite a usuários com níveis de privilégio relativamente baixo ignorar a autorização de acesso às APIs do kubelet. Com isso, eles podem executar operações arbitrárias em qualquer pod e em qualquer nó do cluster. Para ver mais detalhes, consulte a divulgação do Kubernetes. Todas as instâncias mestre do Google Kubernetes Engine (GKE) foram afetadas por essas vulnerabilidades. O upgrade dos clusters para a versão mais recente com patch já foi feito. Nenhuma ação é necessária.

O que fazer?

Nenhuma ação é necessária. O upgrade das instâncias mestre do GKE já foi feito.

Esse patch está disponível no GKE 1.9.7-gke.11, 1.10.6-gke.11, 1.10.7-gke.11, 1.10.9-gke.5, 1.11.2-gke.18 e nas versões mais recentes.

Qual vulnerabilidade é corrigida por esse patch?

O patch reduz os riscos da seguinte vulnerabilidade:

A vulnerabilidade CVE-2018-1002105 permite a usuários com níveis de privilégio relativamente baixos ignorar a autorização de acesso às APIs do kubelet. Com isso, eles podem fazer solicitações maiores de encaminhamento e chamadas arbitrárias à API do kubelet. Essa é uma vulnerabilidade crítica no Kubernetes. Com base em alguns detalhes na implementação do GKE que impediram o caminho não autorizado de escalonamento, podemos classificar a vulnerabilidade como alta.

Alto CVE-2018-1002105

13 de novembro de 2018

Descrição

Atualização de 16/11/2018: a revogação e a rotação de todos os tokens potencialmente afetados foram concluídas. Você não precisa fazer mais nada.

O Google descobriu recentemente um problema no plug-in da interface de rede de contêiner (CNI, na sigla em inglês) do Project Calico. Em determinadas configurações, isso pode causar o registro de informações confidenciais. O problema está sendo monitorado pela deliberação técnica da Tigera TTA-2018-001 (em inglês).

  • Se executado com geração de registros no nível de depuração, o plug-in da CNI do Calico gravará a configuração do cliente da API Kubernetes nos registros.
  • A CNI do Calico também gravará o token da API Kubernetes no nível de informação dos registros se o campo “k8s_auth_token” estiver definido na configuração de rede da CNI.
  • Além disso, no caso de execução do plug-in com geração de registros no nível de depuração, se o token da conta de serviço estiver definido de modo explícito no arquivo de configuração lido pelo Calico ou como uma variável de ambiente usada pelo Calico, os respectivos componentes (calico/node, felix, CNI) gravarão essa informação nos arquivos de registro.

Esses tokens têm as seguintes permissões:


bgpconfigurations.crd.projectcalico.org     [create get list update watch]
bgppeers.crd.projectcalico.org              [create get list update watch]
clusterinformations.crd.projectcalico.org   [create get list update watch]
felixconfigurations.crd.projectcalico.org   [create get list update watch]
globalbgpconfigs.crd.projectcalico.org      [create get list update watch]
globalfelixconfigs.crd.projectcalico.org    [create get list update watch]
globalnetworkpolicies.crd.projectcalico.org [create get list update watch]
globalnetworksets.crd.projectcalico.org     [create get list update watch]
hostendpoints.crd.projectcalico.org         [create get list update watch]
ippools.crd.projectcalico.org               [create get list update watch]
networkpolicies.crd.projectcalico.org       [create get list update watch]
nodes                                       [get list update watch]
pods                                        [get list watch patch]
namespaces                                  [get list watch]
networkpolicies.extensions                  [get list watch]
endpoints                                   [get]
services                                    [get]
pods/status                                 [update]
networkpolicies.networking.k8s.io           [watch list]
      

Os clusters do Google Kubernetes Engine que têm uma política de rede de cluster e o Stackdriver Logging ativados registraram os tokens da conta de serviço do Calico no Stackdriver. Clusters sem a ativação da política de rede não foram afetados.

Implantamos uma correção que migra o plug-in da CNI do Calico para gravar apenas no nível de aviso e usar uma nova conta de serviço. O código com patch será implantado em uma versão posterior.

Ao longo da próxima semana, executaremos uma revogação gradual de todos os potenciais tokens afetados. Este boletim será atualizado quando a revogação for concluída. Não é necessária nenhuma ação da sua parte. Essa rotação foi concluída em 16/11/2018.

Se você quiser rotacionar esses tokens imediatamente, execute o comando a seguir. A nova chave secreta da conta de serviço deverá ser recriada automaticamente em alguns segundos:


kubectl get sa --namespace kube-system calico -o template --template '&#123&#123(index .secrets 0).name&#125&#125' | xargs kubectl delete secret --namespace kube-system
      

Detecção

O GKE registra todos os acessos ao servidor da API. Para determinar se um token do Calico foi usado fora do intervalo de IP esperado, execute a consulta do Stackdriver a seguir. Observação: a consulta retornará apenas registros de chamadas feitas fora da rede do GCP. Faça as alterações necessárias de acordo com seu ambiente específico.


resource.type="k8s_cluster"
protoPayload.authenticationInfo.principalEmail="system:serviceaccount:kube-system:calico"
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "8.34.208.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "8.35.192.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "8.35.200.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.59.80.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.192.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.208.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.216.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.220.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.222.0/24")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.224.0.0/13")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "162.216.148.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "162.222.176.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "173.255.112.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "192.158.28.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "199.192.112.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "199.223.232.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "199.223.236.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "23.236.48.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "23.251.128.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.204.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.208.0.0/13")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "107.167.160.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "107.178.192.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.2.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.4.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.8.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.16.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.32.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.64.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.0.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.128.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.192.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.240.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.8.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.16.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.32.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.64.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.128.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "104.154.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "104.196.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "208.68.108.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.184.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.188.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.202.0.0/16")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.190.0.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.190.128.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.190.192.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.235.224.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.192.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.196.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.198.0.0/16")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.199.0.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.199.128.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.200.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "2600:1900::/35")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.190.224.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.232.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.234.0.0/16")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.235.0.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.235.192.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.236.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.240.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.232.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.4.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.220.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.242.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.244.0.0/14")
      

14 de agosto de 2018

Descrição Gravidade Observações

A Intel divulgou as seguintes Vulnerabilidades e Exposições Comuns (CVEs, na sigla em inglês):

Essas CVEs são coletivamente denominadas "L1 Terminal Fault (L1TF)".

As vulnerabilidades desse tipo atacam a configuração de estruturas de dados no nível do processador para explorar a execução especulativa. "L1" se refere ao cache de dados de nível 1 (L1D), um pequeno recurso dos núcleos usado para acelerar o acesso à memória.

Leia a postagem do blog do Google Cloud para ver mais detalhes sobre essas vulnerabilidades e os recursos do Compute Engine que ajudam a reduzir o impacto delas.

Impacto no Google Kubernetes Engine

A infraestrutura que executa o Kubernetes Engine e isola os clusters e os nós do cliente é protegida contra ameaças conhecidas.

Os pools de nós do Kubernetes Engine que usam a imagem do SO do Google otimizada para contêineres e estão com o upgrade automático ativado receberão as versões da imagem do SO para contêineres com o patch aplicado conforme elas forem disponibilizadas, a partir de 20 de agosto de 2018.

Os pools de nós do Kubernetes Engine que não estiverem com o upgrade automático ativado precisam realizar o processo manualmente conforme as versões com patch da imagem do SO otimizado para contêineres forem disponibilizadas.

Alto

6 de agosto de 2018. Última atualização: 5 de setembro de 2018

Descrição Gravidade Observações

Atualização: 9 de setembro de 2018

O boletim sobre a CVE-2018-5391 foi divulgado recentemente. Assim como a CVE-2018-5390, ela é uma vulnerabilidade de rede no nível do kernel que aumenta a eficiência de ataques de negação de serviço (DoS) contra sistemas vulneráveis. A principal diferença é que a CVE-2018-5391 pode ser explorada por meio de conexões IP. Atualizamos este boletim para detalhar as duas vulnerabilidades.

Descrição

Na CVE-2018-5390 ("SegmentSmack"), há a descrição de uma vulnerabilidade de rede no nível do kernel que aumenta a eficácia de ataques de negação de serviço (DoS) em sistemas vulneráveis com conexões TCP.

Na CVE-2018-5391 (“FragmentSmack”), você encontra a descrição de uma vulnerabilidade de rede no nível do kernel que aumenta a eficiência de ataques de negação de serviço (DoS) em sistemas vulneráveis por meio de conexões IP.

Impacto no Google Kubernetes Engine

Desde 11 de agosto de 2018, todas as instâncias mestre do Kubernetes Engine são protegidas contra essas duas vulnerabilidades. Além disso, todos os clusters desse serviço com a opção de upgrade automático ativada também estão protegidos. Os pools de nós que não estão com o upgrade automático ativado e foram atualizados manualmente pela última vez antes de 11 de agosto de 2018 podem ser afetados por essas duas vulnerabilidades.

Versões com patch aplicado

Devido à gravidade dessa vulnerabilidade, recomendamos que você faça o upgrade manual dos seus nós assim que o patch estiver disponível.

Alto

30 de maio de 2018

Descrição Gravidade Observações

Recentemente foi descoberta no Git uma vulnerabilidade que possibilita o escalonamento de privilégios no Kubernetes caso usuários sem privilégios tenham a permissão para criar pods com volumes gitRepo. A CVE é identificada pela tag CVE-2018-11235.

Fui afetado por essa vulnerabilidade?

Você pode ter sido afetado se todas as afirmações a seguir forem aplicáveis no seu caso:

  • Usuários que não são de confiança podem criar pods (ou acionar a criação deles).
  • Os pods criados por usuários que não são de confiança têm restrições que impedem o acesso root do host (por exemplo, por meio da PodSecurityPolicy).
  • Os pods criados por usuários que não são de confiança podem usar o tipo de volume "gitRepo".

Todos os nós do Kubernetes Engine estão vulneráveis.

O que fazer?

Proíba o uso do tipo de volume "gitRepo". Para fazer isso com a "PodSecurityPolicy", omita gitRepo da lista de permissões de volumes na sua PodSecurityPolicy.

Clone um repositório git em um volume "EmptyDir" a partir de um "initContainer" para conseguir um comportamento equivalente ao do volume "gitRepo".


apiVersion: v1
kind: Pod
metadata:
  name: git-repo-example
spec:
  initContainers:
    # This container clones the desired git repo to the EmptyDir volume.
    - name: git-clone
      image: alpine/git # Any image with git will do
      args:
        - clone
        - --single-branch
        - --
        - https://github.com/kubernetes/kubernetes # Your repo
        - /repo # Put it in the volume
      securityContext:
        runAsUser: 1 # Any non-root user will do. Match to the workload.
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
      volumeMounts:
        - name: git-repo
          mountPath: /repo
  containers:
    ...
  volumes:
    - name: git-repo
      emptyDir: {}

Qual patch corrige essa vulnerabilidade?

Um patch será incluído em uma das próximas versões do Kubernetes Engine. Volte a esta página em breve para mais detalhes.

Média

21 de maio de 2018

Descrição Gravidade Observações

Diversas vulnerabilidades foram descobertas recentemente no kernel do Linux. Elas podem possibilitar o escalonamento de privilégios de negação de serviço (por meio da falha do kernel) a partir de um processo sem privilégios. Essas CVEs são identificadas pelas tags CVE-2018-1000199, CVE-2018-8897 e CVE-2018-1087. Todos os nós do Kubernetes Engine são afetados por essas vulnerabilidades. Recomendamos que você faça o upgrade para a versão mais recente com patch, conforme detalhado a seguir.

O que fazer?

Para fazer o upgrade, primeiro você precisa atualizar sua instância mestre para a versão mais recente. Esse patch está disponível no Kubernetes Engine 1.8.12-gke.1, Kubernetes Engine 1.9.7-gke.1 e no Kubernetes Engine 1.10.2-gke.1. Essas versões incluem patches para imagens do Ubuntu e do SO otimizadas para contêineres.

Se você criar um novo cluster antes disso, especifique qual é a versão com o patch para que ela seja usada. Os clientes que ativaram os upgrades de nós automáticos e não realizaram a atualização manualmente terão os nós atualizados para versões com patch nas próximas semanas.

Quais vulnerabilidades são corrigidas por esse patch?

O patch reduz os riscos das seguintes vulnerabilidades:

CVE-2018-1000199: essa vulnerabilidade afeta o kernel do Linux. Ela permite que um usuário ou processo sem privilégios cause uma falha no kernel do sistema, o que levaria a um ataque de DoS ou escalonamento de privilégios. Essa é uma vulnerabilidade de alta gravidade, com classificação de 7,8 no Sistema de Pontuação de Vulnerabilidades Comuns (CVSS, na sigla em inglês).

CVE-2018-8897: essa vulnerabilidade afeta o kernel do Linux. Ela permite que um usuário ou processo sem privilégios cause uma falha no kernel do sistema, o que levaria a um ataque de DoS. Essa é uma vulnerabilidade de média gravidade, com classificação de 6,5 no Sistema de Pontuação de Vulnerabilidades Comuns (CVSS, na sigla em inglês).

CVE-2018-1087: essa vulnerabilidade afeta o hipervisor KVM do kernel do Linux. Ela permite que um processo sem privilégios cause uma falha no kernel convidado ou possivelmente consiga privilégios. Um patch que corrige essa vulnerabilidade foi incluído na infraestrutura em que o Kubernetes Engine é executado, então esse serviço não pode ser afetado. Essa é uma vulnerabilidade de alta gravidade, com classificação de 8,0 no Sistema de Pontuação de Vulnerabilidades Comuns (CVSS, na sigla em inglês).

Alto

12 de março de 2018

Descrição Gravidade Observações

O projeto Kubernetes divulgou recentemente novas vulnerabilidades de segurança, a CVE-2017-1002101 e a CVE-2017-1002102. Elas permitem que os contêineres acessem arquivos que não estão dentro deles. Todos os nós do Kubernetes Engine são afetados por essas vulnerabilidades. Recomendamos que você faça o upgrade para a versão com patch mais recente assim que possível.

O que fazer?

Devido à gravidade dessas vulnerabilidades, mesmo que você tenha ativado os upgrades automáticos, recomendamos que faça o upgrade manual dos seus nós assim que o patch estiver disponível. Isso deve acontecer até 16 de março, mas, de acordo com a programação de lançamento, talvez você tenha acesso a ele antes com base na zona em que seu cluster está.

Para fazer o upgrade, primeiro você precisa atualizar sua instância mestre para a versão mais recente. Esse patch está disponível no Kubernetes 1.9.4-gke.1, Kubernetes 1.8.9-gke.1 e no Kubernetes 1.7.14-gke.1. Os novos clusters usarão a versão com patch por padrão até 30 de março. Se você criar um novo cluster antes disso, especifique qual é a versão com o patch para que ela seja usada.

Os clientes que ativaram os upgrades de nós automáticos e não realizaram a atualização manualmente terão os nós atualizados para versões com patch até 23 de abril. No entanto, devido à natureza dessa vulnerabilidade, recomendamos que você faça o upgrade dos seus nós manualmente assim que o patch estiver disponível.

Quais vulnerabilidades são corrigidas por esse patch?

O patch reduz os riscos das seguintes vulnerabilidades:

Com a vulnerabilidade CVE-2017-1002101, os contêineres que usam ativações do volume subpath podem acessar arquivos fora do volume. Com isso, se você tiver bloqueado o acesso do contêiner aos volumes do caminho do host com a PodSecurityPolicy, um intruso com capacidade de atualizar ou criar pods poderá ativar qualquer caminho de host usando outro tipo de volume.

A vulnerabilidade CVE-2017-1002102 possibilita que contêineres que usam certos tipos de volume, incluindo chaves secretas, mapas de configuração, volumes projetados ou APIs decrescentes, excluam arquivos que estão fora do volume. Isso significa que, se um contêiner que usa um desses tipos de volume for comprometido ou você permitir que usuários que não são de confiança criem pods, um intruso poderá usar esse contêiner para excluir arquivos aleatórios no host.

Para saber mais sobre a correção, leia a postagem do blog do Kubernetes.

Alto
Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…