Notas de lançamento do adaptador da Apigee para Envoy

Esta página se aplica à Apigee e à Apigee híbrida.

Confira a documentação da Apigee Edge.

Nesta página, você encontra as notas de lançamento de todos os softwares do adaptador da Apigee para Envoy de 2021 e anos anteriores.

Consulte Adaptador para Envoy para ver As notas de lançamento atuais (2022 em diante).

v2.0.4

Em 3 de dezembro de 2021, lançamos a versão 2.0.4 do adaptador da Apigee para Envoy.

Recursos e melhorias

  • A lista de versões compatíveis do Envoy e do Istio para o comando samples da CLI foi atualizada. Agora estas versões são compatíveis com amostras:
    • Versões do Envoy 1.18 a 1.20
    • Istio 1.10 a 1.12

Problemas corrigidos

  • Adicionamos uma verificação nula para o carregamento da chave privada no bloco PEM para evitar pânico. (Problema 360)
  • Os erros de autorização de serviço remoto agora são registrados no nível de depuração. Há uma exceção a essa categorização para erros de busca de token em chaves de API. Nesse caso, os erros são registrados no nível de erro para que fiquem visíveis mesmo que o nível do registro de depuração de apigee-remote-service-envoy esteja desativado. Consulte também Como configurar níveis de registro de serviço remoto. (Problema 104)

v2.0.3

Em 21 de setembro de 2021, lançamos a versão 2.0.3 do Adaptador da Apigee para Envoy.

Problemas corrigidos

  • Foi corrigido um problema de registro de análises com respostas diretas. O problema ocorria apenas em algumas circunstâncias. Exemplo:
    • Para solicitações que não exigem verificação de Authn/z, nenhum authContext foi gerado e os metadados dinâmicos eram nulos, fazendo com que a entrada de registro de acesso fosse ignorada.
    • A resposta negada usava o código RPC em vez do código HTTP, fazendo com que os registros fossem exibidos na IU da Apigee como sendo bem-sucedidos.

v2.0.2

Em 7 de junho de 2021, lançamos a versão 2.0.2 do adaptador de Apigee para Envoy.

Problemas corrigidos

  • Uma condição de disputa foi corrigida que poderia causar 403 erros e pânico quando os escopos das declarações JWT eram nulos.

v2.0.1

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

Problemas corrigidos

Recurso Descrição
Bug

Foi corrigido um problema que fazia a v2.0.0 falhar quando usada com o a Apigee híbrida v1.5.0 ou Apigee. Se você estiver fazendo upgrade da instalação da Apigee híbrida para a v1.5.x, o caminho de upgrade recomendado para o adaptador será:

  1. Fazer upgrade do adaptador da Apigee para Envoy para a versão v2.0.1.
  2. Fazer upgrade da Apigee híbrida para a v1.5.1.

Se você usa a Apigee, basta fazer upgrade do adaptador para a v2.0.1.

v2.0.0

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

Recursos e melhorias

Recurso Descrição
Suporte ao ambiente multilocatário

Agora é possível ativar o adaptador para atender a vários ambientes em uma organização da Apigee. Esse recurso permite usar um adaptador do Apigee para Envoy associado a uma organização da Apigee para atender a vários ambientes. Antes dessa alteração, um adaptador sempre foi vinculado a um ambiente da Apigee. Para mais informações sobre esse recurso, consulte Suporte ao ambiente multilocatário.
Compatibilidade com a API Envoy v3
Compatibilidade com metadados do Envoy

O Envoy 1.16+ permite o envio de metadados ext_authz sem precisar usar cabeçalhos. Ao usar isso e as alterações relacionadas, agora fornecemos códigos de resposta HTTP melhores para solicitações negadas e não precisamos mais instalar um filtro RBAC no Envoy. Saiba mais em

Esse recurso é compatível apenas com o Envoy 1.16 ou posterior e com o Istio 1.9 ou versões posteriores.

Com essa alteração, a configuração a seguir não é mais adicionada ao arquivo 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 você quiser anexar cabeçalhos a solicitações de um caso especial, basta definir a propriedade append_metadata_headers:true no arquivo config.yaml do adaptador.
Dividir o proxy remote-token do proxy remote-service

O proxy remote-service foi refatorado em dois proxies separados. O provisionamento v2.0.x instalará dois proxies de API: remote-service e remote-token. Os endpoints /token e /certs foram movidos do proxy remote-service para remote-token.

