1 / 7

GENI Cloud Security GENI Engineering Conference 12 Kansas City, MO

GENI Cloud Security GENI Engineering Conference 12 Kansas City, MO. Stephen Schwab University of Southern California / ISI 3 Nov 2011 www.geni.net. GENI Cloud Architecture. Is this an opportunity to extend the way the GENI CF/AM architecture is presented?

seibel
Download Presentation

GENI Cloud Security GENI Engineering Conference 12 Kansas City, MO

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. GENI Cloud Security GENI Engineering Conference 12Kansas City, MO Stephen Schwab University of Southern California / ISI3 Nov 2011 www.geni.net

  2. GENI Cloud Architecture • Is this an opportunity to extend the way the GENI CF/AM architecture is presented? • Why is a GENI Cloud different from the other GENI Aggregates? - Allocation of many nodes? - Many VMs? - Data Intensive? - Longevity of Slices?

  3. GENI (Component) Authentication • Authentication, Node Login, SSH Keys • Default mechanisms deployed because they are inherited • Node Login – automation required for scale • SSH Keys – coupled to the ssh login mechanism • Can or should we re-architect authentication, node login, and key management for GENI Clouds? • Major engineering and user education challenge • Convenience • Is the use model for the GENI Cloud qualitatively different from the use model for other slices?

  4. GENI Authorization Mechanisms and Policy • Security Architecture Properties enabled through a principled approach: • Support for Authorization “At-scale” • decentralized, multiple distinct roots-of-trust, etc. • Reasoning about Security Policies • predictable impact of changes • Auditing • forensics: why was an action permitted? • confidence building: GENI community has the means to answer these questions if and when the need arises • GENI Resource Contributors retain control • enables local policies over who access what • support sub-communities that need to share resources

  5. ABAC Review • Attribute-based Access Control (ABAC) • Decides whether to grant or deny requests based on a collection of credentials • Defining the rights/privileges of the requesting user • Defining the policy of the resource provider • On-going work in the GENI Authorization arena • Development of libabac and tools in TIED • Integration/Prototyping in three CFs • Decision on adoption for GENI pending at GEC-13

  6. ABAC Details • Refer to Ted Faber’s talk from the GEC-12 Authorization Session for ABAC Details • Refer to the TIED project page on the wiki for documentation and software (libabac)

  7. Implicit Attributes for Cloud Security • Security policies could consider all known information such as: • Location: • What machine/network/IP address is making a request? • Temporal Context: • What actions or other requests were made? • Computational Information Flow Context: • What computations (e.g. search/queries) over what data sources produced intermediate or final results • Trust posture: • What hardware/software, Virtual Machine/GuestOS/Cloud Infrastructure Stack is being used? • ABAC policies can rely on attributes in a general way • Can and should we use the power of implicit attributes to protect GENI Clouds?

More Related