Humanos e m¨¢quinas usam segredos por todo o fluxo de valor ao construir e operar software. As pipelines de compila??o precisam de segredos para fazer interface com infraestruturas seguras como registros de cont¨ºiner, as aplica??es usam chaves de API como segredos para ter acesso aos recursos de neg¨®cio, e as comunica??es servi?o-a-servi?o s?o protegidas usando certificados e chaves como segredos. Voc¨º pode configurar e recuperar esses segredos de maneiras diferentes. Durante muito tempo, alertamos as pessoas desenvolvedoras sobre o uso de gerenciamento de c¨®digo-fonte para armazenar segredos. Recomendamos desacoplar o gerenciamento de segredos do c¨®digo-fonte e usar ferramentas como git-secrets e Talisman para evitar armazenar segredos no c¨®digo-fonte. Temos usado segredos como servi?o como uma t¨¦cnica padr?o para armazenar e acessar segredos. Com essa t¨¦cnica, voc¨º pode usar ferramentas como Vault ou para ler/escrever segredos em um terminal HTTPS com n¨ªveis refinados de controle de acesso. Segredos como servi?o usam provedores de identidade externos como para identificar atores que solicitam acesso a segredos. Esses atores se autenticam com o servi?o de segredos. Para esse processo funcionar, ¨¦ importante automatizar o bootstrapping de identidade dos atores, servi?os e aplica??es. As plataformas baseadas em SPIFFE melhoraram a automa??o de atribui??o de identidades para servi?os.
We've long cautioned people about the temptation to check secrets into their source code repositories. Previously, we've recommended decoupling secret management from source code. However, now we're seeing a set of good tools emerge that offer secrets as a service. With this approach, rather than hardwiring secrets or configuring them as part of the environment, applications retrieve them from a separate process. Tools such as Vault by HashiCorp let you manage secrets separately from the application and enforce policies such as frequent rotation externally.
