Secure resource publishing in OpenShift 4.x cluster

🌐 This document is available in both English and Ukrainian. Use the language toggle in the top right corner to switch between versions.

The functionality for secure route publishing in OpenShift 4.x cluster, and resource access control mechanism.

External access to the resources is performed via routes.

Route is an abstraction in OpenShift configuration, which allows for the deployment of web applications at generally available URLs.

1. Solution design

The following diagram displays the Platform components involved in requirement implementation and interaction between them.

secure-endpoints

The diagram shows the main traffic flows to the main operational zones (each zone has its list of allowed CIDRs):

operational-zones

2. Functional capabilities

The purpose is to provide secure access to the following components of OpenShift 4.x cluster:

  • Platform components;

  • Registry components;

  • Infrastructure components.

    You can learn more about each category here.

The Platform realizes access blocking functionality for every route on HAProxy level, the following way:

2.1. Registry components

  1. While creating a registry, an Administrator can set IP-addresses that will have access to the registry components. Platform administration UI adds the listed IP-addresses to values.yaml file into the registry configuration, in the following format:

    global:
  whiteListIP:
    adminRoutes: "192.168.1.64/26 172.16.0.192/27"
    officerPortal: "192.168.1.240/29"
    citizenPortal: "0.0.0.0/0"

    that is further used by components Helm-charts to deploy the registry with annotations in corresponding routes:

    metadata:
  annotations:
    haproxy.router.openshift.io/ip_whitelist: 192.168.1.64/26 172.16.0.192/27

    The administrator can set the IP-address lists separately for the Officer Portal, Citizen Portal, and administration components.

    Each component must include the public IP-address of the cluster. Keycloak must include all the CIDR from other operational zones, or be generally accessible, if the Citizen Portal has no restrictions.

    The adding interface looks like this:

    adding-route-registry-ui

    IP-address entering process:

    adding

    registry IP address list display and editing interface looks like this:

    editing-route-registry-ui

  2. During the editing of an existing registry, the administrator can add or delete IP-addresses with allowed access to registry components. Platform Administration UI updates the added IP-addresses in the values.yaml, in the registry configuration repository, which is then used by Helm-chart to deploy the registry. The adding interface looks the same as the one in the registry creation process.

2.2. Platform components, infrastructure components, and other routes

  1. In the "Cluster management" section, the administrator can set CIDR to restrict external access for platform and infrastructure components. The Administration UI creates a merge request for the values.yaml file, and after administrator approval, the cluster-mgmt pipeline performs the update and adding of required annotations.

  2. To add/change annotations in other routes that aren’t managed by Helm-charts, the annotate-routes stage of cluster-mgmt pipeline is used. values.yaml example:

    global:
  whiteListIP:
    adminRoutes: "192.168.1.64/26 172.16.0.192/27"
    The CIDR set by the administrator for the registry must also be added for platform components automatically.

3. Components and their function within the solution design

This section lists system components that are involved, or need to be changed/created within the realization of functional requirements according to the technical solution design.

Table 1

Component Service name Function

Administration UI

control-plane-console

Applying changes to the configuration of available communication channels for the registry target environment

Storing configurations for the platform and registries

control-plane-gerrit

Platform component for storing of configurations for the platform and registries

Platform and registries deployment

edp-library-stages-fork

Platform deployment pipeline

Table 2 lists the routes that must be restricted:

Table 2

Type Component Route

Registry

bp-admin-portal

business-process-administration-portal

Registry

admin-portal

admin-portal-kong-proxy

Registry

bp-webservice-gateway

bp-webservice-gateway

Registry

nexus

docker-registry, nexus

Registry

gerrit

gerrit

Registry

hashicorp-vault

hashicorp-vault

Registry

jenkins

jenkins

Registry

officer-portal

officer-portal-kong-proxy

Registry

registry-rest-api *

registry-rest-api

Registry

pgadmin *

pgadmin

Registry

registry-rest-api-external

registry-rest-api-external

Registry

redash

redash-admin, redash-viewer

Platform

control-plane-console

control-plane-console

Platform

gerrit

gerrit

Platform

jenkins

jenkins

Platform

nexus

nexus

Platform

ddm-architecture

ddm-architecture

Platform

external mocks *

sign-widget-mock, trembita-dracs-registry-mock, trembita-edr-registry-mock

Platform

hashicorp-vault

hashicorp-vault

Platform

keycloak

keycloak-management-console

Infrastructure

noobaa

noobaa-mgmt, s3

Infrastructure

openshift-monitoring

alertmanager-main, thanos-querier, prometheus-k8s, grafana

Infrastructure

openshift-logging

kibana

Infrastructure

openshift-console

console, downloads

Infrastructure

openshift-authentication

oauth-openshift

Infrastructure

istio

jaeger, kiali

Infrastructure

grafana

grafana-monitoring
* only in case of dev mode deployment

As a result, the system will deny any requests from IP addresses not included in the added annotations.