One of the challenges for administrators, architects and developers in the cloud environment is to comprehend the relationships between different components deployed in the cloud as more resources are added to the infrastructure. Most management consoles do not clearly indicate the contextual relationship between components and this often leads to the engineers or the admins to get redundant components up, make changes that may not be in line with the overall architecture vision etc.
Some of the queries that cannot be easily extracted from traditional managment consoles are:
- How many volumes are associated with an EC2 Instance?
- Which EC2-Instances are open to public i.e. have an Elastic IP?
- Are all EC2-Instances covered by the right security groups within the VPC? If not can we detect which ones are open(or closed) and which groups are unused within the VPC?
- What subnets are associated with my application deployment architecture? Do the subnets ensure segmentation and isolation to enhance security?
- How are EC2 Instances distributed across availability zones? Is the ELB configured to balance load between different zones?
- How many AMIs are in use? Is it possible to reduce redundancy?
- How has the architecture changed over time. What new components were added and when?
The tool would try to answer the above concerns and many more.
Design
Backend Infrastructure:
The platform used to monitor cloud objects is Netflix's EDDA. This tool periodically polls cloud components to record changes over time. It provides a great platform for querying information including contextual relationships between components. EDDA returns basic JSON responses and has extensive support for queries like providing callbacks for JSONP, providing complex search matrix for queries, etc.
However EDDA is still a work in progress and this was only recently open sourced by Netflix. It is configured per region i.e. an instance of
EDDA can poll only one region. We could have multiple instances of EDDA running to poll as many regions as required.
User Interface:
Querying EDDA can be cumbersome as specifying a suitable search matrix is complex. This tool alleviates that by providing a simple user interface where users would be able to filter results based on set parameters. This in turn is translated into a search matrix as a part of the API request to EDDA.
EDDA’s responses are JSON formatted and often complex depending on the kind of search query we provide. One of the highlight of this tool is that it provides a graphical depiction of the deployment environment in the sense that we get a graph of nodes and edges denoting different cloud components and how they are contextually related.
Currently you can query this tool for information regarding a VPC or an EC2-Instance(s) although it can be easily extended to support other types of queries.
This is built here at Symantec entirely in javascript, supported by Firefox, Safari and Chrome.There is no support for IE yet as the backing graph library (Vivagraph) currently has limited IE support.
Below are some screenshots of the tool in action catering to certain use cases. The cloud deployment being monitored is a VPC which was setup as a part of the AWS Sharepoint Server Farm.
Use Case: Show placement zones for instances in vpc-7886b913 including those instances that have a public IP address:
Use Case: Show placement zones and security groups for instances in vpc-7886b913 including those instances that have a public IP address:
Specific color coding of edges are used to denote different types of relationships with the instance as focal point. Like 2 instances may have the same security group configuration this in our graph this is denoted by two EC2 nodes connected to a single Security Group node by a RED link/edge.
All nodes are reported by their corresponding tags if available to keep the visualization intuitive. If no tags are present, then the resource IDs are used. The graph engine is powered by Vivagraph - an open source graph library that supports both WebGL and SVG.
Security Analysis
This tool creates a high level of visibility enabling greater security analysis.
Considering the third use case above, we can see that 6 instances are connected to the same security group sg-b8e70ed7. Any change to the configuration of this security group like opening specific ports etc. have to be done carefully keeping in mind the number of other systems dependent on this security group. In a large deployment this could be hard to visualize with existing management tools.
Similarly identifying the number of public facing nodes can be an important factor in determining the subnet and security group configurations for the entire system. With the added visibility, performing security audits would be a lot easier.
Future Work
EDDA, the backend powering this tool is continously evolving and more feature sets are being added by the developer community. This would help us achieve more visibility to some of the cloud management protocols and also open more opportunites for security analysis and research in the cloud environment.
For a quick demo or questions regarding source for this tool, please contact me at Krishnan_Narayan@Symantec.com