Disconnected Environments

Disconnected environments help prevent unauthorized access and exfiltration of sensitive data. They eliminate the usual routes for cyber threats, providing an extra layer of protection for systems containing high-value data.

The key benefit of disconnected environments lies in their limited access points. Eliminating standard internet connectivity drastically reduces the avenues for potential cyber attacks. This principle is especially crucial when systems house sensitive data like financial transactions, popular targets for cyber threats. Data transfer in these settings requires strict protocols to ensure uncompromised isolation.

Disconnected environments efficiently control system access by eliminating standard internet connectivity. These environments significantly reduce potential access points to systems and applications, creating a more secure operational landscape.

This level of stringency is paramount in environments where even a minor breach could lead to significant disruption or damage, including those requiring high-integrity operations, processing classified information, and where strict regulatory compliance is a must. Here, disconnected environments function as secure citadels, stopping unwarranted intrusions and ensuring smooth operations.

Disconnected environments can play a vital role in multi-tenant architectures by ensuring tenant isolation and preventing a breach in one tenant’s setup from affecting others. Container-based applications run as an isolated process on the host OS, making them less prone to interference. These applications share a kernel, making them lightweight and scalable.

With multi-tenancy, applications can share data within the isolated environment without exposure to the internet, boosting the data’s security. Access control ensures only relevant and necessary applications reach the database’s sensitive information.

Red Hat OpenShift is an enterprise Kubernetes platform that functions seamlessly in connected and disconnected environments. Installing OpenShift in disconnected environments involves pre-downloading the required software and images to establish a local OpenShift cluster since it can’t access the internet. Only relevant servers can access this install, ensuring optimal security.

In collaboration with OpenShift’s Source-to-Image (S2I) builder, which helps build container images, this local cluster facilitates transforming your source code into a deployable containerized application, simplifying development and deployment in these environments.

After a service account creates a pod, OpenShift employs Security Context Constraints (SCCs) to define the pod’s actions and resources. SCCs are instrumental in setting up and implementing disconnected environments. They govern running pods as non-root users, prohibiting access to the host network, and preventing pods from using host volumes.

OpenShift also uses role-based access control (RBAC) and integrates Security-Enhanced Linux (SELinux) to enforce a configurable security policy over user and application behaviors, mitigating the risk of security breaches. SELinux labels all Linux OS aspects and only allows processes with exactly the same label to interact with the objects.

A local container image registry is a necessity in a disconnected environment. OpenShift has a built-in container image registry, managed by an infrastructure Operator, which integrates seamlessly with the cluster’s user authentication and authorization system. The local registry audits new images with stringent control to enhance supply-chain security with an additional layer of protection.

The disconnected install stands up an instance of Red Hat Quay, a private, distributed image registry platform, to serve images for the installation. This enterprise-level container image registry offers functions such as security scanning, robot accounts, and fine-grained access control for more complex requirements.