Azure-sdk-for-java: [BUG] O método KeyVaultPropertySource Class / getPropertyNames carregará todos os segredos (incluindo desativar os segredos) no cofre da chave
Descreva o bug
Atualmente, o cofre de chaves habilita o recurso de exclusão reversível por padrão. Se criar / excluir o certificado, o aplicativo Jave travará porque carregou o segredo desabilitado.
A classe KeyVaultPropertySource carrega todos os segredos no KeyVault. Não deve carregar segredos desativados no método getPropertyNames
A propósito, a solução alternativa é limpar o certificado. Mas ainda pode melhorá-lo na parte do SDK porque não há solicitação para carregar o segredo excluído por software
Exceção ou Stack Trace
Adicione o registro de exceção e o rastreamento de pilha, se disponível
Reproduzir
Passos para reproduzir o comportamento:
A. Criou certificados KeyVault (não secretos) e excluiu os certificados depois que o aplicativo java travou.
C. os certificados criam automaticamente um identificador secreto ao criar novos certificados
D. E depois de excluir o certificado, o sistema Azure DESATIVAR o identificador secreto
E. Nesse caso, o aplicativo java tenta ler o segredo DESATIVADO em tempo de execução
eu. E então o aplicativo Java travou.
A biblioteca é com.microsoft. azure: azure-keyvault : 1.2.2
Fragmento de código
Adicione o trecho de código que causa o problema.
@Value ("$ {cluster-app-sb-connection-string}")
String connectionString;
@Value ("$ {cluster-app.sb.topic-name}")
String topicName;
Comportamento esperado
Uma descrição clara e concisa do que você esperava que acontecesse.
Capturas de tela
Se aplicável, adicione capturas de tela para ajudar a explicar seu problema.
Configuração (preencha as seguintes informações):
- SO: [por exemplo, iOS]
- IDE: [por exemplo, IntelliJ]
- Versão da biblioteca usada
Contexto adicional
Adicione qualquer outro contexto sobre o problema aqui.
Lista de verificação de informações
Certifique-se de adicionar todas as informações a seguir acima e verificar os campos obrigatórios, caso contrário, trataremos o emissor como um relatório incompleto
- [x] Descrição do bug adicionada
- [] Etapas de reprodução adicionadas
- [] Informações de configuração adicionadas
TonySh127-ms
Todos 10 comentários
@ TonySh127-ms você está usando o key vault starter ou o SDK diretamente?
saragluna
em 14 ago. 2020
Discutido com @ TonySh127-ms offline e o cliente usou o spring-boot-starter para keyvault. Precisa de confirmação por parte do SDK de que se o novo SDK resolve esse tipo de problema.
saragluna
em 17 ago. 2020
@AlexGhiondea @ vcolin7 pode fazer um acompanhamento?
joshfree
em 17 ago. 2020
obrigado @joshfree e @saragluna. Aguardando atualização de @AlexGhiondea e @ vcolin7 . Por favor, deixe-me saber se não puder ser corrigido em um curto prazo. Posso explicar para o lado do cliente. Muito obrigado pelo seu tempo novamente!
TonySh127-ms
em 18 ago. 2020
Olá @ TonySh127-ms,
Passei algum tempo examinando esse problema e descobri o seguinte: o comportamento que o cliente vê é causado pelo modo como funciona o iniciador Spring Boot para Key Vault Secrets. Basicamente, sempre que um aplicativo Spring usando este starter é executado, ele obterá os nomes de todos os segredos existentes em um determinado vault chamando o endpoint / secrets, que carrega todos os segredos ativados e desativados (não os excluídos), o aplicativo irá então recupere detalhes de segredos específicos, se necessário. Não é um problema com o serviço Key Vault ou SDK, mas apenas uma consequência de como o Spring Boot starter é codificado.
Uma solução de curto prazo não é usar o Spring Boot starter, mas o próprio Key Vault SDK diretamente. Dessa forma, o cliente terá mais controle sobre quais segredos são carregados e quando durante o ciclo de vida de um aplicativo.
Além disso, não consegui reproduzir um caso em que meu aplicativo travou ao carregar muitos segredos apenas ao criar e excluir um certificado em um cofre. Para fazer algo assim, eu precisaria de mais informações do cliente: quais dependências eles usam em seu projeto, incluindo versões e código de amostra onde isso pode ser reproduzido.
vcolin7
em 19 ago. 2020
@ vcolin7 temos uma opção de passar para o SDK que carregue apenas segredos habilitados? Parece que não devemos carregar os segredos desabilitados em nossa integração Spring.
saragluna
em 20 ago. 2020
@saragluna Infelizmente, não há nenhum parâmetro que possamos passar o serviço para que ele nos forneça apenas os segredos habilitados: /
vcolin7
em 20 ago. 2020
O problema é causado pela forma como o iniciador Spring Boot para Key Vault Secrets funciona. não filtramos segredos desativados. agora eu crio um PR para corrigir o problema
zhoufenqin
em 25 ago. 2020
@ TonySh127-ms
Nós construímos um pacote dev , você pode tentar.
Siga esta página para baixar o pacote dev
zhoufenqin
em 28 ago. 2020
Olá equipe, o problema foi confirmado como corrigido. Podemos fechar este tópico agora. Muito obrigado a todos, grande esforço e tempo !!!
TonySh127-ms
em 8 set. 2020
Questões relacionadas
valmol
·
4Comentários
shubhambhattar
·
4Comentários
ronny-sphera
·
3Comentários
abhikt48
·
3Comentários
dkirrane
·
4Comentários
Comentários muito úteis
O problema é causado pela forma como o iniciador Spring Boot para Key Vault Secrets funciona. não filtramos segredos desativados. agora eu crio um PR para corrigir o problema