1) Why some files are properties files and some yaml ?
2) I have, in many a time, forgotten to capitalize something and wasted
hours to find it. So I personally like everything in lowercase.
3) I still feel C4 xpath approach is cleaner. The "alias" is deceptively
slimier to an xpath, yet offers no clue, one has to grep to find the real
place.
eg:
carbon.yml
----------
id: carbon-kernel #Value to uniquely identify a server
name: WSO2 Carbon Kernel #Server Name
version: 5.1.0-SNAPSHOT #Server Version
tenant: default #Tenant Name
# keystore used by this server
security:
keystore:
password: *****
secret.yml
-----------
carbon.yml.security.keystore.password=[wso2carbon]
4) Maybe, in a containerized environment, these values should come form
kubernetes secrets [1]. There is a mail on this.
[1] http://kubernetes.io/docs/user-guide/secrets/
On Wed, May 4, 2016 at 9:22 AM, Nipuni Perera <[email protected]> wrote:
> Hi all,
>
> We are trying to add Carbon secure-vault support to C5.
>
> We have done some changes to the way how we configure ciphertool and
> securevault in C5 compared to C4. Please find the new design details below:
>
> There are two configuration files that we maintain for Ciphertool and
> Securevault:
>
> [1]. *secrets.properties* - This file will contains the secret-allias
> and secrets (encrypted/or plain-text). Act as the file-based secret
> repository. We define all the passwords/secrets which need to be secured in
> this file.
> eg: SecureVault.Keystore.Password=[wso2carbon]
> Carbon.Security.KeyStore.Password=[somepassword]
>
> [2]. *secure-vault.yaml* - This file will have the main
> configurations (eg: default secret repository implementation, default
> Callbackhandler implementation etc)
> eg: carbon.secretProvider:
> org.wso2.securevault.secret.handler.SecretManagerSecretCallbackHandler
> keystore.identity.type: JKS
> keystore.identity.store.password: identity.store.password
>
> The CipherTool will be used for creating encrypted values for given plain
> text secrets in the *secrets**.properties* [1].
>
> If a user need to make a value secure,
>
> 1. they have to add a unique name (alias) to their carbon
> configuration element (eg: a value of an element in carbon.yml)
> 2. add the same unique-name along with the plain-text password to the
> *secrets.properties* file.
>
> *Example:*
>
> Assume that we need to secure a value "password" under element
> "Security/Keystore" in Carbon.yml configuration. First we add a unique a
> alias as the value to the Password as below [3]. Second we add that unique
> alias with its plain text password to *secrets*.properties file[4].
>
> CipherTool will encrypt the plain-text password and replace the plain-text
> password with the encrypted value. (In c4 we have added plain-text
> passwords within square brackets. If not they are identified as encrypted
> values).
>
> When loading the carbon.yml (or any other custom configuration file), we
> read the secured values using secure-vault service. This secure vault
> service will either return the password from the *secrets*.properties
> file if the secret is not encrypted, OR return the encrypted value.
>
> [3]
> ################################################################################
>
> id: carbon-kernel #Value to uniquely identify a server
> name: WSO2 Carbon Kernel #Server Name
> version: 5.1.0-SNAPSHOT #Server Version
> tenant: default #Tenant Name
>
> # Keystore used by this server
> Security:
> Keystore
> Password: Carbon.Security.Keystore.Password
>
>
> ###############################################################################
>
> [4] Carbon.Security.Keystore.Password=[wso2carbon]
>
>
> *New design decisions taken compared to C4 SecureVault implementation:*
>
> 1. We have removed the usage of cipher-tool.properties file. (This
> file was used to keep the alias, the location to the configuration file,
> and the xpath to the secret element in the configuration file).
> 2. We can support any format of configuration file with this model as
> we only care about the secret-key that we define in the
> *secrets*.properties
> file and do not depend on the xpath to find the location of the secret
> element.
>
> Thanks,
> Nipuni
>
> --
> Nipuni Perera
> Software Engineer; WSO2 Inc.; http://wso2.com
> Email: [email protected]
> Git hub profile: https://github.com/nipuni
> Blog : http://nipunipererablog.blogspot.com/
> Mobile: +94 (71) 5626680
> <http://wso2.com>
>
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
With regards,
*Manu*ranga Perera.
phone : 071 7 70 20 50
mail : [email protected]
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
