Notas de lançamento do Apigee Adapter para Envoy

Esta página aplica-se ao Apigee e ao Apigee Hybrid.

Veja a documentação do Apigee Edge.

Esta página documenta as notas de lançamento de todo o software Apigee Adapter for Envoy para 2021 e anos anteriores.

Consulte o artigo Adaptador para o Envoy para ver as notas de lançamento atuais (2022 e posteriores).

v2.0.4

A 3 de dezembro de 2021, lançámos a versão 2.0.4 do Apigee Adapter para Envoy.

Funcionalidades e melhorias

  • A lista de versões suportadas do Envoy e do Istio para o comando samples da CLI foi atualizada. Estas versões são agora suportadas para exemplos:
    • Envoy versões 1.18 a 1.20
    • Versões 1.10 a 1.12 do Istio

Problemas corrigidos

  • Foi adicionada uma verificação nula para o carregamento da chave privada do bloco PEM para evitar pânico. (Issue #360)
  • Os erros de autorização de serviços remotos são agora registados ao nível de depuração. É feita uma exceção a esta categorização para erros de obtenção de tokens para chaves da API. Nesse caso, os erros são registados ao nível de erro para que fiquem visíveis mesmo que o nível de registo de depuração para apigee-remote-service-envoy esteja desativado. Consulte também o artigo Definir níveis de registo de serviços remotos. (Edição n.º 104)

v2.0.3

A 21 de setembro de 2021, lançámos a versão 2.0.3 do Apigee Adapter para Envoy.

Problemas corrigidos

  • Foi corrigido um problema de registo de estatísticas com respostas diretas. O problema só ocorreu em determinadas circunstâncias. Por exemplo:
    • Para pedidos que não requerem uma verificação de autenticação/autorização, não foi gerado nenhum authContext e os metadados dinâmicos eram nulos, o que fez com que a entrada do registo de acesso fosse ignorada.
    • A resposta recusada usou o código RPC em vez do código HTTP, o que fez com que os registos fossem apresentados na IU do Apigee como bem-sucedidos.

v2.0.2

A 7 de junho de 2021, lançámos a versão 2.0.2 do Apigee Adapter para Envoy.

Problemas corrigidos

  • Foi corrigida uma condição de corrida que podia causar erros 403 e pânicos quando os âmbitos das reivindicações JWT eram nulos.

v2.0.1

Na terça-feira, 29 de abril de 2021, lançámos a versão 2.0.1 do Apigee Adapter para Envoy.

Problemas corrigidos

Funcionalidade Descrição
Erro

Foi corrigido um problema que fazia com que a versão 2.0.0 funcionasse incorretamente quando usada com o Apigee Hybrid v1.5.0 ou o Apigee. Se estiver a atualizar a instalação do Apigee hybrid para a versão 1.5.x, o caminho de atualização recomendado para o adaptador é:

  1. Atualize o Apigee Adapter para Envoy para a versão 2.0.1.
  2. Atualize o Apigee Hybrid para a versão 1.5.1.

Se estiver a usar o Apigee, basta atualizar o adaptador para a versão 2.0.1.

v2.0.0

Na terça-feira, 6 de abril de 2021, lançámos a versão 2.0.0 do Apigee Adapter para Envoy.

Funcionalidades e melhorias

Funcionalidade Descrição
Suporte para ambiente multiinquilino

Agora, pode ativar o adaptador para servir vários ambientes numa organização do Apigee. Esta funcionalidade permite-lhe usar um adaptador do Apigee para o Envoy associado a uma organização do Apigee para prestar serviços a vários ambientes. Antes desta alteração, um adaptador estava sempre associado a um ambiente do Apigee. Para mais informações acerca desta funcionalidade, consulte Suporte de ambiente multi-inquilino.
Suporte da API Envoy v3
Suporte de metadados do Envoy

O Envoy 1.16+ permite enviar metadados ext_authz sem ter de usar cabeçalhos. Com esta e outras alterações relacionadas, agora fornecemos melhores códigos de resposta HTTP para pedidos recusados e já não precisamos de instalar um filtro RBAC no Envoy. Consulte

Esta funcionalidade só é suportada para o Envoy 1.16 e superior e o Istio 1.9 e superior.

Com esta alteração, a seguinte configuração deixa de ser adicionada ao ficheiro de configuração do Envoy (envoy-config.yaml): 

additional_request_headers_to_log:
    - x-apigee-accesstoken
    - x-apigee-api
    - x-apigee-apiproducts
    - x-apigee-application
    - x-apigee-clientid
    - x-apigee-developeremail
    - x-apigee-environment

Se quiser anexar cabeçalhos a pedidos para um caso especial, basta definir a propriedade append_metadata_headers:true no ficheiro config.yaml do adaptador.
Divida o proxy remote-token do proxy remote-service

O proxy remote-service foi refatorado em dois proxies separados. O aprovisionamento da v2.0.x instala dois proxies de API: remote-service e remote-token. Os pontos finais /token e /certs foram movidos do proxy remote-service para remote-token.

Esta alteração cria uma separação útil das funções. Agora, o proxy remote-service só é usado para comunicações internas do adaptador, enquanto o proxy remote-token fornece um exemplo de fluxo de trabalho OAuth que pode personalizar. Nunca substituímos o proxy remote-token personalizado, mesmo que seja usado o comando provision --force-proxy-install.

Suporte de captura de dados

O adaptador suporta agora a transmissão de metadados do Envoy para a funcionalidade de captura de dados do Apigee, que envia dados capturados em variáveis que especifica para o Apigee Analytics para utilização em relatórios personalizados. Esta funcionalidade oferece uma capacidade semelhante à da política de captura de dados do Apigee. Para mais informações acerca desta funcionalidade, consulte o artigo Captar dados para relatórios personalizados.

RBAC not required

Conforme indicado anteriormente em Suporte de metadados do Envoy, agora rejeitamos imediatamente pedidos não autorizados sem exigir um filtro RBAC separado. Uma vez que a RBAC não é usada, os clientes vão agora receber estes códigos de estado HTTP, conforme adequado, do adaptador:

  • 401 Não autorizado
  • 403 Proibido
  • 429 Demasiados pedidos
  • 500 Erro interno do servidor

Se quiser permitir que os pedidos não autorizados continuem, pode fazê-lo definindo auth:allow_unauthorized:true no ficheiro config.yaml do adaptador.

Os cabeçalhos x-apigee-* já não são anexados por predefinição

Conforme mencionado anteriormente na secção Suporte de metadados do Envoy, os cabeçalhos x-apigee-* já não são anexados por predefinição. Se quiser adicioná-los, defina append_metadata_headers:true no ficheiro config.yaml. Esta configuração é totalmente opcional e só deve ser usada quando for desejável encaminhar cabeçalhos para o serviço de destino a montante.

Correspondência personalizada de um pedido a uma operação de produto de API do Apigee

A semântica da propriedade api_header config permanece igual à propriedade target_header anterior (o valor predefinido continua a ser o nome do anfitrião de destino), e o conteúdo do cabeçalho especificado continua a corresponder ao atributo Remote service target do produto da API ou ao campo Source numa configuração de operações do produto da API.

Para substituir este valor do cabeçalho através dos metadados do Envoy, pode transmitir o elemento de metadados do Envoy para o adaptador para especificar diretamente o alvo do serviço remoto do produto API ou a origem da API da operação do produto API.apigee_api Para configurar, adicione código semelhante ao seguinte ao ficheiro de configuração do Envoy (que pode gerar através da CLI do adaptador): 

typed_per_filter_config:
  envoy.filters.http.ext_authz:
    "@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthzPerRoute
    check_settings:
      context_extensions:
        apigee_api: httpbin.org
As estatísticas dos pedidos rejeitados são registadas imediatamente

O adaptador do Envoy vai registar imediatamente os pedidos rejeitados nas estatísticas, conforme necessário, em vez de aguardar que o pedido seja devolvido no registo de acesso. Isto é mais eficiente e não requer a anexação de metadados ao pedido.
O apoio técnico do UDCA foi removido

O streaming para o agente de recolha de dados universal (UDCA) da Apigee no Apigee hybrid e no Apigee já não é necessário para as estatísticas, uma vez que foi substituído pelo carregamento direto. Esta alteração remove simplesmente o suporte antigo para esta opção.

Suporte de mTLS adicionado para o Edge for Private Cloud nos comandos CLI provision/bindings

Os utilizadores do Apigee Edge para nuvem privada podem fornecer certificados TLS do lado do cliente e o certificado de raiz através de ‑‑tls‑cert, ‑‑tls‑key e ‑‑tls‑ca, respetivamente, quando aprovisionam ou listam associações de produtos através da CLI.

Suporte de mTLS entre o adaptador e o tempo de execução do Apigee

Pode fornecer certificados TLS do lado do cliente na secção tenant do ficheiro config.yaml do adaptador para usar o mTLS entre o adaptador e o tempo de execução do Apigee. Esta alteração aplica-se a todas as plataformas Apigee suportadas. Também ativa o mTLS para estatísticas para a plataforma Apigee Edge for Private Cloud. Para mais informações, consulte o artigo Configurar o mTLS entre o adaptador e o tempo de execução do Apigee.

Outros problemas e correções

  • Foi corrigido um problema em que várias configurações de operações com a mesma origem da API partilhavam os mesmos identificadores de bucket de quota e causavam conflitos no cálculo da quota. (Edição n.º 34)
  • Foi corrigido um problema em que as operações sem verbos especificados faziam com que o pedido fosse recusado (o comportamento esperado é permitir todos os verbos se nenhum for especificado). (Edição n.º 39)

v1.4.0

Na quarta-feira, 16 de dezembro de 2020, lançámos a versão 1.4.0 do Apigee Adapter para Envoy.

Plataformas suportadas

Publicamos ficheiros binários para MacOS, Linux e Windows.

Publicamos imagens Docker do distroless, Ubuntu e Ubuntu com Boring Crypto da Google.

Nesta versão, suportamos as seguintes plataformas:

  • Apigee Hybrid versão 1.3.x, 1.4.x (data de lançamento pendente), Apigee para nuvem pública, Apigee para nuvem privada e Apigee no Google Cloud
  • Versões 1.5, 1.6, 1.7 e 1.8 do Istio
  • Versões 1.14, 1.15 e 1.16 do Envoy

Funcionalidades e melhorias

Funcionalidade Descrição
O proxy remote-service já não requer associação a um produto de API que use destinos de serviços remotos.

Uma vez que esta associação já não é necessária, tenha em atenção as seguintes alterações:

  • Um produto de API remote-service já não é criado durante o aprovisionamento.
  • O comando da CLI bindings verify já não é relevante e foi descontinuado.
A função de administrador da organização do Apigee já não é necessária para o aprovisionamento.

Em vez de exigir a autorização de administrador organizacional para o aprovisionamento, agora pode usar as funções de criador e implementador da API IAM. Tem de conceder ambas as funções para o aprovisionamento ser bem-sucedido.
(Aplica-se apenas ao Apigee no Google Cloud e ao Apigee Hybrid)

Outros problemas e correções

  • Foi corrigido um problema em que o reaprovisionamento do Apigee sem a opção --rotate terminava com um erro.
  • A CLI de aprovisionamento lê e reutiliza agora as credenciais da conta de serviço do Analytics a partir de um ficheiro config.yaml específico (Issue #133).

v1.3.0

Na segunda-feira, 23 de novembro de 2020, lançámos a versão 1.3.0 do Apigee Adapter para Envoy.

Plataformas suportadas

Publicamos ficheiros binários para MacOS, Linux e Windows.

Publicamos imagens Docker do distroless, Ubuntu e Ubuntu com Boring Crypto da Google.

Nesta versão, suportamos as seguintes plataformas:

  • Apigee Hybrid versão 1.3.x, 1.4.x (data de lançamento pendente), Apigee para nuvem pública, Apigee para nuvem privada e Apigee no Google Cloud
  • Versões 1.5, 1.6, 1.7 e 1.8 do Istio
  • Versões 1.14, 1.15 e 1.16 do Envoy

Funcionalidades e melhorias

Funcionalidade Descrição
Suporte para OperationGroups de produtos da API. Os OperationGroups associam os recursos e a aplicação de quotas associada num proxy ou num serviço remoto com métodos HTTP. Para obter detalhes, consulte OperationGroup.
(Aplica-se apenas ao Apigee no Google Cloud e ao Apigee Hybrid)
Remoção do suporte para proxy de encaminhamento dinâmico da geração de amostras. Devido a esta alteração, os clientes têm de incluir o cabeçalho HOST se o nome do anfitrião for diferente do anfitrião de destino do serviço remoto definido no produto API. For example: 
curl -i http://localhost:8080/httpbin/headers -H "HOST:httpbin.org"

Consulte o artigo Crie um produto de API.

Suporte contas de serviço e o Workload Identity. Para permitir que os dados de estatísticas sejam carregados para o Apigee quando executar o adaptador fora de um cluster híbrido do Apigee, tem de usar o parâmetro analytics-sa com o comando apigee-remote-service-cli provision. Além disso, o adaptador suporta agora o Workload Identity no Google Kubernetes Engine (GKE). Consulte o comando Provision.
(Aplica-se apenas ao Apigee no Google Cloud e ao Apigee Hybrid)
Novo atributo de configuração jwt_provider_key. Esta chave é adicionada ao ficheiro de configuração. Representa a chave payload_in_metadata do fornecedor de JWT na configuração do Envoy ou o emissor de JWT RequestAuthentication na configuração do Istio.
O atributo de configuração KeepAliveMaxConnectionAge tem agora 1 minuto como valor predefinido. A predefinição anterior era de 10 minutos. Esta alteração permite um dimensionamento mais suave. Este valor também é usado para a duração da stream do registo de acesso. Consulte o ficheiro de configuração.
Comandos da CLI removidos. Os seguintes comandos da CLI foram descontinuados. Recomendamos que use as APIs Apigee em alternativa para atualizar os destinos de serviços remotos para produtos de API:
  • apigee-remote-service-cli bindings add
  • apigee-remote-service-cli bindings remove
Novo comando da CLI adicionado. O comando: 
apigee-remote-service-cli samples templates

lista as opções disponíveis que pode usar com a sinalização --template no comando samples create. Consulte a referência da CLI.
Alterou o comando da CLI existente. Foi feita uma alteração ao comando apigee-remote-service-cli samples create. As flags específicas dos modelos do Envoy ou do Istio são rigorosamente verificadas e são devolvidos erros nas flags usadas incorretamente. A opção de modelo native foi descontinuada. Para obter uma lista dos modelos disponíveis, use o comando apigee-remote-service-cli samples templates. Veja também a referência da CLI.
A resposta do ponto final /token segue agora a especificação OAuth2. O parâmetro access_token foi adicionado à resposta e o parâmetro token foi descontinuado.

v1.2.0

Na quarta-feira, 30 de setembro de 2020, lançámos a versão 1.2.0 do Apigee Adapter para Envoy.

Plataformas suportadas

Publicamos ficheiros binários para MacOS, Linux e Windows.

Publicamos imagens Docker do distroless, Ubuntu e Ubuntu com Boring Crypto da Google.

Nesta versão, suportamos as seguintes plataformas:

  • Apigee Hybrid versão 1.3.x
  • Versões 1.5, 1.6 e 1.7 do Istio
  • Versões 1.14 e 1.15 do Envoy

Funcionalidades e melhorias

Funcionalidade Descrição
Apoio técnico do Apigee no Google Cloud Agora, pode usar o Apigee Adapter para Envoy com o Apigee no Google Cloud. Pode executar o adaptador no seu próprio cluster ou executando o serviço remoto para o Envoy como um binário nativo ou num contentor. Aprovisione o adaptador no Apigee através do comando provision.
Carregamento direto de dados de estatísticas Agora, pode configurar o Apigee Adapter para carregar dados de estatísticas para o Apigee diretamente. Se estiver a usar o Apigee hybrid, esta nova funcionalidade permite implementar o adaptador no respetivo cluster do Kubernetes, fora do cluster onde o Apigee hybrid está instalado. Para ativar o carregamento direto, use a nova flag --analytics-sa com o comando provision. Consulte o comando provision.
A verificação do estado devolve "Pronto" depois de os dados de produtos da API serem carregados a partir do Apigee A verificação de estado do Kubernetes não devolve "Pronto" até que os dados do produto API sejam carregados a partir do Apigee. Esta alteração ajuda na escalabilidade e na atualização, porque não é enviado tráfego para o adaptador recém-instanciado até que esteja pronto.

Outros problemas e correções

  • Foi corrigido um problema para resolver um potencial impasse de sincronização de quotas (Issue #17).
  • As anotações do Prometheus foram movidas para a especificação do pod (Issue #69).
  • Foi corrigido um problema para resolver erros de validação emitidos incorretamente (Issue #62).

v1.1.0

Na quarta-feira, 26 de agosto de 2020, lançámos a versão 1.1.0 do Apigee Adapter para Envoy.

Plataformas suportadas

Publicamos ficheiros binários para MacOS, Linux e Windows.

Publicamos imagens Docker do distroless, Ubuntu e Ubuntu com Boring Crypto da Google.

Na versão 1.1.0, suportamos as seguintes plataformas:

  • Apigee Hybrid versão 1.3
  • Versões 1.5, 1.6 e 1.7 do Istio
  • Versões 1.14 e 1.15 do Envoy

Funcionalidades e melhorias

Funcionalidade Descrição
Valide as associações Foi adicionado um novo comando apigee-remote-service-cli bindings verify à CLI. Este comando verifica se o produto de API associado especificado e as respetivas apps de programadores associadas também têm um produto de serviço remoto associado. Consulte Valide uma associação.
Gerar exemplos Foi adicionado um novo comando apigee-remote-service-cli samples create à CLI. Este comando cria ficheiros de configuração de exemplo para implementações nativas do Envoy ou Istio. Os ficheiros de configuração que gera com este comando substituem os ficheiros de exemplo que foram instalados com o adaptador para o Envoy em versões anteriores. Veja o comando Samples.
Autenticação OAuth2 O adaptador usa agora a autenticação OAuth2 quando a autenticação multifator (MFA) está ativada para o Apigee. Use a flag --mfa sempre que usar a flag --legacy.
Contentor sem distribuição O adaptador usa agora a imagem sem distribuição (gcr.io/distroless/base) da Google em vez de scratch para a base da imagem Docker predefinida.

Outros problemas e correções

  • Foi corrigido um problema da CLI para comandos de associações no OPDK. (#29)
  • A quota pode ficar bloqueada quando a ligação é perdida (apigee/apigee-remote-service-envoy). (#31)
  • As imagens do Docker são agora criadas com um utilizador não root (999).
  • Os exemplos do Kubernetes aplicam que o utilizador não pode ser root.
  • O --http1.1 já não é necessário para comandos curl em relação a pontos finais de proxy. A flag foi removida dos exemplos.

v1.0.0

Na sexta-feira, 31 de julho de 2020, lançámos a versão DG do Apigee Adapter para Envoy.

Plataformas suportadas

Publicamos ficheiros binários para MacOS, Linux e Windows.

Publicamos imagens Docker a partir do zero, do Ubuntu e do Ubuntu com Boring Crypto.

Na versão 1.0.0, suportamos as seguintes plataformas:

  • Apigee Hybrid versão 1.3
  • Versões 1.5 e 1.6 do Istio
  • Versões 1.14 e 1.15 do Envoy

Adições e alterações

Entre a versão 1.0-beta4 e a versão GA, foram feitas as seguintes alterações ao adaptador:

  • Go Boring builds

    Já está disponível uma nova compilação que usa bibliotecas Go BoringSSL compatíveis com FIPS.

  • Alterações à flag de nível de registo

    As flags do nível de registo do serviço apigee-remote-service-envoy foram alteradas para garantir a consistência:

    Bandeira antiga Nova denúncia
    log_level log-level
    json_log json-log
  • Novas flags da CLI

    Foram adicionadas novas flags aos comandos da CLI token:

    Bandeira Descrição
    --legacy Defina esta flag se estiver a usar o Apigee Cloud.
    --opdk Defina esta flag se estiver a usar o Apigee para a nuvem privada.