Notas de lançamento do adaptador da Apigee para Envoy

Esta é a documentação do Apigee Edge.
Acesse Documentação da Apigee X. informações

v2.1.1

Em 7 de junho de 2023, lançamos a versão 2.1.1 do adaptador da Apigee para Envoy.

Problemas corrigidos

  • Foi corrigido um problema em que as cotas eram duplicadas incorretamente entre as operações em vez de serem compartilhadas no nível do produto.

v2.1.0

Em 5 de junho de 2023, lançamos a versão 2.1.0 do adaptador da Apigee para Envoy.

Problemas corrigidos

  • A declaração application_id foi adicionada à resposta /verifyApiKey.

v2.0.7

Em 9 de março de 2023, lançamos a versão 2.0.7 do adaptador da Apigee para Envoy.

Recursos e melhorias

  • Os JWTs agora podem adicionar uma declaração chamada customattributes que transmitirá o valor. no destino em um cabeçalho chamado x-apigee-customattributes (se append_metadata_headers está configurado como true).

Problemas corrigidos

  • Foi corrigido um problema que fazia com que uma chave de API inválida criasse análises e entradas de registro falsas registros.
  • Uma verificação de versão descontinuada foi removida de um proxy e causou problemas nas versões mais recentes do a Apigee.

v2.0.6

Em 18 de outubro de 2022, lançamos a versão 2.0.6 do adaptador da Apigee para Envoy.

Problemas corrigidos

  • Versão de segurança para resolver uma vulnerabilidade de negação de serviço (DoS) em uma biblioteca de dependências. Consulte CVE-2022-28948 (em inglês).

v2.0.5

Em 3 de março de 2022, lançamos a versão 2.0.5 do adaptador da Apigee para Envoy.

Problemas corrigidos

  • Versão de segurança para lidar com um risco de negação de serviço (DoS) na biblioteca do Prometheus. Consulte CVE-2022-21698 (em inglês).

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.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. Confira

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

Disponível apenas para Apigee X e Apigee híbrida.

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.
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 um destino de serviço remoto

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 de serviço remoto do produto da API ou o campo apiSource em uma Operação de produto de API (somente Apigee híbrida e Apigee X).

Para substituir esse valor de cabeçalho usando metadados do Envoy, transmita o apigee_api de metadados do Envoy para o adaptador para especificar diretamente o Destino de serviço remoto do produto da API ou Origem da API da operação do produto 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. Este é mais eficiente e não exige 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 X 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.

Problemas corrigidos

  • 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 Edge para Public Cloud, Apigee Edge para Private Cloud 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, 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 Edge para Public Cloud, Apigee Edge para Private Cloud 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.
(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 mudança, os clientes precisam incluir o cabeçalho HOST se o nome do host for diferente do host de destino de serviço remoto definido no produto da API. Por 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 o APIs Edge em vez disso, para atualizar destinos de serviço remoto para produtos de 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, 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, 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 Edge. 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, 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 o Apigee Edge Cloud.
    --opdk Defina essa sinalização se estiver usando o Apigee Edge para nuvem privada.