Hi All,
The meeting minutes of the discussion held on 14th September 2020
*Topic:* POC Implementation on External vault Support for carbon
configurations
*Participant:* Ruwan Abeykoon, Deependra Ariyadewa, Malithi Edirisinghe,
Hasintha Indrajee, Buddhima Udaranga, Sahan Gunathilaka, Sumedhe
Dissanayake, Suresh Peris
Presented the POC level implementation that has been done in order to
retrieve multiple Secret repositories from the external vault providers.
*Suggestions*
- Replacing the *" - " *with any other valid separator when using the *"
$secret " *annotation
$secret{vault-hashicorp-admin_password} => since the toml parser is
identifying the* ": " * as an operator, it cannot be used as the separator.
Therefore it is required to identify any valid character that can be used
with the toml parser.
- Using a single provider for all the repositories
Currently, there are two repository providers as file and vault. Since
there will be no amendments to the legacy implementation, it is required to
maintain separate repository providers.
- Finding a means to connect the repositories to the server
It was being suggested to use Java SPI for registering
- Handling the failures that might occur when trying to connect with the
networking endpoints
Using System exceptions or Bailing out mechanism is suggested
- Secrets Storing
ideally, it is not recommended to cache the secrets once it is used it
should be disposed of apart from certain exceptions such as dB pool
The Zoom meeting Recording
<https://drive.google.com/file/d/1cv9tlIXsKcCrMzmMr52wetL-FpwhCGHa/view?usp=sharing>and
the Presentation
<https://docs.google.com/presentation/d/1dqRjtNwm4ecizQ0OJyMuQpb_zGsMiIZ3yuTf167ejWc/edit?usp=sharing>
are
being attached here
On Fri, Sep 11, 2020 at 10:07 AM Sanduni Nagahage (Intern) <
[email protected]> wrote:
> 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) [email protected]
> [image: http://wso2.com/signature] <http://wso2.com/signature>
>
--
Sanduni Nagahage | Trainee Software Engineer | WSO2 Inc.
(m) +94 71 090 8988 | (e) [email protected]
[image: http://wso2.com/signature] <http://wso2.com/signature>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
