The Nebula project lets users manage their own machines on AWS utilizing profiles defined by your Ops team.
In an organization that wants to give its developers and researchers access to AWS instances the typical process involves creating IAM roles, adding new IAM users, and then training those users on the AWS Console or providing them with command line tools. This can be burdensome to say the least.
The Nebula dashboard integrates into an organization's existing LDAP structure without the need for new IAM users. Nebula provides a system where admins can define different profiles (including the
AMI and instance
userdata) that users can then launch and manage on their own. Users are given the tools to monitor the costs of their instances, such as alerts when they pass certain thresholds, and can even schedule instance shutdown in advance.
Nebula also saves the Ops team from having to deal with SSH keys by letting users manage them on their own.
If you're looking for the documentation look no further than the Nebula Wiki.
Easily Defined System Profiles
Admins can create "Profiles" that their users can then launch machines from. These profiles define the AMI and User Data that are used by Nebula to launch the individual instances.
Admins can choose to give profiles either a direct AMI to launch or a set of filters and owner id which Nebula can use to find an AMI (in the event that multiple AMIs match the filters the most recently created one will be used).
Nebula uses LDAP as its user database.
Full Instance Control
Users have full control over the Instance Type they launch, with a breakdown of the different features (VCPU, Memory, GPUs) available right in the launch menu.
Multiple Availability Zone Support
Nebula supports the ability to specify multiple subnets that it can launch into. When instances of a particular type are unavailable in one (the dreaded
INSUFFICIENT_CAPACITY error) it will continue trying in other subnets until it either launches the instances or runs out of subnets.
Nebula admins have the ability to blacklist instances they do not want their users to launch.
Instances can be given a specific shutdown time. This can be used as a failsafe to prevent machines from being left up or to shutdown machines after running experiments or long running tasks.
Both the User and Amin Dashboards contain to the second cost for all running instances and the volumes of every instance. All users can easily sort by cost to see which of their instances have cost the most money.
SSH Key Management and OpenSSH Integration
Users can add and remove their own public ssh keys on their own. Admins also have the ability to view, add, and remove User keys.
A provided integration script lets OpenSSH pull from this list of keys directly.
Web API for Continuous Deployment
Launch profiles can have their AMI updated automated using the Profiles API. This allows organizations which have automated their build process to always provide the most up to date version of the AMI available. This API can also be used to create and remove profiles.
Autoupdating Instance Metadata
Instance data is pulled from the ec2details API, so new instances and updates pricing information are available to Nebula without having to update the project itself. The ec2details API itself is populated directly from the AWS Bulk API.
AWS Secrets Manager Support
Nebula can load its entire configuration from the AWS Secrets Manager, making it even easier to deploy Nebula as a container.
AWS Cost Explorer Integration
Nebula makes extensive use of resource tags. Every Instance, ENI (network device), and EBS volume gets tagged with the User, Profile, and Site Name. This allows AWS admins to get per penny billing reports on exactly what money is being spent by who on their Nebula install.
Simple Development Environment
Nebula has an easy to use development environment that also makes for a great demo.