Hi All, The External Vault Support for Carbon Configurations is a project intended to extend the existing Secure Vault capabilities to cater for the external vaults such as AWS Secret Manager, Azure Key vault and HashiCorp Vault and Hardware Security Modules etc. However the existing implementation cannot be extended to cater this requirement. Therefore it is required to build an extendable support for the Identity Server to connect with the external secret providers in order to use their vault infrastructures.
Currently, the existing secure vault is supported only for the FileBaseSecretRepository but with this extended capability we can use multiple vaults to store our secrets simultaneously. While keeping the legacy implementation parallelly. This parallel implementation will be obtained by enabling a configuration so that it can be reverted to the legacy behaviour whenever a need arises. The main three components require modification to retrieve the expected behavior is, - The Secret Manager which is the entry point for managing secrets in the Secure Vault. This will direct to the relevant Secret Provider based on the value obtained from configuration properties and maintains a list of initialized Secret Repositories to be used to get secrets. - The Secret Provider acts as an central management which will initialize the Secret Repositories given under that specific Secret Provider in the configuration properties by passing the relevant properties and returns an initialized Secret repository array. - The Secret repository is the component responsible for fetching the secrets from the external vaults by taking the alias of that secret as an argument. According to that, there are providers based on secret storing mechanisms (Filebase, Vaultbase, HSMbased etc.) and each of these providers will handle several repositories Eg: Filebase - file (legacy repository) Vaultbase - AWS, Hashicorp, Azure etc. You can find how the suggested approach will exists with the legacy implementation from here <https://drive.google.com/file/d/1XML-ZqMJ_jPN0XwLI83v7a3w8RT7Eevj/view?usp=sharing> During the resolving process of the secrets the relevant provider will call upon to resolve that particular secret. In order to define the required provider and the repository type, the *"$secret"* annotation will be modified as, $secret { alias } : $secret { provider: repository: alias } * $secret { admin_password } : $secret { Vault : aws : admin_password }* You can find the illustration for the suggested approach from here <https://drive.google.com/file/d/1mivRKx7tqiQeqzD93rMq8DcKuGht38k5/view?usp=sharing> Thanks & Regards -- Sanduni Nagahage | Trainee Software Engineer | WSO2 Inc. (m) +94 71 090 8988 | (e) sandu...@wso2.com [image: http://wso2.com/signature] <http://wso2.com/signature>
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
