NCI Help

Page tree

On this page

Overview

This collection of pages provide some guidance for users intending to build services on the Nirin Cloud. It is not intended to be comprehensive and should not be considered prescriptive - rather it should be considered a starting point for ongoing learning and improvement.

Broad Outlines

The following sections give very high level overviews of the shape of cloud services, which will be covered in more detail in further documents.

Dynamic Services

Cloud services are dynamic environments, with resources being added and removed as required rather than being provisioned up-front. Depending on the services being run this could involve spinning up additional compute nodes to handle a load spike, or adding back end servers to a reverse proxied service as your user base grows. Regardless of the details, cloud services should be built around the core idea of matching resources allocated to resources required in a dynamic manner, typically using some form of automation and orchestration to manage building and deploying resources.

Automation

Because of the dynamic nature of cloud services it is extremely important for cloud services to be built using some type of automation, which allows resources to be added and removed quickly and efficiently without requiring direct human intervention - having to manually log into new instances in order to add them to the pool of active resources is extremely limiting, and should be avoided.

The goal for building a cloud service should typically to build a system which will build the service for you, as well as allow ongoing management of the service. There are many tools available to support this goal, including Heat, Puppet, Ansible, Terraform, and many others - some of these are discussed below in more detail.

Security

Cloud services by their very nature live on the public Internet, and as such are almost always exposed to external attacks. Thus it is essential for security considerations to be a foundational element of the design of cloud services. Some very basic considerations are noted here, with more detail discussed in further documentation.

Minimising Attack Surface

The attack surface of a system is the part of the system which a potential attacker can gain access to. For an external facing web service this may be the web server itself and the software that the web server runs; for a service accessible remotely via SSH this would be the SSH server and its underlying authentication mechanisms - the exact details are very dependent on the design of the service. Minimising the attack surface will reduce the number of potential vulnerabilities that an attacker can use to break into your system. Thus, a good design consideration for cloud services is to minimise the areas which can be accessed by an attacker, particularly those areas which are accessible without any authentication.

This also includes firewalling (or the use of security groups within OpenStack), which can be used to ensure that access to services is restricted to only the desired users. Note firewalls should always default to closed, not open - access which is not explicitly allowed should be denied.

Principle of Least Privilege

The principle of least privilege says that you should run services with the lowest possible privilege level that would allow the service to run - so for example, a simple web server could run as a user which only had access to the web content directory and nothing else, rather than running as a superuser who would have access to anything at all on the system. This is mostly standard practise in most Linux distributions, but is not always the case for software available outside the standard distribution. Regardless, it is an element that should be considered when building a new service.

Ongoing Security Updates

Any externally exposed service must be capable of being updated in order to bring in security fixes. This means that an externally exposed service which has no ongoing updates from the developer must be taken offline (or if absolutely necessary it should be moved behind a properly secured gateway, so that the service itself is not externally exposed).

Note this includes the OS which is running the service - this should be kept up to date, and the service should be rebuilt on newer releases as older releases go out of support.