.png){kind=small}
Platform components
Cloud Networking
Nexorra Private Cloud utilizes OVS or OVN based Software Defined Networking. It implements "vertical isolation" for user tenants, ensuring that each tenant has no access to others. Within each project, "horizontal isolation" is achieved through subnets. Every project consists of "Frontend," "Backend," "Data," "K8S," and "Admin" subnets, allowing the deployment of any application type, whether it is VM-based or containerized.
Frontend subnet: Used for deploying front-end components of applications. Provides access to Backend and K8s subnets.
Backend subnet: Used for deploying backend components. Provides access to Data Frontend, Data, and K8S subnets.
Data subnet: Used for deploying VMs for databases or similar tools. Provides access to Backend and K8S subnets.
K8S subnet: Used for deploying Kubernetes. Each K8S subnet is created for a specific K8S cluster. If there are multiple K8S clusters in a project, multiple K8S subnets will be created. Provides access to all subnets except Admin.
Admin subnet: Used to deploy Jump host, observability, automation, and information security components. Provides access to all other subnets.
Load Balancer Service
L4/L7 load balancers enable load balancing between VM instances and applications.
Support for various protocols (TCP, UDP, HTTP, HTTPS, TERMINATED_HTTPS).
Flexible settings, including timeouts, working with headers and health checks.
Users can upload certificates for use in load balancers.
Public IP Addresses
Allows organization of access to VM instances and load balancers from the corporate network, outside the project.
DNS Service
Two unique DNS zones are created for each project in the cloud. One for classic applications, systems, and user services hosted on a VM. The second is for services and applications hosted in a Kubernetes cluster.
Users can create any type of DNS A records, including wildcard records.
Network Access Control as a Service
Automated and fast provisioning of cloud services alone does not guarantee full usability in an enterprise environment. Most enterprise applications require multiple integrations with both internal enterprise systems and external services. Integration itself is a significant enterprise topic, involving a shift from point-to-point integrations to standard API or event-based integration platforms that provide integration content.
Nexorra Private Cloud offers a compromise between quick and easy network access rights management, information security control, and enterprise architecture standardization. This is accomplished through the functionality of Security Groups. A Security Group is a set of rules that allows access to a defined set of IP addresses and ports. Essentially, we create and manage Security Groups that describe all enterprise integrations as master data, similar to managing material or partner master records in an ERP system.
Working with security groups involves cloud operations, the cloud security team, information security officers, and corporate architects. The automated process ensures quick and easy management.
Within the project, users can view the registry of security groups, which describes the network access rules.
Users select the required accesses in the project and generate a request for their provisioning.
The request is then verified by the cloud security officer, and upon confirmation, the security group becomes available for use in the project. Subsequently, it can be applied to VM instances and K8s cluster nodes, and network access will be automatically established.
The underlying mechanism for this functionality is a Git repository and the Security Group mechanism in OpenStack.
Detailed information about the security group is accessible through the platform portal, including traffic direction, protocol, port and IP ranges, as well as applications for integration.
The process of creating and approving new security groups is automated.
Security as Code
The management of security groups is based on the fact that the groups themselves and access to them are represented as code (manifests) in the repository.
This approach facilitates convenient change management, provides a comprehensive history view, and ensures that any access changes undergo approval by a cloud security officer.
Additionally, this approach is familiar to engineers and developers.