Essa mudança cria uma separação útil das funções. Agora, o proxy remote-service é usado apenas para comunicações internas do adaptador, enquanto o proxy remote-token fornece um exemplo de fluxo de trabalho do OAuth que pode ser personalizado. Nunca substituiremos seu proxy remote-token personalizado, mesmo que o comando provision --force-proxy-install seja usado.

Suporte à captura de dados

Agora, o adaptador é compatível com a transmissão de metadados Envoy para o recurso de captura de dados da Apigee, que envia dados capturados nas variáveis especificadas à Apigee para uso em relatórios personalizados. Esse recurso oferece um recurso semelhante à Política de captura de dados da Apigee. Para mais informações sobre esse recurso, consulte Como capturar dados para relatórios personalizados.

RBAC não obrigatório

Conforme observado anteriormente em Suporte a metadados do Envoy, recusamos imediatamente solicitações não autorizadas sem exigir um filtro RBAC separado. Como o RBAC não é usado, os clientes agora recebem estes códigos de status HTTP conforme apropriado do adaptador:

  • 401 não autorizado
  • 403 Proibido
  • 429 número excessivo de solicitações
  • 500 Internal Server Error

Se você quiser permitir que solicitações não autorizadas continuem, defina auth:allow_unauthorized:true no arquivo config.yaml do adaptador.

Cabeçalhos x-apigee-* não são mais anexados por padrão

Conforme observado anteriormente na seção Suporte a metadados do Envoy, os cabeçalhos x-apigee-* não são mais anexados por padrão. Se você quiser adicioná-las, defina append_metadata_headers:true no arquivo config.yaml. Essa configuração é totalmente opcional e só precisa ser usada quando é recomendado encaminhar cabeçalhos para o serviço de destino upstream.

Correspondência personalizada de uma solicitação a uma operação de produto da API Apigee

A semântica da propriedade de configuração api_header permanece igual à antiga propriedade target_header (o padrão ainda é o nome do host de destino) e o conteúdo do cabeçalho especificado ainda corresponderá ao atributo Destino do serviço remoto ou campo Origem em uma Configuração de operações de produtos de API.

