Security is important when deploying any distributed application especially the one responsible for running all of the virtual machines in your data center. When deploying Open Stack, many of the security implementation details are left unspecified. This is where FreeIPA comes to the rescue. This session will show how guidance on how FreeIPA can be used to help secure communication, provide authentication and authorization capabilities for a large scale Open Stack deployment.
OpenStack is extensively used in industry today. With increasing collaborations both within a single organization and between several, resource sharing is a natural extension to the existing implementation of isolated tenants (ie allow resource sharing between tenants within an organization). Furthermore, the access
and resource sharing between different cloud installations is also unattended to. We propose the addition of a service which handles both these requirements ie, resource sharing between tenants within a single organization and also tenants between different cloud installations. Our proposal (which will be submitted as a blueprint and is under implementation) aims to provide a multi-tenant federated access to resources within OpenStack. A federation is an association comprising any number of service providers and identity providers, in this scenario would mean different openstack clouds/installations. Multi-tenancy support is defined as the capability of a single cloud instance to provide its service to several customers/tenants simultaneously which in this case not only refers to the mere existence of several tenants but also resource sharing capability between the tenants within the same cloud instance or other cloud instances due to the concept of federated access.
This brings forth the need for improved Identity Management and Policy Enforcement which doesn’t rework existing deployments but rather extends them to the the required functionality seamlessly. We model the functionality of this service and the required extensions to be made to accommodate it. The crux of our model lies in the way we represent each user and his capabilities. The current system uses a 3-Tuple mechanism of (Subject, Privilege, Object) to represent users and the resources they are allowed access to. We plan to extend this to a 5-Tuple mechanism (Issuer, role(Issuer,roleName), Privilege, Interface, Object) so as to incorporate RBAC and provide access to remote resources outside of the same tenant and cloud installation.
Our talk will deal with a detailed look into this proposal.
In Keystone v3 (Grizzly release), the Domains feature encapsulates users and projects into logical entities that can represent accounts, organizations, etc. However, currently there is no capability or mechanism to manage or enforce quotas at the domain level. Assigning or updating values or limits to a domain will allow the cloud administrator to evaluate domain lists and consumption. In order to achieve these capabilities it will be required to implement quota management and quota monitoring for Keystone domains, by which domain usage can be managed and enforced.
The goal is to support quotas at the OpenStack Domain level.
Most companys today have taken the age old security models and "Virtualized" them to be used in todays "cloud" market. Vendors have come to market with "Virtual" Firewalls, IPS, HIPS/HIDS, etc that all claim to be the pancea that solves your cloud "security" issues. The problem exists when we rely our "virtual" security infrastructure to protect our sensative 'real' information.
During this talk we will walk through the current state of Virtualization security. We will look at products both free ( as in speech, and as in beer) , and commercial products -- and show where they fail and how; in some cases they leave you in a worse position after implementing.
The hypervisor is a huge attack surface; there’s no defense in depth when your only security controls are provided by the provider (Hypervisor vendor, cloud provider, etc ). How do you gain visibility into a system that by design is constructed to keep you out?
Whether it is IAAS or PASS, Public or Private - there is no good compensating control around a system that is closed and only allows access to very specific parts, and uses a "trust me" security methodology.
As a community we need to innovate, leverage different ways to address our security concerns, get rid of the "catsup" on "ketchup" approach to Cloud security, piling on legacy security infrastrucutre up and down the stack, duplicating efforts along the way.
This presentation will outline where our current security strategys fail, and can be circumvented -- and also gives insite on how to make things better going forward.
This presentation will provide an update on the progress in adding federated authentication and authorisation to OpenStack via modifications to the Keystone v3 API. This will allow organisations to use their existing internal authentication systems so that their users can access both public clouds and internal private clouds and services using the same set of credentials. This will simultaneously reduce the management overhead costs to the organisation and the multiple credential management nightmare to users.
This talk will be of general interest to all OpenStack users.
This talk is a break down of security concerns relating to the OpenStack Folsom Release. The purpose of this talk is to look at past vulnerabilities in Folsom, existing security models, and emerging technologies that will impact those models. The presentation will follow the flow of describing several deployment models in terms of their security attributes. The next phase will be the discussion of specific protocols in use and their individual security characteristics. I will present statistics on where past vulnerabilities have been found and reported allowing us to consider how we can better address security in our continuous integration
processes. The goal of this talk is to present a map of where we are today, and expose some of the issues we have yet to face.
OpenStack is complex, and like all complex systems needs to have some extra attention paid when hardening the environment. This session will cover some basic cloud security concepts and then dive into the practicalities of securing your OpenStack deployment and the steps necessary to design your OpenStack Private Cloud in preparation to undergo a PCI-DSS Audit.
There have been a number of premature attempts to provide a trusted computing platform for IaaS software; however, all of met with failure and a lack of mass market adoption. What would be required to solve this problem for real and deliver "true" computing? True computing requires the ability to have a trusted chain of events related to the provisioning and deployment of hardware and software. It requires integration to the supply chain with installation of initial keys at the hardware vendor's site, secure PXE booting, system attestation, and robust key management. None of this is easy or free, but what would it look like if OpenStack could become the first truly trusted cloud system? How would it integrate with the current 'trusted-messaging' blueprint? Would it make CloudAudit's API more relevant?
