Hi Inosh,

Yes we will be using CallBackHandlers to resolve the passwords. We are
still discussing the approach of adding keystore password using a file or
command-line (which we have practiced in C4) as this cause issues in docker
environment.

Thanks,
Nipuni

On Wed, May 11, 2016 at 8:18 PM, Inosh Goonewardena <[email protected]> wrote:

> How does the passwords encrypted/decrypted? Does the carbon server's
> primary keystore will still be used?
> If so, does the DefaultSecretCallbackHandler is still used as the password
> resolver for the keystore/private key passwords as in C4 where we need to
> provide keystore/private key password using a file or in command line?
>
>
> On Wed, May 11, 2016 at 7:26 PM, Chamila De Alwis <[email protected]>
> wrote:
>
>> Is there a particular reason to make the secrets file a properties file?
>> I agree with Manuranga that it can also be made a YAML file, so the users
>> will be working with a consistent format when it comes to configuration.
>>
>> It would be easier for the user if a layer exists on top of this
>> implementation that automates the process to include the secret alias and
>> the password in the secrets file. Currently, it's a two-step process, which
>> can result in typos.
>>
>> ex:
>>
>>    1. Cipher Tool has a list of conf files that it should scan This can
>>    be modified if needed.
>>    2. Instead of the plain text password ("plainTextPassword"), the user
>>    enters a string of format "secret.conf.plainTextPassword"  in the conf
>>    file.
>>    3. When the Cipher Tool is run,
>>    1. it scans the conf files
>>       2. picks up the fields prefixed with "secret.conf"
>>       3. encrypts the remaining part of the string
>>       4. generates a unique alias
>>       5. replaces the "secret.conf.plainTextPassword" with the
>>       generated alias
>>       6. inserts the alias: encrypted password to secrets file
>>
>>
>> This way, the user doesn't have to manually come up with unique aliases,
>> and make user they match in the conf and the secrets file. And it eases the
>> process of encrypting secrets.
>>
>>
>> Regards,
>> Chamila de Alwis
>> Committer and PMC Member - Apache Stratos
>> Software Engineer | WSO2 | +94772207163
>> Blog: code.chamiladealwis.com
>>
>>
>>
>> On Wed, May 4, 2016 at 7:47 PM, Manuranga Perera <[email protected]> wrote:
>>
>>> 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
>>>
>>>
>>
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Thanks & Regards,
>
> Inosh Goonewardena
> Associate Technical Lead- WSO2 Inc.
> Mobile: +94779966317
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
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

Reply via email to