Hi,
One of the other related area is how do we use credentials in configuration
artifacts (similar to connectors, data service scripts etc.). I think that
is more frequently used/changed than the static configuration files (static
config is more or less a dev-ops task while artifact level configuration is
done by the developers). So, we need to consider that aspect as well.
On Mon, May 16, 2016 at 11:41 PM, Srinath Perera <srin...@wso2.com> wrote:
> Manu, I prefer the approach Sameera mentioned as it is independent of the
> config file and will work with any future config file as well.
>
> --Srinath
>
> On Fri, May 13, 2016 at 7:26 PM, Manuranga Perera <m...@wso2.com> wrote:
>
>> 1)
>>
>>> 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.
>>
>> +1 for having in one file and not having to change in multiple places.
>>
>> 2)
>> Have you considered not having an alias, instead using path
>>
>> *carbon.yml file*
>>
>> security:
>> keystore:
>> password:
>>
>> *secret.properties file*
>>
>> carbon-yml.security.keystore.password=[wso2carbon]
>>
>>
>>
>> On Fri, May 13, 2016 at 4:07 AM, Niranjan Karunanandham <
>> niran...@wso2.com> wrote:
>>
>>> Hi all,
>>>
>>> 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. 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.
>>>>
>>> +1 to have a the sensitive data in one file since it will easy to
>>> maintain.
>>>
>>>
>>>
>>>> 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
>>>>
>>>>
>>>
>>> Regards,
>>> Nira
>>> --
>>>
>>> *Niranjan Karunanandham*
>>> Senior Software Engineer - WSO2 Inc.
>>> WSO2 Inc.: http://www.wso2.com
>>>
>>
>>
>>
>> --
>> With regards,
>> *Manu*ranga Perera.
>>
>> phone : 071 7 70 20 50
>> mail : m...@wso2.com
>>
>> _______________________________________________
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> ============================
> Srinath Perera, Ph.D.
> http://people.apache.org/~hemapani/
> http://srinathsview.blogspot.com/
>
> _______________________________________________
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
Kasun Indrasiri
Software Architect
WSO2, Inc.; http://wso2.com
lean.enterprise.middleware
cell: +94 77 556 5206
Blog : http://kasunpanorama.blogspot.com/
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
