Please correct me if I am wrong, but I think there is no secure way to store stuff in an virtual environment.
I wish I am wrong - cause my heart always bleeds if I see db passwords in configuration files! But As long as there is a hypervisor you do not control access to - you must trust the owner of the bare metal to (1) honor your privacy (2) be competent to secure his system. Trust is nice, but it is not security.
granted - Confidant and KMS seem better solution than most. Will look into it at more detail. thx for open sourcing it and moving the solution forward.
Please correct me if I am wrong, but I think there is no secure way to store stuff in an virtual environment. I wish I am wrong - cause my heart always bleeds if I see db passwords in configuration files! But As long as there is a hypervisor you do not control access to - you must trust the owner of the bare metal to (1) honor your privacy (2) be competent to secure his system. Trust is nice, but it is not security.…
It's unfortunate that this is tied to AWS, while the industry is moving towards a cloud agnostic approach to hosting. That being said, it seems like an interesting project to keep an eye on.
I'd say the opposite - the industry is in general being a lot more comfortable with investing in AWS to the point of lockin being acceptable now. More people are treating cloud providers less like a big pool of IP addresses. Not saying it's a good or bad thing, but attend AWS reInvent or something and it's pretty easy to percieve huge uptake. If you adopt extra management stacks running on or against your cloud you l…
That's an interesting perspective and observation. I've always found lock-in to be a bit scary, and I've heard this echoed by a number of colleagues & companies. No one can deny the usefulness of tools provided by hosting providers, namely AWS; however, to me, architecting a system in such a way where you are literally unable to jump ship when the need arises (compliance, cost, etc) is unacceptable. With hybrid / multi cloud more of a reality with the existence of tools like Docker (and others), there needs to exist sets of tools capable of handling such variability. I digress, this really belongs in an entirely different thread.
Please correct me if I am wrong, but I think there is no secure way to store stuff in an virtual environment. I wish I am wrong - cause my heart always bleeds if I see db passwords in configuration files! But As long as there is a hypervisor you do not control access to - you must trust the owner of the bare metal to (1) honor your privacy (2) be competent to secure his system. Trust is nice, but it is not security.…
I did not know such thing is possible. very cool! thx for pointing it out! :)
but still..some rhetorical questions: Is KMS based on this concept? Is it's implementation open sourced? Is it verified to run unchanged in the instance I pay? Who is verifying it? Who is paying the one verifying it? Can I meet him / her to drink a coffee and build trust between us?
pls, do not misunderstand me. I got more trust in the amazon techs than in my own ability to admin a complex linux system on bare metal. But while all that is great progress toward security we still need to make a leap to find a solution. don't we?
It's unfortunate that this is tied to AWS, while the industry is moving towards a cloud agnostic approach to hosting. That being said, it seems like an interesting project to keep an eye on.
I'm in agreement with mpdehaan2 here. By sticking with a single cloud provider you get a lot of benefits. One of the more major benefits is cost, as you can do things like reserved instance in EC2. Another major benefit of sticking with a single provider is that you get to use solutions that only that provider has, which in this case is KMS, DynamoDB and IAM. The biggest downside of being cloud agnostic is that you'r…
It seems like Confidant can and will be great for customers using AWS, and frankly it's nice to see open source projects built using AWS services, but is not a complete black box (like many AWS services themselves). I also totally agree that utilizing the tools provided by your hosting provider can be majorly beneficial; however, I think that sometimes teams employ hacky solutions so they can use a hosted service from AWS (or similar), in which case they end up with technical debt and the inability to change directions in the future.
As you said, until tools exist that offer operability between clouds, users will be stuck with the smallest combination of tools. I do however believe such a day is coming.
Please correct me if I am wrong, but I think there is no secure way to store stuff in an virtual environment. I wish I am wrong - cause my heart always bleeds if I see db passwords in configuration files! But As long as there is a hypervisor you do not control access to - you must trust the owner of the bare metal to (1) honor your privacy (2) be competent to secure his system. Trust is nice, but it is not security.…
Security is a spectrum. There's definitely a path for someone with full local access to the hypervisor and system memory to do some careful reconstruction or other malicious injection, but that attack vector is amazingly rare compared to attacks based on bad protocols for network traffic, bad app-level auth, and insecure storage practices (mixing code and creds, for example).
There's immense value in defending against the kind of attacks where an attacker gets partial access, even if an attacker with omnipotence can compromise you.
I did not know such thing is possible. very cool! thx for pointing it out! :) but still..some rhetorical questions: Is KMS based on this concept? Is it's implementation open sourced? Is it verified to run unchanged in the instance I pay? Who is verifying it? Who is paying the one verifying it? Can I meet him / her to drink a coffee and build trust between us? pls, do not misunderstand me. I got more trust in the amaz…
> I did not know such thing is possible.
It's theoretically possible, but right now it's too slow to be practical in usual situations. Just storing and single operations are maybe possible. But for example homomorphic AES takes multiple seconds per each block. And that's still AES-128.
This is the first time I've seen a nicely documented requirements.txt and I like! https://github.com/lyft/confidant/blob/master/requirements.t...
+ for readability, - for precise versions. Good luck receiving critical updates this way...
We watch CVEs and update accordingly. Assuming you're using the latest stable release of the docker image or are using the latest stable release of Confidant (we're still working on making releases through github) you should be using a version with secure dependencies.
Using >= doesn't ensure security, but it does ensure less stability, and part of security is availability.
This is the first time I've seen a nicely documented requirements.txt and I like! https://github.com/lyft/confidant/blob/master/requirements.t...
+ for readability, - for precise versions. Good luck receiving critical updates this way...
i mean, aren't specified versions crucial for compatibility? what am i missing?
on second thought, i guess you are suggesting to specify the major, with an ambiguous minor? but doesn't this require that no package will introduce a breaking change in a minor version? not sure you can rely on that assumption.