Cloud Security with Stackato

Cloud Security with Stackato

1 Survey after survey identifies security as the primary concern potential users have with respect to cloud computing. Use of an external computing environment raises issues regarding:» Code management and change management processes: how can users be sure that the provider ensures that all necessary code changes and patches are applied to critical infrastructure software like the hypervisor; likewise, how can users be sure providers follow industry best practices regarding change management so that every change is tracked to ensure audit capability?» Application security: How can users be assured that appropriate identity and access management policies are enforced to ensure that access to the application and its environment is controlled?» Computing environment security: how can users be confident that the operating environment in which their applications run is securely partitioned from other organizations using that same environment? As companies now begin to consider moving beyond simple Infrastructure-as-a-Service (IaaS) cloud computing, the same security concerns are now applied to the Platform-as-a-Service (PaaS) environments they evaluate. The benefits of PaaS are clear: increased application agility, more efficient infrastructure utilization, and accelerated application lifecycles. However, should a PaaS provider be unable to address these security concerns, potential users will be prevented from adopting the solution, no matter how compelling its operational benefits. ActiveState recognizes how critical the question of PaaS security is and has architected the Stackato environment to meet the security requirements of its most demanding customers. As part of that commitment to security, ActiveState has addressed the three key areas needed to ensure complete PaaS security: 1. Code Integrity This security element focuses on the security of the code used to build Stackato and how ActiveState ensures any reported code vulnerabilities are addressed to minimize security issues. Stackato has a comprehensive and detailed security policy for vulnerability management and a standardized process it follows to ensure all code patches are tracked, implemented, and distributed as quickly as possible. 2. Application Integrity The security associated with the application container is of critical importance. Regardless of whether you are hosting your applications on a private or public cloud, it is necessary to mitigate the risk of a malicious or poorly designed application that could result in costly downtime and loss/leakage of data. As part of its application integrity measures, ActiveState uses Docker containers to ensure that applications operating in the Stackato environment are partitioned and prevented from accessing one another s application space. ddddddddddd

2 3. Operational Integrity While application security is fundamental, securely managing user interaction with the application operating environment is also crucial to ensure full end-to-end security. Stackato implements a number of mechanisms to control Operations access to applications residing within a Docker container. Code Integrity: How Stackato Addresses Code Management to Prevent Security Vulnerabilities The Role of Open Source Components in Stackato Stackato includes many third-party open source components including items sourced from from Canonical s Ubuntu repositories. Based on over 15 years of working with open source products and communities, ActiveState has established industry-best practices to ensure its code management practices address any security issues that may arise. With each new release of Stackato, ActiveState reviews each open source component included in the product to confirm that it contains the latest updates and patches. In addition, ActiveState ensures that included database engines and other data service packages represent the most secure versions by following one of three methods for each data service package:» Sourcing the package from the most recent Ubuntu version, thereby reflecting the package version provided by this leading Linux distribution.» Installing from packages provided by the maintainers, who create and make available upstream more recent and secure versions that may not yet be included in the Ubuntu distribution.» Building the package from the package source. These practices mean that all open source components and packages that are part of Stackato are maintained to the highest possible state of security, and that any security issues that develop are addressed immediately in a manner that allows ActiveState to issue product patches as quickly as possible. Regarding the security practices of the Stackato product itself, ActiveState applies its longestablished code management practices to the product. Stackato is implemented mostly in Ruby, Go, and Node.js. Much of the Stackato code foundation is derived from the Cloud Foundry open source project; however, ActiveState has modified or re-implemented many of the base Cloud Foundry components to improve performance and extend product functionality. For any components that have been patched, augmented, or re-implemented entirely, ActiveState applies security techniques used throughout all of its open source products. All Stackato components modified or extended from the base Cloud Foundry code are actively maintained by ActiveState. Identifying Security Vulnerabilities ActiveState is adept at managing potential vulnerabilities that exist with community-based development. Our developers closely monitor relevant distribution and security-specific mailing lists for all Stackato incorporated projects as well as cve.mitre.org to ensure it is aware of and addressing all security-related product vulnerabilities. Download your free micro cloud: www.stackato.com/download

