Hi Nipuni,
On Fri, May 13, 2016 at 1:15 PM, Nipuni Perera <nip...@wso2.com> wrote:
> 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.
>
Keeping both approaches are useful. Command-line one will be useful for
demos. The preferred production approach can be "password-tmp" file, which
is deleted each time the docker image starts. When the image is burnt we
burn it with the "password-tmp" file.
thanks,
Dimuthu
> Thanks,
> Nipuni
>
> On Wed, May 11, 2016 at 8:18 PM, Inosh Goonewardena <in...@wso2.com>
> 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 <chami...@wso2.com>
>> 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 <m...@wso2.com> 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 <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>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Architecture mailing list
>>>>> Architecture@wso2.org
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Thanks & Regards,
>>
>> Inosh Goonewardena
>> Associate Technical Lead- WSO2 Inc.
>> Mobile: +94779966317
>>
>> _______________________________________________
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> 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>
>
>
> _______________________________________________
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
Dimuthu Leelarathne
Director, Solutions Architecture
WSO2, Inc. (http://wso2.com)
email: dimut...@wso2.com
Mobile: +94773661935
Blog: http://muthulee.blogspot.com
Lean . Enterprise . Middleware
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
