Hi Shankar,
On Fri, Jul 1, 2016 at 6:29 PM, Selvaratnam Uthaiyashankar <[email protected] > wrote: > Hi Sameera, > > > > On Fri, May 13, 2016 at 12:43 PM, Sameera Jayasoma <[email protected]> > 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. >> > > > There is an operational issue here. A component should be a self > contained. If the component author introduced a secret alias, he shouldn't > update in a "central" secret.properties. Not all the people will have write > access to the repo having "central" secret.properties, so they should send > PR if they have to update that file. That will break the component self > contained model. Can we keep the secret.properties fragments with the > component itself and merge when installing the features? > +1 for the fragments approach. With this approach components will introduce a set of files. Thats is the only concern. Anyway as per our discusion, I will start another thread to discuss this aspect. Thanks, Sameera. > > > >> 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. >> >> 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 <[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> >>> >>> >> >> >> -- >> Sameera Jayasoma, >> Software Architect, >> >> WSO2, Inc. (http://wso2.com) >> email: [email protected] >> blog: http://blog.sameera.org >> twitter: https://twitter.com/sameerajayasoma >> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections >> Mobile: 0094776364456 >> >> Lean . Enterprise . Middleware >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > S.Uthaiyashankar > VP Engineering > WSO2 Inc. > http://wso2.com/ - "lean . enterprise . middleware" > > Phone: +94 714897591 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Sameera Jayasoma, Software Architect, WSO2, Inc. (http://wso2.com) email: [email protected] blog: http://blog.sameera.org twitter: https://twitter.com/sameerajayasoma flickr: http://www.flickr.com/photos/sameera-jayasoma/collections Mobile: 0094776364456 Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