3 Vulnerability announcements are monitored by ActiveState technical team members charged with security responsibility. In addition, Stackato developers maintain responsibility for their respective Stackato components (e.g. ruby gems, nginx, gnatsd), and monitor the source projects for announcements and releases. In this way, there are two sets of eyes focusing on security and being sure all source code security issues are addressed. The ActiveState development team evaluates all new vulnerabilities and assesses which are applicable to Stackato. Once a vulnerability is identified as relevant to Stackato, team members develop a plan to resolve it as quickly as possible. Furthermore, team members assess if logically similar issues might exist in other areas of the product which are exploitable. If one or more vulnerabilities might be possible in other areas of the product, the plan is extended to incorporate those changes as well. Once a code change plan is developed, team members prioritize them for resolution so that the most critical security issues are addressed immediately. Validation & Testing After a thorough review of a vulnerability, the development team determines what code changes need to be made and the best method to implement them. Some are handled as package updates while others require small patches to the distributed product. The criteria to determine action include: severity of the vulnerability, relevancy to Stackato, and exposure risk level for Stackato customers. When a package update is necessary, we review and test the procedure across the current and most recent Stackato versions to provide customers with a fully tested product that will transparently replace the package they are currently running. Once the procedure is defined, ActiveState creates an update process plan that defines which node types require the update and what products components must be restarted. To ensure that all security updates operate properly and will not disrupt operational environments, ActiveState runs a public-facing Stackato sandbox environment where security patches are applied and tested in real-world use prior to being released to customers. This same process is followed for source code patches, with the extra caution taken to account for source code variation in previous Stackato versions. The length of time it requires to address a security vulnerability depends upon the nature of the vulnerability, how many components or packages it affects, and the severity of the vulnerability. We strive for the quickest possible turnaround on all security vulnerabilities and have achieved under 24-hour response for a number of vulnerabilities identified as significant. Patch Distribution To ensure customers are aware of any security issues as well as the necessary steps to address them, ActiveState sends email notifications to the technical contacts at each user organization. This email describes the general nature of the vulnerability and contains the vulnerability remediation process described in the previous section. As a general rule, ActiveState does not post specific exploit details with a patch to avoid any exploitation efforts and only the patch itself is made available publicly. Remediation normally involves running the Stackato kato patch command, but may require a maintenance window and/or system reboots to ensure the patch is applied properly. Stackato ddddddddddd

4 systems generally fetch patches automatically to make the patching process easier for system administrators; however, in cases where user organizations have restricted internet access for particular nodes or clusters, ActiveState has a process to distribute coded patches manually. Application Integrity: Isolating Operating Environments to Prevent Inappropriate Application Interaction The security of your application in a cloud environment is of critical importance. How your application interacts with other applications in the cloud and its resource usage are two popular concerns for most enterprises. With Stackato, we understand these concerns and have addressed application concerns through the use of Docker containers. Docker Containers as the First Line of Defense Stackato uses Docker for its Linux Containers (LXC) to ensure that customer applications are secure. Docker containers allow users to deploy their applications in a safe and secure way, with applications prevented from interacting with any other application residing on the PaaS unless specifically allowed. The application is isolated in such a way that it only sees its own files and processes and is prevented from accessing files or processes associated with other applications even those operated by the same organization. The diagram below provides an overview of the Stackato architecture. Each Droplet Execution Agent (DEA) represents a virtual machine (VM) instance that hosts multiple Docker containers. Within the DEA, each individual cube represents an individual Docker container running an instance of an application. Download your free micro cloud: www.stackato.com/download

5 Docker Containers isolate all aspects of an application and, as part of that isolation, define a number of namespaces, each of which identifies resources that a group of processes within a specific container can access. These namespaces include pid, net, ipc, mnt and uts. Table 1: LXC Namespaces Namespace pid net ipc mnt uts The process ID namespace groups and isolates processes so that processes in a namespace only have visibility on other processes in the same namespace. Each pid namespace has its own process id numbering, and the namespace guarantees that process in one namespace cannot affect a process in a sibling or parent namespace. The net namespace allows each container to have its own network interface. You can create pairs of these interfaces such that the interface inside the containers can also map or be connected to an interface that s visible outside the application. This functionality enables the container to talk to the outside world. The actual ports that are used are also associated with the namespace. It allows processes running in multiple containers to each listen on the same port. If you start two apache instances on a VM, the second one will fail to launch because the first port is already allocated. With containers, the application in each container binds with port 80 so there is no conflict as far as the application is concerned. Stackato takes care of mapping the outside port, but each application has its own port, without interfering with the other. Each application also has its own IP tables and firewall rules that are specific to it. This provides a lot of power and assists in isolating your applications. Inter-process communication is included for legacy applications that make use of features generally considered obsolete such as semaphores, message queues, and shared memory segments. A handful of apps such as PostgreSQL still use ipc features. The mnt namespace is like chroot, but more powerful. It uses a number process to share a directory, but there is no access to mnt points on the file system. Each container has its own mnt points and root directory which are mapped into the top-level root file system. It looks like it is running on a normal UNIX file system, but it has no visibility into the file system on any other namespace. This is another isolationist capability of Linux containers. UTS manages the host name. It is convenient for each application to have its own host name because it would be more challenging if every app running in PaaS had to share one. With each application having its own, there is more flexibility for the applications and some isolation. If you make the hostname system call you will see the hostname associated with the uts namespace, not the hostname overall. The Linux container implementation using Docker is a fundamental component of how Stackato works. Containers can be rapidly spun up, ensuring rapid response to administrative commands or application load factors. Since a container takes only a few milliseconds to create, these instances appear almost instantaneously, thereby ensuring that applications respond immediately to changing application load. ddddddddddd

