Hi
Since we do have generalized concept across the platform with C5, we
should focus not only how to deal with static config but also it is greatly
important to see how runtime configs get secured when it's necessary such
as for securing connector, data source configs (runtime) etc as Kasun
emphasis
As FYI,ESB current version having "password tool" which uses the same
secure vault concept but only for ESB runtime configs (there we have
discussed how would the concept broadly used on other products but AFAIK
that was never implemented)
Therefore, it would be much easier when architecting/designing secure
vault, preparing a set of standard guidance for C5 base products which may
heavily depend on runtime configs (may be defined common interface? or may
be pluggable runtime?), especially next gen ESB, Identity Bus, Data
Integration Server and other products may or will be asking this question.
Cheers,
Dushan
On Wed, May 18, 2016 at 10:24 AM, Kasun Indrasiri <ka...@wso2.com> wrote:
> 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/
>
--
Dushan Abeyruwan | Technical Lead
PMC Member Apache Synpase
WSO2 Inc. http://wso2.com/
Blog:*http://www.dushantech.com/ <http://www.dushantech.com/>*
LinkedIn:*https://www.linkedin.com/in/dushanabeyruwan
<https://www.linkedin.com/in/dushanabeyruwan>*
Mobile:(001)408-791-9312
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
