Re: [openstack-dev] [nova][cinder] Using externally stored keys for encryption
Dear Mohammed, with SecuStack we've been integrating end-to-end (E2E) transfer of secrets into the OpenStack code. From your problem description, it sounds like our implementation would address some of your points. For below explanation, I will refer to those secrets as "keys". Our solution works as follows: - when the user creates an encrypted resource, they may specify to use E2E key transfer instead of Barbican - the resource will be allocated and enter a state where it is waiting for the transmission of the key - the user establishes an E2E relationship with the compute/volume host where the resource has been scheduled - the key is encrypted (asymmetrically) on the user side specifically for this host (using its public key) and transferred through the API to this host - the key reaches the compute/volume host, is decrypted by the host's private key and is then used temporarily for the duration of the resource creation and discarded afterwards Whenever such resource is to be used (instance booted or volume attached), a similar workflow is triggered on-demand that requires the key to be transferred via the E2E channel again. Our solution is complemented by an extension of the Barbican workflow which also allows users to specify secret IDs and manage them manually for encrypted resources instead of having OpenStack handle all of that automatically. This represents a solution that is kind of in-between the current OpenStack and our E2E approach. We have not looked into external Barbican integration yet, though. We do plan to contribute our E2E key transfer and user-centric key control to OpenStack, if we can obtain support for this idea. However, we are currently in the middle of trying to contribute image encryption to OpenStack, which is already proving to be a lengthy process as it involves a lot of different teams. The E2E stuff would be an even bigger change across the components. Unfortunately, we currently don't have the resources to tackle two huge contributions at the same time as it requires a lot of effort getting multiple teams to agree on a single solution. Best regards, Markus Hentsch Mohammed Naser wrote: > Hi everyone: > > I've been digging around the documentation of Nova, Cinder and the > encrypted disks feature and I've been a bit stumped on something which > I think is a very relevant use case that might not be possible (or it > is and I have totally missed it!) > > It seems that both Cinder and Nova assume that secrets are always > stored within the Barbican deployment in the same cloud. This makes a > lot of sense however in scenarios where the consumer of an OpenStack > cloud wants to operate it without trusting the cloud, they won't be > able to have encrypted volumes that make sense, an example: > > - Create encrypted volume, keys are stored in Barbican > - Boot VM using said encrypted volume, Nova pulls keys from Barbican, > starts VM.. > > However, this means that the deployer can at anytime pull down the > keys and decrypt things locally to do $bad_things. However, if we had > something like any of the following two ideas: > > - Allow for "run-time" providing secret on boot (maybe something added > to the start/boot VM API?) > - Allow for pointing towards an external instance of Barbican > > By using those 2, we allow OpenStack users to operate their VMs > securely and allowing them to have control over their keys. If they > want to revoke all access, they can shutdown all the VMs and cut > access to their key storage management and not worry about someone > just pulling them down from the internal Barbican. > > Hopefully I did a good job explaining this use case and I'm just > wondering if this is a thing that's possible at the moment or if we > perhaps need to look into it. > > Thanks, > Mohammed > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][cinder][glance][osc][sdk] Image Encryption for OpenStack (proposal)
Dear OpenStack developers, as you suggested, we have written individual specs for Nova [1] and Cinder [2] so far and will write another spec for Glance soon. We'd appreciate any feedback and reviews on the specs :) Thank you in advance, Markus Hentsch [1] https://review.openstack.org/#/c/608696/ [2] https://review.openstack.org/#/c/608663/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova][cinder][glance][osc][sdk] Image Encryption for OpenStack (proposal)
Hello Eric, Eric Harney wrote: > > Are you aware of the existing Cinder support for similar functionality? > > When encrypted volumes are uploaded to Glance images from Cinder, > encryption keys are cloned in Barbican and tied to Glance images as > metadata. Then, volumes created from those images can consume the > Barbican key to use the volume. > > The keys I mention here are used for the LUKS encryption layer -- which > is different from what you are proposing. But I'd like to point it out > to make sure that the interaction between the two different encryption > methods is understood when designing this and considering use cases. > > (Note: there is still at least one big TODO pending around this > functionality, namely that the Glance service doesn't know to remove a > key from Barbican when the image is deleted from Glance.) > We are aware of this and plan to integrate this existing case with our new approach. This would mean that the container_format property of such image - which currently is simply 'bare' iirc - would be changed to the new one for encrypted images and its metadata adjusted to contain appropriate information about the encryption used. Such metadata would indicate the Cinder-specific encryption in this case and differentiate it from our general encryption mechanism. Regarding the key deletion: that's an interesting point actually. Although OpenStack does create and delete keys for encryption of volumes or ephemeral storage itself automatically, we didn't plan to do that in our current proposal for the image encryption. As our quoted use cases describe, the user is to upload or order a key in Barbican beforehand themselves. This means the key management (including deletion) for encrypted images was meant to be in the hand of the user. I wonder, would this be undesired from the OpenStack perspective? Best regards, Markus __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][cinder][glance][osc][sdk] Image Encryption for OpenStack (proposal)
Hello Julia, we will begin formulating an individual spec for each project accordingly. Regarding your question: as you already assumed correctly, the code necessary to handle image decryption is driver specific in our current design as it is very close to the point where the ephemeral storage disk is initialized. Our proposed goal of direct decryption streaming makes it hard to design this in a generic fashion since we can't simply place the decrypted image somewhere temporarily in a generic place and then take it as a base for a driver specific next step, since that'd expose the image data. Best regards, Markus Julia Kreger wrote: > Greetings! > > I suspect the avenue of at least three different specs is likely going > to be the best path forward and likely what will be required for each > project to fully understand how/what/why. From my point of view, I'm > quite interested in this from a Nova point of view because that is the > initial user interaction point for majority of activities. I'm also > wondering if this is virt driver specific, or if it can be applied to > multiple virt drivers in the nova tree, since each virt driver has > varying constraints. So maybe the best path forward is something nova > centric to start? > > -Julia > > On Thu, Sep 27, 2018 at 10:36 AM Markus Hentsch > wrote: >> >> Dear OpenStack developers, >> >> we would like to propose the introduction of an encrypted image format >> in OpenStack. We already created a basic implementation involving Nova, >> Cinder, OSC and Glance, which we'd like to contribute. >> >> We originally created a full spec document but since the official >> cross-project contribution workflow in OpenStack is a thing of the past, >> we have no single repository to upload it to. Thus, the Glance team >> advised us to post this on the mailing list [1]. >> >> Ironically, Glance is the least affected project since the image >> transformation processes affected are taking place elsewhere (Nova and >> Cinder mostly). >> >> Below you'll find the most important parts of our spec that describe our >> proposal - which our current implementation is based on. We'd love to >> hear your feedback on the topic and would like to encourage all affected >> projects to join the discussion. >> >> Subsequently, we'd like to receive further instructions on how we may >> contribute to all of the affected projects in the most effective and >> collaborative way possible. The Glance team suggested starting with a >> complete spec in the glance-specs repository, followed by individual >> specs/blueprints for the remaining projects [1]. Would that be alright >> for the other teams? >> >> [1] >> http://eavesdrop.openstack.org/meetings/glance/2018/glance.2018-09-27-14.00.log.html >> >> Best regards, >> Markus Hentsch >> > [trim] > > __________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ** *Markus Hentsch* Head of Cloud Innovation CLOUD *CLOUD & HEAT Technologies GmbH* Königsbrücker Str. 96 (Halle 15) | 01099 Dresden Tel: +49 351 479 3670 - 100 Fax: +49 351 479 3670 - 110 E-Mail: markus.hent...@cloudandheat.com <mailto:markus.hent...@cloudandheat.com> Web: https://www.cloudandheat.com Handelsregister: Amtsgericht Dresden Registernummer: HRB 30549 USt.-Ident.-Nr.: DE281093504 Geschäftsführer: Nicolas Röhrs __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova][cinder][glance][osc][sdk] Image Encryption for OpenStack (proposal)
Dear OpenStack developers, we would like to propose the introduction of an encrypted image format in OpenStack. We already created a basic implementation involving Nova, Cinder, OSC and Glance, which we'd like to contribute. We originally created a full spec document but since the official cross-project contribution workflow in OpenStack is a thing of the past, we have no single repository to upload it to. Thus, the Glance team advised us to post this on the mailing list [1]. Ironically, Glance is the least affected project since the image transformation processes affected are taking place elsewhere (Nova and Cinder mostly). Below you'll find the most important parts of our spec that describe our proposal - which our current implementation is based on. We'd love to hear your feedback on the topic and would like to encourage all affected projects to join the discussion. Subsequently, we'd like to receive further instructions on how we may contribute to all of the affected projects in the most effective and collaborative way possible. The Glance team suggested starting with a complete spec in the glance-specs repository, followed by individual specs/blueprints for the remaining projects [1]. Would that be alright for the other teams? [1] http://eavesdrop.openstack.org/meetings/glance/2018/glance.2018-09-27-14.00.log.html Best regards, Markus Hentsch (excerpts from our image encryption spec below) Problem description === An image, when uploaded to Glance or being created through Nova from an existing server (VM), may contain sensitive information. The already provided signature functionality only protects images against alteration. Images may be stored on several hosts over long periods of time. First and foremost this includes the image storage hosts of Glance itself. Furthermore it might also involve caches on systems like compute hosts. In conclusion they are exposed to a multitude of potential scenarios involving different hosts with different access patterns and attack surfaces. The OpenStack components involved in those scenarios do not protect the confidentiality of image data. That’s why we propose the introduction of an encrypted image format. Use Cases - * A user wants to upload an image, which includes sensitive information. To ensure the integrity of the image, a signature can be generated and used for verification. Additionally, the user wants to protect the confidentiality of the image data through encryption. The user generates or uploads a key in the key manager (e.g. Barbican) and uses it to encrypt the image locally using the OpenStack client (osc) when uploading it. Consequently, the image stored on the Glance host is encrypted. * A user wants to create an image from an existing server with ephemeral storage. This server may contain sensitive user data. The corresponding compute host then generates the image based on the data of the ephemeral storage disk. To protect the confidentiality of the data within the image, the user wants Nova to also encrypt the image using a key from the key manager, specified by its secret ID. Consequently, the image stored on the Glance host is encrypted. * A user wants to create a new server or volume based on an encrypted image created by any of the use cases described above. The corresponding compute or volume host has to be able to decrypt the image using the symmetric key stored in the key manager and transform it into the requested resource (server disk or volume). Although not required on a technical level, all of the use cases described above assume the usage of encrypted volume types and encrypted ephemeral storage as provided by OpenStack. Proposed changes * Glance: Adding a container type for encrypted images that supports different mechanisms (format, cipher algorithms, secret ID) via a metadata property. Whether introducing several container types or outsourcing the mechanism definition into metadata properties may still be up for discussion, although we do favor the latter. * Nova: Adding support for decrypting an encrypted image when a servers ephemeral disk is created. This includes direct decryption streaming for encrypted disks. Nova should select a suitable mechanism according to the image container type and metadata. The symmetric key will be retrieved from the key manager (e.g. Barbican). * Cinder: Adding support for decrypting an encrypted image when a volume is created from it. Cinder should select a suitable mechanism according to the image container type and metadata. The symmetric key will be retrieved from the key manager (e.g. Barbican). * OpenStack Client / SDK: Adding support for encrypting images using a secret ID which references the symmetric key in the key manager (e.g. Barbican). This also involves new CLI arguments to specify the secret ID and encryption method. We propose to use an implementation of symmetric AES 256 encryption provided by GnuPG as a basic
Re: [Openstack] How to setup nova's policy.json ensure only owner can list his instance?
Hello, as far as I am aware, the lowest possible level you can (officially) reach with the policy files is project-level not user-level. Some APIs still provide user-level checks but those are a thing from the past and effectively deprecated. Nova API was migrated to Oslo Policies for API 2.1 where the user-level was removed entirely from the policy implementation, if I recall correctly. Kind regards, Markus Hentsch Cloud Technologies On 08.01.2018 at 06:50, Ying-Chuan Chen wrote: > Hi guys, > I want to ensure that only the owner of the instances can list his > instances. > I try to add rules in /etc/openstack-dashboard/nova_policy.json like > below: > > "owner": "user_id:%(user_id)s", > > "compute:get": "rule:owner", > > But, it can't work. > How to setup policy ensure only owner can list his instance? > Version: Ocata, OS: CentOS 7.3 > > Thanks a lot! > > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Policy enforcement in Glance (Ocata Release)
After some more thorough analysis of Glance, I think we finally got this figured out. The access control to Glance seems to be a two-staged process. The first stage is the policy check. This stage determines, which API requests are accepted. Nothing special here, the rules defined in the "policy.json" are applied. The second stage is a hardcoded process that can get confusing. At this stage, the requesting user is checked whether they are the "glance admin" or not. This is true if either or both of the following conditions are met: * the user matches the rule defined as "context_is_admin" in the "policy.json" * the user has a role that matches the "admin_role" entry in the "glance-api.conf" As soon as the user is identified to be a "glance admin", they are allowed to access and manipulate images at will, not being bound to the project context at all. In any other case the project context seems to be automatically enforced in the second stage, the check for "project_id" or "owner" respectively is unnecessary in the policies. This leads to the solution to our problem: We simply created a new role called "project-admin" and defined corresponding rules and restrictions within the "policy.json": ... "context_is_admin": "role:admin", "admin_restriction": "role:admin or role:project-admin", ... "delete_image": "rule:admin_restriction", It is important to note, that the "role:admin" within "admin_restriction" is still absolutely necessary for the global admin to pass the 1st stage, even if "context_is_admin" is approprietly defined. The "context_is_admin" on the other hand, allows the global admin to pass the 2nd stage as the "glance admin" but is out of scope for the 1st stage. The "project-admin" role now allows for project-scoped admins being able to delete images, while normal project members can't but still retaining the global (and hence glance-) admin's omnipotence. The thing to be learned from this is that the statement "You can use the policies to control what users can make the call, but you can't use the policies to determine what will be included in the response" has one exception. That is the "context_is_admin", since it has influence on the second stage that follows the actual policy check (together with the "admin_role" config entry). Mind you, none of this may apply to other OpenStack components at all, since this analysis was Glance-specific. There is currently no consistent way of identifying the "global admin" across the components, so each one of them might implement their unique way of handling this. However, it seems there is some movement going on - see the following (quite recent) blog post for more details: http://adam.younglogic.com/2017/05/fixing-bug-96869/#bug-968696 Kind regards, Markus Hentsch Cloud Technologies > Dear Brian, > > thanks for your answer to my previous question! > > I've tried changing the definition of "admin_role" in the > configuration of the Glance API component but it did not change the > behavior in the way I was expecting it. > > This role is evaluated and sets the "self.is_admin" property, see: > > > https://github.com/openstack/glance/blob/0a2074ecef67beb7a3b3531534c9d97b1c3ea828/glance/api/middleware/context.py#L195 > > However before that check, the policy check possibly alters the same > "self.is_admin" property in the RequestContext constructor, see: > > > https://github.com/openstack/glance/blob/0a2074ecef67beb7a3b3531534c9d97b1c3ea828/glance/context.py#L36 > > The "check_is_admin()" in turn evaluates the policy rule for > "context_is_admin". > > If I interpret this correctly, the value of the "self.is_admin" > property determines who is what you describe as the "glance admin". > However, due to the code cited above, the assignment of who is the > "glance admin" seems to be influenced by /both/ the "admin_role" > config entry /as well as/ the "context_is_admin" policy rule. > > This leads to the problem that is affecting my setup. Every project > member that has the "admin" role within their project, seems to be > automatically treated as a glance admin (self.is_admin). This explains > why admins from specific projects can still see _private_ images of > other projects they are not even a member of, just because their role > happens to be called "admin". In my case this is a serious security > issue and I'd like to prevent this. > I want to prevent users from seeing or accessing private images of >
[Openstack] Policy enforcement in Glance (Ocata Release)
Hello,
I've run into an issue regarding policies with Glance on the Ocata release.
Essentially, I'd like to restrict the actions of listing images and
viewing/editing their details to either members of the same project or
the global admin. Since all policies are empty strings by default, I
tried the following edit:
{
"context_is_admin": "role:admin",
"default": "role:admin",
"admin_or_owner": "is_admin:True or project_id:%(project_id)s",
"add_image": "",
"delete_image": "",
"get_image": "admin_or_owner",
"get_images": "admin_or_owner",
"modify_image": "admin_or_owner",
"publicize_image": "role:admin",
"communitize_image": "",
...
The result was that nobody (including the global admin!) could list
images anymore. An "openstack image list" command would always result in
a "403 Forbidden" error.
Also, retrieving a single image's info via a user from the same project
was also impossible. An "openstack image show " would simply
output "403 Forbidden You are not authorized to compelte get_images action".
From the policies as quoted above I would have expected the global admin
as well as any project member being able to list and show images without
problems.
Editing 2 lines in above policy definition:
...
"get_images": "",
"modify_image": "",
...
resulted in another weird behavior. With those adjustments, an
"openstack image list" or "openstack image show " on the
command line executed as the global admin succeeded. On the dashboard
(Horizon) on the other hand, only listing them was possible. Trying to
display their details resulted in an error.
Digging through the logs and code, I stumbled on an image target object
that is inspected for the policy enforcement, see here:
https://github.com/openstack/glance/blob/57c4d7d78f37e840660719b944ebabe91cbf231b/glance/api/policy.py#L109
Hacking the code to put some more debugging output into the logs, I
peeked into this "ImageTarget(image)" object, which also contains a
".target.context" attribute wrapped into it. Although this "context"
attribute does contain seemingly relevant user data, its contents _do
actually differ depending on the logged in user_.
My interpretation was that the context of the image target should be
static (representing the owner/project it actually belongs to) and that
this is in turn matched against the dynamic "self.context" dict
(representing currently logged in user) according to the policies
defined, something along the lines of:
self.context (e.g. project_id) ---[policy check against]--->
ImageTarget(image) (e.g. project_id)
However "ImageTarget(image)" seems to contain context that is not
actually related to the image but differs per logged in user.
Did I misinterpret the policy definitions and/or the code related to it?
How are policies like these actually supposed to be defined in Glance?
Kind regards,
Markus Hentsch
Cloud Technologies
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] Restricting volume attachment using policies
Am 20.02.2017 um 10:01 schrieb Vincent Gatignol: > Le 20/02/2017 à 09:20, Markus Hentsch a écrit : >> Hello, >> >> I'm running a Newton setup where I'm trying to restrict the volume >> attachment actions using Nova's policy file. >> >> I want to check for both the VM ownership as well as the volume >> ownership, so that users should be unable to attach volumes if they >> aren't the owner of both the VM and the volume. >> > This is related to https://bugs.launchpad.net/nova/+bug/1539351 > Openstack policies are mapped at the tenant/project level, not user > > Regards, > Vincent Dear Vincent, thanks for clarifying this! Kind regards, Markus Hentsch Cloud Technologies ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack] Restricting volume attachment using policies
Hello,
I'm running a Newton setup where I'm trying to restrict the volume
attachment actions using Nova's policy file.
I want to check for both the VM ownership as well as the volume
ownership, so that users should be unable to attach volumes if they
aren't the owner of both the VM and the volume.
I came up with the following policy.json content:
{
"admin_or_user": "is_admin:True or user_id:%(user_id)s",
"os_compute_api:servers:delete": "rule:admin_or_user",
"os_compute_api:os-volumes-attachments:create":
"rule:admin_or_user",
"os_compute_api:os-volumes-attachments:delete": "rule:admin_or_user"
}
Unfortunately neither of my intended restrictions for volume attachment
seem to be working. This means, a user is still able to attach volumes
that they not own as well as attach volumes to VMs that aren't their VM.
In contrast, the policy restriction for "os_compute_api:servers:delete"
is working just fine: users can now only delete their own VMs, not other
belonging to the same project anymore.
I did some digging into the code and found an interesting difference:
https://github.com/openstack/nova/blob/af44ff97dcef83e3fbae02ab23b1f47d7192e298/nova/api/openstack/compute/servers.py#L757
def _delete(self, context, req, instance_uuid):
instance = self._get_server(context, req, instance_uuid)
context.can(server_policies.SERVERS % 'delete',
target={'user_id': instance.user_id,
'project_id': instance.project_id})
...
For the VM delete action, the "user_id" is retrieved from the VM
instance and thrown into the policy check. However, the same does not
apply for the volume attachment:
https://github.com/openstack/nova/blob/af44ff97dcef83e3fbae02ab23b1f47d7192e298/nova/api/openstack/compute/volumes.py#L310
def create(self, req, server_id, body):
"""Attach a volume to an instance."""
context = req.environ['nova.context']
context.can(vol_policies.BASE_POLICY_NAME)
context.can(va_policies.POLICY_ROOT % 'create')
...
In this case neither the VM instance's "user_id" nor the volume's
"user_id" are retrieved and added as "target" to the policy check.
I modified the code to a log output for the context dict object. It
seems that in the case for the volume attachment the "user_id" value
defaults to the logged in user's for both policy checks, essentially
circumventing my planned restrictions because the "user_id" values will
always match.
Is this some limitation within the code or general design of the volume
attachment policies or is there some other approach that has to be taken
here?
Kind regards,
Markus Hentsch
Cloud Technologies
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
