Architecture

Immutable Service Containers

Immutable Service Containers are an architectural deployment pattern used to describe a platform for highly secure service delivery. Building upon concepts and functionality enabled by operating systems, hypervisors, virtualization, and networking, ISCs provide a security-reinforced container into which a service or set of services is deployed.  By expressing core design principles, such as those embodied in the Sun Systemic Security strategy, along with functional and non-functional requirements, ISCs are not constrained to a particular product or technology, but rather can be implemented using a variety of ways.  As part of a more holistic view, it is expected that Immutable Service Containers will form the most basic architectural building block for more complex, highly adaptive and autonomic security architectures. The goal of this project is is to more fully describe the architecture and attributes of ISCs, their inherent benefits, their construction as well as to document practical examples using various web-scale software applications. 

Design Goals

• Limit Exposure
  • Only required network services are active and exposed.
  • Service is executed in a resource controlled context.
• Limit Change
  • Service (binaries, libraries, configuration, etc.) is read-only [1]
  • Critical operating environment configuration is read-only [1]
• Limit Rights
  • Service is executed with unique credentials, least privilege
  • Operating environment is run with reduced privileges
• Improve Integrity
  • Service is isolated from security monitoring and enforcement.

[1] Where supported by the underlying product or function.

Operating Principles

Immutable Service Containers strive to implement the following key security principles: 

• Self-Preservation
• Defense in Depth
• Compartmentalization
• Least Privilege
• Proportionality

For a discussion of these principles, see the Sun BluePrints article titled Toward Systemically Secure IT Architectures.  In addition, Immutable Service Containers design borrows from Cloud Computing principles including:

• Abstraction
• (Micro-)Virtualization
• Automation
• Fail in Place

Architectural Patterns

Secure Execution Container

Name (Title)	Secure Execution Container
Description	A container that is able to provide a safe environment where applications, jobs, or services can be run.  Specifically, a Secure Execution Container should be capable of providing security enforcement and monitoring functions such that it can protect a running services from unauthorized external influence (originating outside of the container).  Further it must also be capable of protecting the IT environment from the service in the event of an accidental or malicious change that causes the service to behave badly.  The degree to which protection is afforded will vary based upon the actual implementation choices made, but as a rule, it is expected that the security configuration of the Secure Execution Container will be tuned based upon the services it supports.  It will likely involve the integration of one or more technologies or products in support of its security objectives.
Alias	SEC
Intent	The intent is to construct a safe environment for the execution of services capable of: Protecting itself from unauthorized access or use by the services running within it. Protecting any service running within the container from unauthorized external influence. Protecting the IT environment and other services outside of the container (should a running service be mis-configured or compromised). Providing an audit trail of events occurring within the container for monitoring and analysis.
Motivation	Services running in an unsecured container are often susceptible to attacks from the outside that can damage the service or container.  Likewise the environment beyond the container could be adversely affected by malicious code from within the container.  It is thus imperative for a container that runs applications or services to protect itself from compromised or malicious external services and similarly to protect the outside environment should anything unexpected happen to services it is hosting.  This pattern includes three logical boundary elements: Outside - This is beyond the boundary of the container and is where all requests to interact with the container's service originate. Inside - This is inside of the boundary where the container's service and all of its constituent parts are located. Boundary - This is a correct, verifiable, boundary "container" that cannot be bypassed and only exposes permitted interfaces to the _outside_ while enforcing allowed policy on components running on the _inside_.
Applicability	The Secure Execution Container pattern can be used in most IT environments and with virtually any service. It is especially important for those environments seeking stronger security protections for the purposes of risk reduction and attack mitigation. By providing a controlled boundary through which services can be accessed, the Secure Execution Container is able to provide enhanced security protections for the service and the environment in which the service is hosted.  This pattern is most useful when there are clear, well-defined interfaces for interacting with the service or when there is no direct need for service interaction (such as in the case of batch processing).
Structure
Participants	Service.  A Service is the object that is installed and executed within the Secure Execution Container.  It could be a composite application, a single service or a batch job.  There are no restrictions on the type of service that can be used within an ISC although those with well-defined communication and processing interfaces are more suited to this type of environment.  The actual service used will determine what security protections are needed in terms of the service itself. Secure Execution Container.  The Secure Execution Container provides a security boundary around the Service.  External clients can interact with the Service through published interfaces and the Service can also initiate messages to outside services through this interface.  All communications and access methods are arbitrated by the Secure Execution Container's security boundary. Security Hardened Service Container. This is a operational quality of the Secure Execution Container.  This element is used to depict the need to properly implement security hardening and configuration tuning of the container in which the Service is delivered.  The actual steps taken to secure this container will vary based upon the implementation chosen. Service Container Security Functions.  This is a functional element of the Secure Execution Container.  This element is used to depict the need for security enforcement and monitoring functions that exist in the Secure Execution Container and are used to implement the protections described in the Intent section above.  The actual security controls available and used will vary based upon the implementation chosen.
Collaboration	See the Participants section above to understand the relationships between the various elements of this pattern.
Consequences	The primary benefits of the Secure Execution Container pattern are related to the isolation of a service running inside a security boundary that helps to protect both the service and the environment within which it runs from unauthorized access and influence.  Certainly, it is expected that all products used in the implementation of this pattern will be configured to use recommended security practices and as such it is expected that the overall attack surface of the SEC and its Service will be minimized.  As the actual techniques used to implement the security configuration will vary by implementation, it is expected that specific products will be chosen based upon operational and security policy and requirements.  While the notion of Secure Execution Containers is a general one that can accommodate most services, it must be noted that services with variable or ill-defined access methods or interfaces may not be suited for this particular pattern.
Implementation	Immutable Service Container Node
Known uses	OpenSolaris and Solaris 10 Zones, J2EE Containers, Java Sandbox
Related patterns	Immutable Service Container Node, Immutable Service Container Dock
Author	Rafat Alvi, Glenn Brunette, Joel Weise
Reviewer	Ed Clay, Joel Weise

Immutable Service Container Dock

Immutable Service Container Node

Architectural Diagrams

Single Service Container

Elastic Service Containers

Additional designs that leverage alternative private virtual networking models are discussed on the Networking page.

Use Cases

• Autonomic Security use cases