Chapter 5. Using ingress control for a MicroShift node
Use the ingress controller options in the MicroShift configuration file to make pods and services accessible outside the node.
5.1. Using ingress control in MicroShift Copy linkLink copied to clipboard!
When you create your MicroShift node, each pod and service running on the node is allocated an IP address. These IP addresses are accessible to other pods and services running nearby by default, but are not accessible to external clients. MicroShift uses a minimal implementation of the OpenShift Container Platform IngressController API to enable external access to node services.
With more configuration options, you can fine-tune ingress to meet your specific needs. To use enhanced ingress control, update the parameters in the MicroShift configuration file and restart the service. Ingress configuration is useful in a variety of ways, for example:
-
If your application starts processing requests from clients but the connection is closed before it can respond, you can set the
ingress.tuningOptions.serverTimeoutparameter in the configuration file to a higher value to accommodate the speed of the response from the server. -
If the router has many connections open because an application running on the node does not close connections properly, you can set the
ingress.tuningOptions.serverTimeoutandspec.tuningOptions.serverFinTimeoutparameters to a lower value, forcing those connections to close sooner. -
If you need to configure the ingress controller to verify client certificates, you can use the
ingress.clientTLSparameter to set a clientCA value, which is a reference to a config map. The config map contains the PEM-encoded CA certificate bundle that is used to verify a client’s certificate. Optionally, you can also configure a list of certificate subject filters. -
If you need to configure a TLS security profile for an ingress controller, you can use the
ingress.tlsSecurityProfileparameter to specify a default or custom individual TLS security profiles. The TLS security profile defines the minimum TLS version and the TLS ciphers for TLS connections for the ingress controllers. If a TLS security profile is not configured, the default value is based on the TLS security profile set for the API server. -
If you need to define a policy for handling new route claims, you can use the
routeAdmissionparameter to allow or deny claims across namespaces. You set therouteAdmissionparameter to describe how hostname claims across namespaces should be handled and to describe how routes with wildcard policies are handled by the ingress controller.
5.2. Configuring ingress control in MicroShift Copy linkLink copied to clipboard!
You can use detailed ingress control settings by updating the MicroShift service configuration file or using a configuration snippet.
-
A
config.yamlconfiguration file takes precedence over built-in settings. Theconfig.yamlfile is read every time the MicroShift service starts. -
Configuration snippet YAMLs take precedence over both built-in settings and the
config.yamlconfiguration file.
Prerequisites
-
You installed the OpenShift CLI (
oc). - You have root access to the node.
- Your node uses the OVN-Kubernetes Container Network Interface (CNI) plugin.
Procedure
Apply ingress control settings in one of the two following ways:
-
Update the MicroShift
config.yamlconfiguration file by making a copy of the providedconfig.yaml.defaultfile in the/etc/microshift/directory, naming itconfig.yamland keeping it in the source directory. -
Use a configuration snippet to apply the ingress control settings you want. To do this, create a configuration snippet YAML file and put it in the
/etc/microshift/config.d/configuration directory.
-
Update the MicroShift
Replace the default values in the
ingresssection of the MicroShift YAML with your valid values, or create a configuration snippet file with the sections you need.Ingress controller configuration fields with default values
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Expand Table 5.1. Ingress controller configuration fields definitions table Parameter Description ingressThe
ingresssection of the MicroShiftconfig.yamlfile defines the configurable parameters for the implemented portions of the OpenShift Container Platform Ingress Control Operator. All parameters in the rest of this table are subsections in theingresssection of theconfig.yaml.certificateSecretA reference to a
kubernetes.io/tlstype of secret that contains the default certificate that is served by the MicroShift ingress controller. When routes do not specify their own certificate, thecertificateSecretparameter is used. All secrets used must containtls.keykey file contents andtls.crtcertificate file contents.-
When the
certificateSecretparameter is not set, a wildcard certificate is automatically generated and used. The wildcard certificate is valid for the ingress controller defaultdomainand itssubdomains. The generated certificate authority (CA) is automatically integrated with the truststore of the node. - In-use generated and user-specified certificates are automatically integrated with the MicroShift built-in OAuth server.
clientTLSAuthenticates client access to the node and services. As a result, mutual TLS authentication is enabled. If not set, then client TLS is not enabled. You must set the
spec.clientTLS.clientCertificatePolicyandspec.clientTLS.ClientCAparameters to use client TLS.clientTLS.AllowedSubjectPatternsOptional subfield that specifies a list of regular expressions that are matched against the distinguished name on a valid client certificate to filter requests. Use this parameter to cause the ingress controller to reject certificates based on the distinguished name. The Perl Compatible Regular Expressions (PCRE) syntax is required.
ImportantWhen configured, this field must contain a valid expression or the MicroShift service fails. At least one pattern must match a client certificate’s distinguished name; otherwise, the ingress controller rejects the certificate and denies the connection.
clientTLS.clientCASpecifies a required config map that is in the
openshift-ingressnamespace. Required to enable client TLS. The config map must contain a certificate authority (CA) bundle namedca-bundle.pemor the deployment of the default router fails.clientTLS.ClientCA.nameThe
metadata.nameof the config map referenced in theclientTLS.ClientCAvalue.clientTLS.ClientCertificatePolicyRequiredorOptionalare valid values. Set toRequiredto enable client TLS. The ingress controller only checks client certificates for edge-terminated and re-encrypted TLS routes. The ingress controller cannot check certificates for plain text HTTP or passthrough TLS routes.defaultHTTPVersionSets the HTTP version for the ingress controller. Default value is
1for HTTP 1.1.forwardedHeaderPolicySpecifies when and how the ingress controller sets the
Forwarded,X-Forwarded-For,X-Forwarded-Host,X-Forwarded-Port,X-Forwarded-Proto, andX-Forwarded-Proto-VersionHTTP headers. The following values are valid:-
Appendpreserves any existing headers by specifying that the ingress controller appends them. 'Append` is the default value. -
Replaceremoves any existing headers by specifying that the ingress controller sets the headers. -
IfNonesets the headers set by specifying that the ingress controller sets the headers if they are not already set. -
Neverpreserves any existing headers by specifying that the ingress controller never sets the headers.
httpCompressionDefines the policy for HTTP traffic compression.
httpCompression.mimeTypesDefines a list of MIME types to which compression should be applied.
-
For example,
text/css; charset=utf-8,text/html,text/*,image/svg+xml,application/octet-stream,X-custom/customsub, in the,type/subtype; [;attribute=value]format. -
Valid
typesare: application, image, message, multipart, text, video, or a custom type prefaced byX-. To see the full notation for MIME types and subtypes, see RFC1341 (IETF Datatracker documentation).
httpEmptyRequestsPolicyDescribes how HTTP connections are handled if the connection times out before a request is received. Allowed values for this field are
RespondandIgnore. The default value isRespond. Empty requests typically come from load-balancer health probes or preconnects and can often be safely ignored. However, these requests can also be caused by network errors and port scans. Therefore, setting this field toIgnorecan impede detection or diagnosis of network problems and detecting intrusion attempts.-
When the policy is set to
Respond, the ingress controller sends an HTTP400or408response, logs the connection if access logging is enabled, and counts the connection in the appropriate metrics. -
When the policy is set to
Ignore, thehttp-ignore-probesparameter is added to theHAproxyprocess configuration. After this parameter is added, the ingress controller closes the connection without sending a response, then either logs the connection or incrementing metrics.
logEmptyRequestsSpecifies connections for which no request is received and logged.
LogandIgnoreare valid values. Empty requests typically come from load-balancer health probes or preconnects and can often be safely ignored. However, these requests can also be caused by network errors and port scans. Therefore, setting this field toIgnorecan impede detection or diagnosis of network problems and detecting intrusion attempts. The default value isLog.-
Setting this value to
Logindicates that an event should be logged. -
Setting this value to
Ignoresets thedontlognulloption in theHAproxyconfiguration.
portsDefines default router ports.
ports.httpDefault router http port. Must be in range 1-65535. Default value is
80.ports.httpsDefault router https port. Must be in range 1-65535. Default value is
443.routeAdmissionDefines a policy for handling new route claims, such as allowing or denying claims across namespaces.
routeAdmission.namespaceOwnershipDescribes how hostname claims across namespaces should be handled. The default is
InterNamespaceAllowed. The following are valid values:-
Strictdoes not allow routes to claim the same hostname across namespaces. -
InterNamespaceAllowedallows routes to claim different paths of the same hostname across namespaces.
routeAdmission.wildcardPolicyControls how routes with configured wildcard policies are handled by the ingress controller.
WildcardsAllowedandWildcardsDisallowedare valid values. Default value isWildcardsDisallowed.-
WildcardPolicyAllowedmeans that routes with any wildcard policy are admitted by the ingress controller. -
WildcardPolicyDisallowedmeans that only routes with a wildcard policy ofNoneare admitted by the ingress controller.
ImportantChanging the wildcard policy from
WildcardsAllowedtoWildcardsDisallowedcauses admitted routes with a wildcard policy ofsubdomainto stop working. These routes must be recreated to a wildcard policy ofNoneto be readmitted by the ingress controller.statusDefault router status.
ManagedorRemovedare valid values.tlsSecurityProfiletlsSecurityProfilespecifies settings for TLS connections for ingress controllers. If not set, the default value is based on theapiservers.config.openshift.io/clusterresource. The TLS1.0version of anOldorCustomprofile is automatically converted to1.1by the ingress controller.Intermediateis the default setting.-
The minimum TLS version for ingress controllers is
1.1. The maximum TLS version is1.3.
NoteCiphers and the minimum TLS version of the configured security profile are reflected in the
TLSProfilestatus. Profiles are intent-based and change over time when new ciphers are developed and existing ciphers are found to be insecure. The usable list can be reduced depending on which ciphers are available to a specific process.tlsSecurityProfile.customUser-defined TLS security profile. If you configure this parameter and related parameters, use extreme caution.
tlsSecurityProfile.custom.ciphersSpecifies the cipher algorithms that are negotiated during the TLS handshake. Operators might remove entries their operands do not support.
tlsSecurityProfile.custom.minTLSVersionSpecifies the minimal version of the TLS protocol that is negotiated during the TLS handshake. For example, to use TLS versions 1.1, 1.2 and 1.3, set the value to
VersionTLS11. The highest valid value forminTLSVersionisVersionTLS12.tlsSecurityProfile.intermediateThis TLS profile can be used for a majority of services. Intermediate compatibility (recommended).
tlsSecurityProfile.oldUsed for backward compatibility. Old backward compatibility.
tlsSecurityProfile.typeValid values are
Intermediate,Old, orCustom. TheModernvalue is not supported.tuningOptionsSpecifies options for tuning the performance of ingress controller pods.
tuningOptions.clientFinTimeoutSpecifies how long a connection is held open while waiting for the client response to the server closing the connection. The default timeout is
1s.tuningOptions.clientTimeoutSpecifies how long a connection is held open while waiting for a client response. The default timeout is
30s.tuningOptions.headerBufferBytesSpecifies how much memory is reserved, in bytes, for ingress controller connection sessions. This value must be at least
16384if HTTP/2 is enabled for the ingress controller. If not set, the default value is32768bytes.ImportantSetting this field not recommended because
headerBufferMaxRewriteBytesparameter values that are too small can break the ingress controller. Conversely, values forheaderBufferMaxRewriteBytesthat are too large could cause the ingress controller to use significantly more memory than necessary.tuningOptions.headerBufferMaxRewriteBytesSpecifies how much memory should be reserved, in bytes, from
headerBufferBytesfor HTTP header rewriting and appending for ingress controller connection sessions. The minimum value forheaderBufferMaxRewriteBytesis4096.headerBufferBytesmust be greater than theheaderBufferMaxRewriteBytesvalue for incoming HTTP requests. If not set, the default value is8192bytes.ImportantSetting this field is not recommended because
headerBufferMaxRewriteBytesvalues that are too small can break the ingress controller andheaderBufferMaxRewriteBytesthat are too large could cause the ingress controller to use significantly more memory than necessary.tuningOptions.healthCheckIntervalSpecifies how long the router waits between health checks, set in seconds. The default is
5s.tuningOptions.maxConnectionsSpecifies the maximum number of simultaneous connections that can be established for each
HAProxyprocess. Increasing this value allows each ingress controller pod to handle more connections at the cost of additional system resources. Permitted values are0,-1, any value within the range2000and2000000, or the field can be left empty.-
If this field is left empty or has the value
0, the ingress controller uses the default value of50000. -
If the field has the value of
-1, then theHAProxyprocess dynamically computes a maximum value based on the availableulimitsin the running container. This process results in a large computed value that incurs significant memory usage compared to the current default value of50000. -
If the field has a value that is greater than the current operating system limit, the
HAProxyprocesses do not start. -
If you choose a discrete value and the router pod is migrated to a new node, it is possible that the new node does not have an identical
ulimitconfigured. In such cases, the pod fails to start. -
If you have nodes with different
ulimitsconfigured, and you choose a discrete value, you can use the value of-1for this field so that the maximum number of connections is calculated at runtime. -
You can monitor memory usage for router containers with the
container_memory_working_set_bytes{container="router",namespace="openshift-ingress"}metric. -
You can monitor memory usage of individual
HAProxyprocesses in router containers with thecontainer_memory_working_set_bytes{container="router",namespace="openshift-ingress"}/container_processes{container="router",namespace="openshift-ingress"}metric.
tuningOptions.serverFinTimeoutSpecifies how long a connection is held open while waiting for the server response to the client that is closing the connection. The default timeout is
1s.tuningOptions.serverTimeoutSpecifies how long a connection is held open while waiting for a server response. The default timeout is
30s.tuningOptions.threadCountSpecifies the number of threads to create per
HAProxyprocess. Creating more threads allows each ingress controller pod to handle more connections, at the cost of more system resources being used. TheHAProxyload balancer supports up to64threads. If this field is empty, the ingress controller uses the default value of4threads.ImportantSetting this field is not recommended because increasing the number of
HAProxythreads allows ingress controller pods to use more CPU time under load, and prevent other pods from receiving the CPU resources they need to perform. Reducing the number of threads can cause the ingress controller to perform poorly.tuningOptions.tlsInspectDelaySpecifies how long the router can hold data to find a matching route. Setting this value too low can cause the router to fall back to the default certificate for edge-terminated, re-encrypted, or passthrough routes, even when using a better-matched certificate. The default inspect delay is
5s.tuningOptions.tunnelTimeoutSpecifies how long a tunnel connection, including websockets, remains open while the tunnel is idle. The default timeout is
1h.-
When the
Complete any other configurations you require, then start or restart MicroShift by running one the following commands:
sudo systemctl start microshift
$ sudo systemctl start microshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow sudo systemctl restart microshift
$ sudo systemctl restart microshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
After making ingress configuration changes and restarting MicroShift, you can check the age of the router pod to ensure that changes have been applied.
To check the status of the router pod, run the following command:
oc get pods -n openshift-ingress
$ oc get pods -n openshift-ingressCopy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
NAME READY STATUS RESTARTS AGE router-default-8649b5bf65-w29cn 1/1 Running 0 6m10s
NAME READY STATUS RESTARTS AGE router-default-8649b5bf65-w29cn 1/1 Running 0 6m10sCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.1. Creating a secret for the ingress controller certificateSecret Copy linkLink copied to clipboard!
Use this procedure to create a secret that is referenced by the certificateSecret parameter value in the MicroShift configuration file. This secret contains the default certificate served by the ingress controller.
Any in-use certificates is automatically integrated with the MicroShift built-in OAuth server.
Prerequisites
- You have root access to MicroShift.
-
You installed the OpenShift CLI (
oc). - Your private key is not encrypted or you have decrypted it for importing into MicroShift.
Procedure
Create a secret that contains the wildcard certificate chain and key:
oc create secret tls <secret> --cert=</path/to/cert.crt> --key=</path/to/cert.key> -n openshift-ingress$ oc create secret tls <secret>1 --cert=</path/to/cert.crt>2 --key=</path/to/cert.key>3 -n openshift-ingressCopy to Clipboard Copied! Toggle word wrap Toggle overflow ImportantThe certificate must include the
subjectAltNameextension showing*.apps.<nodename>.<domain>.-
Update the
certificateSecretparameter value in the MicroShift configuration YAML with the newly created secret. Complete any other configurations you require, then start or restart MicroShift by running one the following commands:
sudo systemctl start microshift
$ sudo systemctl start microshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow sudo systemctl restart microshift
$ sudo systemctl restart microshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.2. Configuring the TLS security profile for the ingress controller Copy linkLink copied to clipboard!
You can configure the TLS security profile for the ingress controller to use by setting the type in MicroShift configuration YAML.
Prerequisites
- You have root access to the MicroShift node.
Procedure
Add the
spec.tlsSecurityProfilefield to the MicroShift YAML configuration file.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Specify the TLS security profile type (
Old,Intermediate, orCustom). The default isIntermediate. - 2
- Specify the appropriate field for the selected type:
-
old: {} -
intermediate: {} -
custom:
-
- 3
- For the
customtype, specify a list of TLS ciphers and minimum accepted TLS version.WarningIf you choose a
customTLS configuration, use extreme caution. Using self-signed TLS certificates can introduce security risks.
- Save the file to apply the changes.
Restart MicroShift by running the following command:
sudo systemctl restart microshift
$ sudo systemctl restart microshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow