Hi All, While looking more into this, I found that AWS has AWS Key Management Service (KMS), Kubernetes has support for secrets [1] and there are other secret management tools like Hashivalut[3].
For the moment securevault scenario is more coupled with cipher tool. When ciphertool is run, it creates the secret-conf.properties file. Which then be used in the server startup to check whether securevault is enabled. IMO, these two should be decoupled and should have capability to work with mentioned third party secret managers. WDYT? [1] https://aws.amazon.com/kms/ [2] http://kubernetes.io/docs/user-guide/secrets/ [2] https://github.com/hashicorp/vault Thanks, Jayanga. *Jayanga Dissanayake* Associate Technical Lead WSO2 Inc. - http://wso2.com/ lean . enterprise . middleware email: jaya...@wso2.com mobile: +94772207259 On Fri, Jul 1, 2016 at 10:59 PM, Sameera Jayasoma <same...@wso2.com> wrote: > Hi Shankar, > > > On Fri, Jul 1, 2016 at 6:29 PM, Selvaratnam Uthaiyashankar < > shan...@wso2.com> wrote: > >> Hi Sameera, >> >> >> >> On Fri, May 13, 2016 at 12:43 PM, Sameera Jayasoma <same...@wso2.com> >> 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 <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> >>>> >>>> >>> >>> >>> -- >>> Sameera Jayasoma, >>> Software Architect, >>> >>> WSO2, Inc. (http://wso2.com) >>> email: same...@wso2.com >>> 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 >>> Architecture@wso2.org >>> 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 >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Sameera Jayasoma, > Software Architect, > > WSO2, Inc. (http://wso2.com) > email: same...@wso2.com > 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 > 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
