APOIO DE procuração HTTP em Azure Kubernetes Service

Azure Kubernetes Service clusters (AKS), quer sejam implantados numa rede virtual gerida ou personalizada, têm certas dependências de saída necessárias para funcionar corretamente. Anteriormente, em ambientes que exigiam que o acesso à Internet fosse encaminhado através de proxies HTTP, este era um problema. Os nós não tinham forma de arrancar a configuração, variáveis ambientais e certificados necessários para aceder aos serviços de internet.

Esta funcionalidade adiciona suporte de procuração HTTP aos clusters AKS, expondo uma interface simples que os operadores de cluster podem usar para garantir o tráfego de rede exigido pela AKS em ambientes dependentes de procuração.

Algumas soluções mais complexas podem exigir a criação de uma cadeia de confiança para estabelecer comunicações seguras em toda a rede. A funcionalidade também permite a instalação de uma autoridade de certificados fidedigna nos nós como parte da colocação de um cluster.

Limitações e outros detalhes

Os seguintes cenários não são suportados:

  • Configurações de procuração diferentes por piscina de nó
  • Atualizar configurações de procuração após criação de cluster
  • Autenticação de utilizador/senha
  • CAs personalizados para comunicação de servidores API
  • clusters baseados em Windows
  • Piscinas de nó usando conjuntos de disponibilidade de máquina virtual (VMAS)

Por padrão, httpProxy, httpsProxy e trustCa não têm qualquer valor.

Pré-requisitos

Configurar um representante HTTP usando O Azure CLI

A utilização de AKS com um proxy HTTP é feita na criação de cluster, utilizando as az aks criam comando e passam na configuração como um ficheiro JSON.

O esquema para o ficheiro config é assim:

{
  "httpProxy": "string",
  "httpsProxy": "string",
  "noProxy": [
    "string"
  ],
  "trustedCa": "string"
}

httpProxy: Um URL de procuração para a criação de ligações HTTP fora do cluster. O sistema url deve ser http. httpsProxy: Um URL de procuração para a criação de ligações HTTPS fora do cluster. Se isto não for especificado, então httpProxy é utilizado para ligações HTTP e HTTPS. noProxy: Uma lista de nomes de domínios de destino, domínios, endereços IP ou outros CIDRs de rede para excluir a procuração. trustedCa: Uma cadeia que contenha o conteúdo alternativo do base64 encoded certificado de CA. Por enquanto, só apoiamos PEM o formato. Outra coisa a notar é que, para compatibilidade com componentes baseados em Go que fazem parte do sistema Kubernetes, o suporte do certificado MUST Subject Alternative Names(SANs) em vez dos certificados de nome comum precintados.

Entrada de exemplo: Note que o certificado CA deve ser a sequência codificada base64 do conteúdo do formato PEM cert.

{
  "httpProxy": "http://myproxy.server.com:8080/", 
  "httpsProxy": "https://myproxy.server.com:8080/", 
  "noProxy": [
    "localhost",
    "127.0.0.1"
  ],
  "trustedCA": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUgvVENDQmVXZ0F3SUJB...b3Rpbk15RGszaWFyCkYxMFlscWNPbWVYMXVGbUtiZGkvWG9yR2xrQ29NRjNURHg4cm1wOURCaUIvCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0="
}

Crie um ficheiro e forneça valores para httpProxy, httpsProxy e noProxy. Se o seu ambiente o exigir, também forneça um valor de confiança. Em seguida, coloque um aglomerado, passando o seu nome de arquivo através da http-proxy-config bandeira.

az aks create -n $clusterName -g $resourceGroup --http-proxy-config aks-proxy-config.json

O seu cluster rubricará com o proxy HTTP configurado nos nós.

Configurar um representante HTTP usando modelos Azure Resource Manager (ARM)

A implantação de um cluster AKS com um proxy HTTP configurado através do modelo ARM é simples. O mesmo esquema utilizado para a implantação do CLI existe na definição sob Microsoft.ContainerService/managedClusters propriedades:

"properties": {
    ...,
    "httpProxyConfig": {
        "httpProxy": "string",
        "httpsProxy": "string",
        "noProxy": [
            "string"
        ],
        "trustedCa": "string"
    }
}

No seu modelo, forneça valores para httpProxy, httpsProxy e noProxy. Se necessário, também fornecer um valor para 'trustCa. Implemente o modelo e o seu cluster deve inicializar-se com o seu proxy HTTP configurado nos nós.

Manuseamento do capotamento da CA

Os valores para httpProxy, httpsProxy e noProxy não podem ser alterados após a criação do cluster. No entanto, para suportar certs ca rolantes, o valor para trustedCa pode ser alterado e aplicado ao cluster com o comando de atualização az aks .

Por exemplo, assumindo que um novo ficheiro foi criado com a cadeia codificada base64 do novo ca cert chamado aks-proxy-config-2.json, a seguinte ação atualizará o cluster:

az aks update -n $clusterName -g $resourceGroup --http-proxy-config aks-proxy-config-2.json

Monitorização da configuração do add-on

Ao utilizar o proxy HTTP com o add-on de monitorização, as seguintes configurações são suportadas:

  • Procuração de saída sem autenticação
  • Procuração de saída com autenticação de senha de nome & de utilizador
  • Procuração de saída com certificado fidedigno para log analytics endpoint

As seguintes configurações não são suportadas:

  • As funcionalidades de Métricas Personalizadas e Alertas Recomendados não são suportadas quando se utiliza proxy com cert fidedigno
  • O proxy outbound não é suportado com Azure Monitor Private Link Scope (AMPLS)

Passos seguintes