- Developer Tools
Organizations moving to the cloud need to understand the security at each layer of the cloud stack. The security associated with your private platform-as-a-service (PaaS) is just as important as the security associated with your infrastructure. Stackato has been architected with security as the primary focus to protect your applications from being breached and bringing down your cloud completely.
First Line of Defense–Docker Containers
Stackato uses Docker for its Linux Containers (LXC) to ensure that our customers’ applications are secure. These Docker containers allow users to deploy their applications in a safe and secure way, knowing that one application cannot interact with any other on the PaaS unless it is specifically allowed to. The application is isolated in such a way that it only sees its own files and processes.
The diagram below provides an overview of the Stackato architecture. Each Droplet Execution Agent (DEA) represents a virtual machine (VM) instance that is enabled to run each application instance in its own container. Within the DEA, each individual cube represents the container itself (which runs the application).
Containers allow for the isolation of all aspects of an application and define a number of namespaces, each of which identifies resources that a group of processes can access. These namespaces include pid, net, ipc, mnt and uts.
The Linux container implementation using Docker is a fundamental component of how Stackato works. Containers can be rapidly spun up. When the application is scaled, these instances appear almost instantaneously with each container taking only a few milliseconds to be created.
By using containers, you also have complete control over resources associated with each one. You are able to set the limit so no single container can go rogue and consume all of the resources. In addition, you can perform your security patches on only the one VM that may need it, without having to affect others that may be residing on the same infrastructure.
Additional Security Measures used in Stackato
In addition to the use of Linux containers, Stackato provides users with further security measures.
Each container also runs AppArmor (an alternative to SELinux) to provide an extra layer of security. If a person obtains access at the root level of the container, AppArmor prevents the user from breaking out of the container.
Stackato supports SSL across the stack and the API itself is accessed over HTTPS by default. You can manage all aspects Stackato with the API by using any HTTP client. The Stackato Web Console is a sample client. SSL requires a certificate on the server, so we deliver Stackato with a self-signed certificate and then we provide a mechanism so you can update it with your own. Non-SSL access is also available through Stackato.
SSH & SCP Access
SSH allows provides direct access to the container. As you deploy an application you might wonder what the environment variable looks like and parse it. Stackato's SSH support allows the user to directly SSH into the container for examining the environment, low-level debugging (eg. strace or tcpdump) and to make local non-persisted changes for troubleshooting purposes. Any changes will not impact other running containers. SCP is also fully supported, allowing files to be safely transferred to and from the container.
Stackato provides an SSL tunnel that can be used to access the underlying data. The SSL tunnel is created to access an interactive shell. MongoDB, MySQL, PostgreSQL. This functionality is most commonly used to import data into your database.
Users can be granted sudo privileges within their application containers. This allows unrestricted access to install any packages or software within that container. Because of this, this is reserved for trusted users. Stackato allows administrators to grant or revoke sudo privileges to users through the Stackato API or Web Console.
Want to try Stackato? Download the micro cloud for free.