Para modificar esse valor de cabeçalho usando metadados do Envoy, é possível transmitir o elemento de metadados apigee_api do Envoy para o adaptador a fim de especificar diretamente o Destino de serviço remoto do produto de API ou a operação de produtos de API da origem da API. Para configurar, adicione um código semelhante ao seguinte ao arquivo de configuração do Envoy (que pode ser gerado usando a 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
O Analytics para solicitações recusadas é registrado imediatamente

O adaptador do Envoy agora registrará solicitações recusadas imediatamente na análise, conforme a necessidade, em vez de esperar que a solicitação retorne no registro de acesso. Esse recurso é mais eficiente e não requer a anexação de metadados à solicitação.
A compatibilidade com a UDCA foi removida

A transmissão ao Agente Universal de Coleta de Dados (UDCA) da Apigee na Apigee híbrida e a Apigee não é mais necessária para análise porque foi substituída pelo upload direto. Essa alteração apenas remove o suporte legado para essa opção.

Suporte para mTLS adicionado para Edge para nuvem privada nos comandos da CLI de provisionamento/vinculação

Os usuários da Apigee Edge para nuvem privada podem fornecer certificados TLS do cliente e certificado raiz via ‑‑tls‑cert, ‑‑tls‑key e ‑‑tls‑ca, respectivamente, ao provisionar ou listar vinculações de produtos usando a CLI.

Suporte a mTLS entre o adaptador e o ambiente de execução da Apigee

É possível fornecer certificados TLS do lado do cliente na seção tenant do arquivo config.yaml do adaptador para usar mTLS entre o adaptador e o ambiente de execução da Apigee. Essa alteração se aplica a todas as plataformas compatíveis da Apigee. Além disso, permite o mTLS para análise da plataforma Apigee Edge para nuvem privada. Para mais informações, consulte Como configurar o mTLS entre o adaptador e o ambiente de execução da Apigee.

Outros problemas e correções

  • Correção de um problema em que várias configurações de operação com a mesma origem de API tinham os mesmos identificadores de bucket de cota e causavam conflitos no cálculo. (Problema #34)
  • Corrigimos um problema em que operações sem verbos especificados faziam com que a solicitação fosse negada (o comportamento esperado era permitir todos os verbos, caso nenhum fosse especificado). (Problema #39)

v1.4.0

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

Plataformas compatíveis

Publicamos binários para MacOS, Linux e Windows.

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

Nesta versão, as seguintes plataformas são compatíveis:

  • Apigee híbrida 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 Istio 1.5, 1.6, 1.7 e 1.8
  • Versões Envoy 1.14, 1.15 e 1.16

Recursos e melhorias

Recurso Descrição
O proxy remote-service não requer mais associação a um produto de API que usa Destinos de serviço remotos.

Como essa associação não é mais necessária, observe as seguintes alterações:

  • Um produto de API remote-service não é mais criado durante o provisionamento.
  • O comando da CLI bindings verify não é mais relevante e se tornou obsoleto.
O papel de administrador da organização do Apigee não é mais necessário para o provisionamento.

Em vez de exigir a permissão de administrador da organização para o provisionamento, agora é possível usar o papel de criador e implantador da API de papéis do IAM. Você precisa conceder os dois papéis para provisionar com sucesso.
(Aplicável à Apigee apenas no Google Cloud e na Apigee híbrida)

Outros problemas e correções

  • Corrigimos um problema em que o aprovisionamento da Apigee sem a opção --rotate foi encerrado com um erro.
  • A CLI de provisionamento agora lê e reutiliza as credenciais da conta de serviço de análise de um determinado arquivo config.yaml (Problema no 133).

v1.3.0

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

Plataformas compatíveis

Publicamos binários para MacOS, Linux e Windows.

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

Nesta versão, as seguintes plataformas são compatíveis:

  • Apigee híbrida 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 Istio 1.5, 1.6, 1.7 e 1.8
  • Versões Envoy 1.14, 1.15 e 1.16

Recursos e melhorias

Recurso Descrição
Suporte para OperationGroups de produto de API. Os OperationGroups vinculam os recursos e a aplicação de cota associada em um proxy ou serviço remoto a métodos HTTP. Para detalhes, consulte OperationGroup.
(Aplicável à Apigee apenas no Google Cloud e na Apigee híbrida)
Remova a compatibilidade com proxy de encaminhamento dinâmico da geração de amostras. Devido a essa alteração, os clientes precisam incluir o cabeçalho HOST se o nome do host for diferente do host de destino do serviço remoto definido no produto da API. Exemplo: 

curl -i http://localhost:8080/httpbin/headers -H "HOST:httpbin.org"

Consulte Criar um produto de API.

Ofereça suporte a contas de serviço e identidade de carga de trabalho. Para permitir o upload de dados de análise para a Apigee ao executar o adaptador fora de um cluster híbrido da Apigee, é preciso usar o parâmetro analytics-sa com o comando apigee-remote-service-cli provision. Além disso, o adaptador agora é compatível com a Identidade da carga de trabalho no Google Kubernetes Engine (GKE). Consulte o comando de provisionamento.
(Aplicável à Apigee apenas no Google Cloud e na Apigee híbrida)
Novo atributo de configuração jwt_provider_key. Essa chave é adicionada ao arquivo de configuração. Ele representa a chave payload_in_metadata do provedor JWT em Configuração Envoy ou o emissor JWT RequestAuthentication na Configuração do Istio.
O atributo de configuração KeepAliveMaxConnectionAge agora assume o padrão de 1 minuto. O padrão anterior era de 10 minutos. Essa mudança permite um escalonamento mais suave. Esse valor também é usado para a vida útil do stream de registro de acesso. Consulte o arquivo de configuração.
Comandos da CLI removidos. Os comandos da CLI a seguir estão obsoletos. Recomendamos que você use as APIs da Apigee para atualizar os destinos de serviços remotos para os produtos da API:
  • apigee-remote-service-cli bindings add
  • apigee-remote-service-cli bindings remove
Novo comando da CLI: O comando: 

apigee-remote-service-cli samples templates

lista as opções disponíveis que podem ser usadas com a sinalização --template no comando samples create. Consulte a referência da CLI.
O comando da CLI atual foi alterado. Uma alteração foi feita no comando apigee-remote-service-cli samples create. As sinalizações específicas dos modelos Envoy ou Istio são estritamente verificadas, e os erros são retornados em sinalizações usadas incorretamente. A opção de modelo native está suspensa. Para ver uma lista dos modelos disponíveis, use o comando apigee-remote-service-cli samples templates. Consulte também a Referência de CLI.
A resposta do endpoint /token agora segue a especificação do OAuth2. O parâmetro access_token foi adicionado à resposta e o parâmetro token está obsoleto.

v1.2.0

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

Plataformas compatíveis

Publicamos binários para MacOS, Linux e Windows.

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

Nesta versão, as seguintes plataformas são compatíveis:

  • Apigee híbrida versão 1.3.x
  • Istio 1.5, 1.6 e 1.7
  • Envoy 1.14, 1.15

Recursos e melhorias

Recurso Descrição
Suporte para Apigee no Google Cloud Agora é possível usar o adaptador da Apigee para Envoy com a Apigee no Google Cloud. Agora é possível usar o adaptador da Apigee para Envoy com a Apigee no Google Cloud. Provisione o adaptador na Apigee usando o comando de provisionamento.
Upload direto de dados de análise Agora é possível configurar o adaptador da Apigee para fazer upload de dados de análise diretamente para a Apigee. Se você estiver usando a Apigee híbrida, esse novo recurso permite implantar o adaptador no próprio cluster do Kubernetes, fora do cluster em que a Apigee híbrida está instalada. Para ativar o upload direto, use a nova sinalização --analytics-sa com o comando provision. Consulte o comando de provisionamento.
A verificação de integridade retorna "Pronto" depois que os dados do produto da API são carregados da Apigee A verificação de integridade do Kubernetes não retornará "Pronto" até que os dados do produto da API sejam carregados da Apigee. Essa alteração ajuda no escalonamento e no upgrade porque nenhum tráfego será enviado ao adaptador recém-instanciado até que esteja pronto.

Outros problemas e correções

  • Correção de um problema para resolver um possível impasse da sincronização de cotas (problema 17, link em inglês).
  • As anotações do Prometheus foram movidas para a especificação de pod (problema 69, link em inglês).
  • Corrigimos um problema para resolver erros de verificação emitidos incorretamente (problema 62, link em inglês).

v1.1.0

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

Plataformas compatíveis

Publicamos binários para MacOS, Linux e Windows.

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

Na versão 1.1.0, oferecemos suporte para as seguintes plataformas:

  • Apigee híbrida versão 1.3
  • Istio 1.5, 1.6 e 1.7
  • Envoy 1.14, 1.15

Recursos e melhorias

Recurso Descrição
Verificar vinculações Um novo comando apigee-remote-service-cli bindings verify foi adicionado à CLI. Esse comando verifica se o produto de API vinculado especificado e os aplicativos de desenvolvedor associados também têm um produto de serviço remoto associado a eles. Consulte Verificar uma vinculação.
Gerar amostras Um novo comando apigee-remote-service-cli samples create foi adicionado à CLI. Ele cria amostras de arquivos de configuração para implantações nativas do Envoy ou do Istio. Os arquivos de configuração gerados com este comando substituem os arquivos de amostra que foram instalados com o adaptador do Envoy nas versões anteriores. Consulte o comando de amostra.
Autenticação do OAuth 2.0 O adaptador agora usa a autenticação OAuth2 quando a autenticação multifator (MFA) está ativada para a Apigee. Use a sinalização --mfa sempre que usar a sinalização --legacy.
Contêiner distroless O adaptador agora usa a imagem distroless do Google (gcr.io/distroless/base) em vez de scratch para a base de imagem do Docker padrão.

Outros problemas e correções

  • Um problema de CLI foi corrigido para comandos de vinculação em OPDK. (#29)
  • A cota pode ficar paralisada quando a conexão foi perdida (apigee/apigee-remote-service-envoy). (#31)
  • As imagens do Docker agora são criadas com um usuário não raiz (999).
  • As amostras do Kubernetes aplicam o usuário que não pode ser raiz.
  • O --http1.1 não é mais necessário para comandos curl em endpoints de proxy. A sinalização foi removida dos exemplos.

v1.0.0

Na sexta-feira, 31 de julho de 2020, lançamos a versão GA do adaptador da Apigee para Envoy.

Plataformas compatíveis

Publicamos binários para MacOS, Linux e Windows.

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

Na versão 1.0.0, oferecemos suporte para as seguintes plataformas:

  • Apigee híbrida versão 1.3
  • Istio 1.5, 1.6
  • Envoy 1.14, 1.15

Adições e alterações

Entre a versão v1.0-beta4 e o GA, as seguintes alterações de adição foram feitas no adaptador:

  • Compilações de "Go Boring"

    Uma nova versão já está disponível e usa bibliotecas Go BoringSSL compatíveis com o FIPS.

  • Mudanças na sinalização de nível de registro

    As sinalizações de nível de registro para o serviço apigee-remote-service-envoy foram alteradas para fins de consistência:

    Sinalização antiga Nova sinalização
    log_level log-level
    json_log json-log
  • Novas sinalizações da CLI

    Novas sinalizações foram adicionadas aos comandos da CLI token:

    Sinalização Descrição
    --legacy Defina essa sinalização se você estiver usando a Apigee Cloud.
    --opdk Defina essa sinalização se você estiver usando a Apigee para nuvem privada.