Hi Sameera,
On Fri, May 13, 2016 at 12:43 PM, Sameera Jayasoma <same...@wso2.com> wrote:
> Hi All,
>
> We introduced this new design to solve the issues in the previous secure
> vault implementation. We've simplified the configuration of secure vault
> module with this new design.
>
> Now we don't maintain passwords or any sensitive data in the configuration
> files. All such data should be maintained in the *secret.properties*
> file. We will see whether we can use YAML as the file format here.
>
> When you develop Carbon components and if you happen to introduce configs
> which contain passwords, you shouldn't put the actual password there. Just
> put a secret alias in your config file and add an entry the
> secret.properties file.
>
There is an operational issue here. A component should be a self contained.
If the component author introduced a secret alias, he shouldn't update in a
"central" secret.properties. Not all the people will have write access to
the repo having "central" secret.properties, so they should send PR if they
have to update that file. That will break the component self contained
model. Can we keep the secret.properties fragments with the component
itself and merge when installing the features?
> This should happen at the development time. End users do not need to worry
> such configurations. But if they want to change passwords, they can change
> them only in the secret.properties file.
>
> e.g. Consider the carbon.yml file. You should put a secret alias such as,
>
> password: ${secvault:carbon.security.keystore.password}
>
> Now you need put an entry in the secret.properties file as follows.
>
> carbon.security.keystore.password=[wso2carbon]
>
>
> Thanks,
> Sameera.
>
>
> On Wed, May 4, 2016 at 6:52 PM, Nipuni Perera <nip...@wso2.com> 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: nip...@wso2.com
>> Git hub profile: https://github.com/nipuni
>> Blog : http://nipunipererablog.blogspot.com/
>> Mobile: +94 (71) 5626680
>> <http://wso2.com>
>>
>>
>
>
> --
> Sameera Jayasoma,
> Software Architect,
>
> WSO2, Inc. (http://wso2.com)
> email: same...@wso2.com
> blog: http://blog.sameera.org
> twitter: https://twitter.com/sameerajayasoma
> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections
> Mobile: 0094776364456
>
> Lean . Enterprise . Middleware
>
>
> _______________________________________________
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
S.Uthaiyashankar
VP Engineering
WSO2 Inc.
http://wso2.com/ - "lean . enterprise . middleware"
Phone: +94 714897591
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
