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
