karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Nierbeck <bcanh...@googlemail.com>
Subject Re: Proposal: property placeholder to delegating crypto to external services
Date Tue, 09 Dec 2014 14:07:20 GMT
Hi,

I kinda like the idea, I would prefer a "service" oriented architecture for
that ;)
So we can exchange the AWS/Cloud centric solution with a standalone one and
vice versa.

regards, Achim


2014-12-09 14:51 GMT+01:00 Jean-Baptiste Onofré <jb@nanthrax.net>:

> Hi Chad,
>
> as already quickly discussed, it sounds like a good proposal.
>
> It's a bit maybe too much cloud oriented to be in Karaf core distribution,
> but part of the encryption feature why not.
> It would be great to have a more standalone service (we have a Jira about
> this) for Karaf standalone (without cloud relationship).
>
> Do you already have something to review ?
>
> Regards
> JB
>
>
> On 12/09/2014 02:37 PM, Chad Loder wrote:
>
>>    Hello,
>>
>>
>> When deploying Karaf to production in the cloud, one often has to provide
>> configuration to containers where some of the config properties are secrets
>> (for example, database passwords, secret keys, API keys, etc.). Karaf has
>> support for symmetric encryption of properties using jasypt, which is
>> helpful, but still leaves the problem of securely distributing the
>> encryption keys to the container.
>>
>>
>> This distribution of encryption keys can be done in Amazon AWS using a
>> variety of means including instance metadata, puppet, etc., but all of
>> these methods have the disadvantage of propagating encryption key
>> information throughout the environment, including the on-premise Continuous
>> Integration servers. This is not that difficult to accomplish when systems
>> are first deployed, but it you want to rotate encryption keys and use
>> something like Karaf dynamic reconfiguration via Config Admin, you now have
>> to find a secure way to distribute the newly rotated keys to the Karaf
>> instances. Instance metadata can't be updated for systems already started,
>> so you're now faced with the prospect of having to use Puppet to push
>> encryption keys prior to pushing new container configuration.
>>
>>
>> A better way would be to utilize a crypto service where keying
>> information never leaves the boundaries of a trusted device or service.
>> Amazon provides two built-in  mechanisms for this purpose: CloudHSM and
>> their newly-announced KSM (Key Management Service). The basic idea is that
>> one or more dedicated, named keys would be created within the KSM, and
>> secret properties would be encrypted by calling the Encrypt function of the
>> KMS: "Encrypt this blob with the latest version of the key named by the
>> alias ABC-XYZ". The encrypted blob would be stored in the config file using
>> a namespace like ENC, so:
>>
>>
>> <cm:property name="mydb.password" value="ENC(xxxxxx)"/>
>>
>>
>> where xxxxxx is the ciphertext. And then ENC namespace would be defined
>> using a declaration of:
>>
>>
>> xmlns:enc="http://karaf.apache.org/xmlns/kms-enc/v1.0.0"
>>
>>
>> And further expanded with a property placeholder definition referencing
>> the alias of the key - using its ARN, or Amazon Resource Identifier which
>> looks something like: "arn:aws:kms:us-east-1:168548364837:key/
>> 12345678-1234-1234-1234-123456789012".
>>
>>
>> When the properties are resolved, it will cause multiple Decrypt calls to
>> Amazon KMS saying "Decrypt this ciphertext using the key with this alias".
>>
>>
>> There are several benefits to this approach:
>>
>>
>> 1. Crypto keying material never leaves the trusted boundary of the KMS.
>> Keys can never be stolen or saved anywhere.
>> 2. Access to the Encrypt and Decrypt functions for each separate key are
>> controlled using Grants to specific IAM Roles, which are assigned to each
>> EC2 instance out-of-band. Access to keys can be revoked with a simple
>> removal of a Grant
>> 3. Key rotation is handled inherently by the KMS in a way that allows
>> ciphertext from older key versions to still be decryptable [1]
>> 4. All encrypt/decrypt calls are fully audited and handled in CloudTrail
>>
>>
>>
>>
>> I would be happy to prototype this approach in the next couple weeks.
>> Would like to know what people think, and maybe someone could be kind
>> enough to point me in the direction of the repository containing the source
>> code for the jasypt decryptor used in Karaf.
>>
>>
>> Thoughts?
>>
>>
>>         -Chad
>>
>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message