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
