Services Exposure¶

Basic Configuration¶

Each Suite contains some services that needs to be exposed to the external of the cluster (e.g., the Shell Backend in the ICOS Controller, the Telemetry Gateway in the ICOS Agent). All the suites uses the same approach to configure the exposure of the services that allows a minimal configuration. It is based on two Helm values:

• url that defines the base url or IP used to derive the url/IP where each single service of the sute will be exposed
• routing that defines the method to use to multiplex the different services of the suite from the url.

The url parameter can be an ip address or a valid url with protocol (defaults to http), host (mandatory), port (defaults to 80 or 443) and path (defaults to /). Valid values are:

• http://192.168.100.30/
• https://10.160.3.100:31000/
• https://my-icos-controller.com/
• http://my-icos-controller.com:31200/acme
• my-icos-controller

The routing parameter can be one of:

• host: expose each service to a different subdomain of url
• path: expose each service to a different path of url
• port: expose each service to a different port of url

Based on those two parameters the Helm templates will derivce the exact way each service of the suite will be exposed to the extern.

The choose of the URL and the routing mechanism to use for exposing the services of an ICOS node will depend on the options available in the cluster and the infrastructure where the node is going to be installed (e.g., in some infrastructures only ports 80 and 443 are open, so port routing is not an option) and from the user preferences.

Host Routing¶

Given the ICOS Core Suite as example, if the Helm values are:

global:
  core:
    url: https://my-icos-core.example.org/
    routing: host

the suite's services will be exposed at:

The name of the subdomains for each service can be customized with the global.core.ca.config.subdomain, global.core.iam.config.subdomain and global.core.lighthouse.config.subdomain values respectively.

Path Routing¶

Given the ICOS Core Suite as example, if the Helm values are:

global:
  core:
    url: https://my-icos-core.example.org/
    routing: path

the suite's services will be exposed at:

The name of the subdomains for each service can be customized with the global.core.ca.config.path, global.core.iam.config.path and global.core.lighthouse.config.path values respectively.

Port Routing¶

Given the ICOS Core Suite as example, if the Helm values are:

global:
  core:
    url: 10.160.3.100
    routing: port

the suite's services will be exposed at:

The name of the subdomains for each service can be customized with the global.core.ca.config.port, global.core.iam.config.port and global.core.lighthouse.config.port values respectively.

ICOS Ingress Controller¶

The host and path routing mechanisms make use of Ingress and Certificate resources. The ICOS Suites will automatically generate the appropriate resources based on the url and routing values, but an additional software to handle those resources is needed at cluster level.

In order to simplify the deployment and reduce the requirements to install the ICOS Suites, it is possible to install all the required software directly using the ICOS Ingress Controller Helm Chart (also available as dependency of each ICOS Suite Chart).

The ICOS Ingress Controller chart contains the following components: - NGINX Ingress Controller to deploy a reverse proxy that manage the exposure of the internal services using the configuration provided through the Ingresses - Cert Manager to autoamte the generation and renewal of TLS certificates for each service of the ICOS Suites exposed to the extern - Step Issuer a component that creates required TLS certificates contacting the ICOS CA.

In each ICOS Suite Helm chart, it is possible to deploy the ICOS Ingress Controller with the following value:

icos-ingress-controller:
  enabled: true

Documentation on more configuration options is available in GitHub.

Insecure exposure with http¶

It is possible to expose the ICOS services also using the http protocol. However this is not recommended for obvious security risks.

In order to deploy an insecure ICOS Core Suite with a path routing using http, the follwoing values can be used an example:

global:
  core:
    url: my-insecure-core.com
    routing: path

# we disable the CA because it will not be needed
icos-ca:
  enabled: false

icos-ingress-controller:
  step-issuer:
    enabled: false
  cert-manager:
    enabled: false
  nginx-ingress-controller:
    config:
      ssl-redirect: "false"

icos-iam:
  keycloak:
    ingress:
      tls: false

icos-lighthouse:
  ingress:
    tls: []

In order to deploy an ICOS Controller using port routing the following values can be used as an example:

global:
  controller:
    url: 192.168.100.100
    routing: port

icos-ingress-controller:
  enabled: false