6 Containers also allow you to configure limits to container resource consumption, which enables you to be sure that no single container can spin out of control and consume all of the resources. In addition, you can implement security patches on only the VMs that may need it, without having to affect others that may reside on the same infrastructure. Operational Integrity: Implementing Access Controls to Prevent Inappropriate User Interaction Whether you are hosting your applications on a public, private or hybrid cloud, how that application can be accessed is of critical importance. While Docker containers are the first line of defense for Stackato, ActiveState has implemented further security measures to ensure that only appropriate user personnel can gain access to critical application resources. App Armor Each container runs AppArmor (similar to SELinux as a system mechanism to increase default Linux security) to provide an extra layer of security. Even if a person obtains inappropriate access to the root level of one container, AppArmor prevents the user from breaking out of the container, thereby protecting the operating environments of applications residing in other containers. SSL One mechanism to access Stackato is through a browser via HTTP. To further improve operational security, by default Stackato uses the more secure HTTPS for access. SSL requires a certificate on the server, so we deliver Stackato with a self-signed certificate to enable secure use out of the box. However, it is also easy to use your own SSL certificate should you wish to do so. SSH & SCP Access To perform some administrative functions or to interact with software and configurations, Stackato allows SSH access to the container. When SSH is used, it provides complete access to the container process space, file systems, environment, hostname and network. Common actions executed via SSH include examining the application environment, low-level debugging (eg. strace or tcpdump), and to make local non-persisted changes for troubleshooting purposes. Any changes implemented on a given container via SSH will not impact other running containers. SCP is also fully supported, allowing files to be safely transferred to and from the container. Any changes made exist only during the life of a given container and will not persist beyond container termination. Because of this, ActiveState recommends that application instances should not store any state information, as this will restrict that application s ability to scale beyond a single instance. State information should be the domain of the provisioned dataservices that Stackato provides. dbshell Stackato provides an SSL tunnel that can be used to access the data services associated with a specific application. The SSL tunnel is created to access an interactive shell, which can access any of the data services ActiveState supports, including MongoDB, MySQL, and PostgreSQL. This functionality is most commonly used to securely import data into a database. Download your free micro cloud: www.stackato.com/download

7 sudo access Users can be granted sudo privileges within their application containers to install packages or software. Sudo access allows unrestricted access to container resources and, because of this, this should be reserved for trusted users. Stackato allows administrators to grant or revoke sudo privileges to users through the Stackato API or Web Console. Conclusion As users consider moving to a PaaS, they are drawn to its obvious benefits: simplified application development, more rapid application delivery, and greater business agility. However, all IT organizations are charged with ensuring their applications and data are secure and any improved development tools that might compromise security would be unacceptable, no matter what benefits they might deliver. ActiveState recognizes the critical importance of security and implements security measures throughout Stackato as well as its own development process. ActiveState addresses three key areas necessary to ensure PaaS-based application security:» Code Integrity» Application Integrity» Operational Integrity Based on over 15 years of experience ensuring appropriate security in its products, ActiveState is confident its security measures meet industry-best levels. While no system or product is perfect, ActiveState strives to implement best practices so that its customers can be satisfied with the security of their applications running in ActiveState s Stackato product. ddddddddddd

8 ActiveState empowers innovation from code to cloud smarter, safer, and faster. ActiveState s cutting edge solutions give developers and enterprises the Perl, Node.js, PHP, Tcl, and more. Stackato is ActiveState s groundbreaking enterprise private Platform-as-a-Service (PaaS), and is the secure and proven way to develop and deploy apps to the cloud. Download the FREE Stackato Micro Cloud at: www.stackato.com/download ActiveState Software Inc. 1700-409 Granville Street Vancouver, BC V6C 1T2 stackato-sales@activestate.com Phone: 1.778.786.1100 Fax: 1.778.786.1133 NA Toll-free: 1.866.631.4581 Download your free micro cloud: www.stackato.com/download