Copyright

Copyright © 2019 Balasys IT Ltd.. All rights reserved. This document is protected by copyright and is distributed under licenses restricting its use, copying, distribution, and decompilation. No part of this document may be reproduced in any form by any means without prior written authorization of Balasys.

This documentation and the product it describes are considered protected by copyright according to the applicable laws.

This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/). This product includes cryptographic software written by Eric Young (eay@cryptsoft.com)

Linux™ is a registered trademark of Linus Torvalds.

Windows™ 10 is registered trademarks of Microsoft Corporation.

The Balasys™ name and the Balasys™ logo are registered trademarks of Balasys IT Ltd.

The Proxedo™ name and the Proxedo™ logo are registered trademarks of Balasys IT Ltd.

AMD Ryzen™ and AMD EPYC™ are registered trademarks of Advanced Micro Devices, Inc.

Intel® Core™ and Intel® Xeon™ are trademarks of Intel Corporation or its subsidiaries in the U.S. and/or other countries.

All other product names mentioned herein are the trademarks of their respective owners.

DISCLAIMER

Balasys is not responsible for any third-party websites mentioned in this document. Balasys does not endorse and is not responsible or liable for any content, advertising, products, or other material on or available from such sites or resources. Balasys will not be responsible or liable for any damage or loss caused or alleged to be caused by or in connection with use of or reliance on any such content, goods, or services that are available on or through any such sites or resources.

2023-12-07 .Copyright

Preface

Typographical conventions

Before you start using this guide, it is important to understand the terms and typographical conventions used in the documentation. For more information on specialized terms and abbreviations used in the documentation, see the Glossary at the end of this document.

The following text formatting principles and icons identify special information in the document.

Tips provide best practices and recommendations.
Notes provide additional information on a topic, and emphasize important facts and considerations.
Warnings mark situations where loss of data or misconfiguration of the device is possible if the instructions are not obeyed.
Command

Commands you have to execute.

Emphasis

Reference items, additional readings.

/path/to/file

File names.

Parameters

Parameter and attribute names.

In the parameter listing tables the required parameters are also emphasized with bold text:

Key Description

param1

This is a required parameter.

param2

This is an optional parameter.

Additional marks used specifically in the Web User Interface (UI):

Key Description

*

The elements marked with * in the configuration reference tables are mandatory to be configured.

(Default)

For some of the configuration elements there are recommended default values, marked as (Default). In case the value is not defined during the configuration, the default value will be considered for the actual element.

+

By clicking this sign you can add the actual element to the list of configuration elements.

Contact and support information

This product is developed and maintained by Balasys IT Ltd..

Contact:

Balasys IT Ltd.
4 Alíz Street
H-1117 Budapest, Hungary
Tel: +36 1 646 4740
E-mail: <info@balasys.hu>
Web: http://balasys.hu/

Sales contact

You can directly contact us with sales-related topics at the e-mail address <sales@balasys.hu>, or leave us your contact information and we call you back.

Support contact

To access the Balasys Support System, sign up for an account at the Balasys Support System page. Online support is available 24 hours a day.

Balasys Support System is available only for registered users with a valid support package.

Support e-mail address: <support@balasys.hu>.

Training

Balasys IT Ltd. holds courses on using its products for new and experienced users. For dates, details, and application forms, visit the https://www.balasys.hu/en/services#training webpage.

1. Scope of this document

This document describes the Web User Interface for the Proxedo API Security in Kubernetes. The purpose of this document is to present the designed approach and the usage for the configuration of Proxedo API Security via Web User Interface (UI). The Web UI allows easy configuration for Proxedo API Security. All the functionalities are grouped visually and logically into thematic units which follow the logical built up of Proxedo API Security’s configuration. The primary intended audience of this document are system engineers and system designers for configuring Proxedo API Security systems.

2. Introduction to Proxedo API Security

2.1. What is Proxedo API Security

The Proxedo API Security (PAS) is a security solution that protects API serving endpoints. It is positioned in the network flow between consumers of the APIs (clients) and backend solutions serving the API (servers) as a transparent HTTP proxy.

Proxedo API Security can:

  • handle incoming Transport Layer Security v1 (TLS) connections from clients & outgoing TLS connections to servers separately and selectively

  • verify that the communication conforms to HTTP specifications

  • verify that the content of the messages conform to their specified content type

  • verify that the content of messages conform to API specification(s) as described in schemas

  • evaluate the level of risk with regards to the API call using the data collected from call data

  • provide rule-based protection against a variety of web-based application layer attacks

  • extract parts of the content of the messages and relay them to external data stores such as log servers, SIEM systems or other data warehouses

2.2. Where to start

Depending on what you need to do the following starting points are suggested:

3. Overview of Proxedo API Security

3.1. Main features

3.1.1. TLS

Transport Layer Security v1 (TLS) (successor of the now obsoleted Secure Socket Layer v3 (SSL)) is a widely used crypto protocol, guaranteeing data integrity and confidentiality in many PKI and e-commerce systems.

The TLS framework inspects TLS connections, and also any other connections embedded into the encrypted TLS channel. TLS connections initiated from the client are terminated on the Proxedo API Security, and two separate TLS connections are built: one between the client and the firewall, and one between the firewall and the server. If both connections match the configuration settings of PAS (for example, the certificates are valid, and only the allowed encryption algorithms are used), PAS inspects the protocol embedded into the secure channel as well. Note that the configuration settings can be different for the two connections, for example, it is possible to permit different protocol versions and encryption settings.

3.1.2. Enforcement

Proxedo API Security acts as an HTTP proxy and verifies that the traffic passing through conforms to HTTP’s specifications. By using OpenAPI schemas, as defined in OpenAPI specifications (also known as Swagger), it also verifies that the traffic passing through conforms to the API endpoint’s specification and can log or deny non-conforming traffic.

PAS also provides its own versatile filtering system to control passing traffic.

3.1.3. Fraud Detection

The Fraud Detection module of Proxedo API Security reduces the number of fraudulent transactions by harnessing device fingerprinting and enriching incoming data with alternate sources to provide the best accuracy and details about transactions.

3.1.4. Rule-based Enforcement

Besides its positive security model approach, Proxedo API Security also has a web application firewall module. The WAF Enforcer protects against a variety of application layer attacks including credential theft, code injection, cross-site scripting (XSS), cookie poisoning, CSRF, SQL injection, DoS, ransomware, and more.

3.1.5. Insights

With Proxedo API Security it is possible to extract business-relevant information with extremely high resolution from the traffic and relay it to external data stores where further analysis can be implemented.

Thus, it is possible to feed Log Management solutions, Monitoring and SIEM systems, Data visualization tools with data extracted from the traffic, even to the level of specific fields deep inside API calls or URI parameters.

3.1.6. Security flow

The security flow binds most of PAS’s features together. It allows flexible configuration for handling the traffic. Multiple Enforcement, Filter and Insight plugins can be mix-and-matched with control over error policies.

3.2. Main Concepts in Proxedo API Security

This chapter provides an overview of the Proxedo API Security solution, introduces its main concepts, and explains the relationship of the various components.

API Endpoint

Proxedo API Security protects API endpoints. An API endpoint is the serving part of the communication channel and is the collection of all functions of a service. It resides at a list of well-known top URIs under which all the functions are accessible. APIs have well-defined HTTP Endpoints for all exposed calls, resources etc., usually through providing a schema that describes all parameters of these URI paths, including possible HTTP response codes, the format and fields of the data structure in the request’s and response’s body.

Client

It is a consumer of API endpoints. It is the source of the requests.

Backend

The backend constitutes of one or more servers that serve the API endpoint. It receives the requests of the client and sends the responses.

HTTP message

It can be an HTTP request coming from the client or an HTTP response coming from the backend.

Call

An HTTP conversation constitutes of a request — response interchange of HTTP messages between the client and the backend. Whenever the direction is irrelevant in the context — it applies to both requests and responses — the message is named Call.

Listener

It is the part of PAS that listens to incoming traffic for given API Endpoints. It is bound to a network port. Clients address this port when accessing API Endpoints through the gateway.

TLS

Transport Layer Security is the cryptographic protocol that secures HTTPS communications. PAS can apply TLS encryption both when communicating with Clients and Backends. TLS encryption can also be used with Syslog Insight Target and Elastic Insight Target.

Security flow

It provides a collection of security rules that PAS applies to a Call. It is two series of Plugins: one for requests and one for responses.

Plugin

It is an element of the security flow that applies a specific security function. It has different types based on the role they do.

Decompressor

A Plugin responsible for decompressing compressed content in the HTTP message’s body. This ensures that the original content of the message is available for processing.

Compressor

A Plugin responsible for compressing the result of a flow and forwarding the compressed content.

Deserializer

A Plugin responsible for parsing the HTTP message’s body to structured data. This ensures that a message is well-formed. The structured data will also be consumed by other Plugins that operate on the body of the message.

Serializer

A Plugin responsible for serializing the structured data to the format of the HTTP message’s body.

Filter

A Plugin that rejects calls when they match defined rules.

Enforcer

A Plugin that validates calls against externally defined schemas.

Insight

A Plugin that extracts various data from the call and sends it to external systems (log servers, SIEMs, and other data analysis tools).

Brick

They are reusable components of Plugins. They can be defined on their own and then shared by multiple Plugins.

Error policy

It is a brick that defines what happens if the Plugin has found an error. It decides if calls are rejected or merely logged, and defines the details of the HTTP error response sent to the client if a call is rejected.

Matcher

It is a brick that decides if the Plugin should be executed for a given call by checking various data in the HTTP message.

Selector

Selector is a brick that can extract a piece of information from a call. It is used by Insight plugins.

Insight Target

It is a brick that defines an external system to send extracted data to. It is used by Insight plugins.

3.3. Architecture for Proxedo API Security

Proxedo API Security is based on a micro-services architecture.

The components of the architecture are each responsible for well-defined subset of handling traffic between the client and the backend. Proxedo API Security is built up of three components:

Transport Director

It manages the transport layer of API connections:

  • handles network connections from the client

  • handles network connections towards the backends

  • handles TLS on these connections

  • load-balances between multiple backend servers

  • load-balances between multiple Flow Directors

  • enforces HTTP protocol validity in calls

Flow Director

It is responsible for the execution of the Plugins in the Endpoint’s flow and for applying Error Policies as necessary.

Insight Director

It manages the connections to Insight Targets. It is responsible for sending the data collected by Insight plugins to Insight Target systems.

The handling of a connection with the help of components is shown in this figure:

PAS Architecture
Figure 1. PAS Architecture
  1. Incoming connections are accepted by the Transport Director.

    • It handles TLS with the client if necessary.

  2. It hands over the connection to the Flow Director.

    • The Flow Director chooses the Endpoint based on the URL.

    • The Flow Director applies the Endpoint specific Request Security Flow.

  3. If an Insight plugin needs to send data to an external Insight Target it sends the collected data to the Insight Director.

  4. The Insight Director sends the data further to the Insight Target with the appropriate protocol.

  5. The Flow Director hands the connection back to the Transport Director.

  6. The Transport Director then sends the data to the Backend.

    • It handles TLS with the backends if necessary.

    • It performs load balancing among Backend servers if necessary.

The same procedure is executed with the response coming from the Backend.

3.3.1. Understanding processing flow

The figure on Proxedo API Security architecture and the steps following that describe how client connection is handled. The following figure explains how calls are processed in more details:

PAS processing flow
Figure 2. PAS processing flow
  1. As shown in the figure above, the incoming connection from the client is handled by the Transport Director, applying TLS if needed.

  2. The Transport Director hands over the connection to the Flow Director, indicating which Listener the connection belongs to.

  3. The Flow Director then chooses the Endpoint based on the URL in the request. First endpoint has matching URL is chosen.

  4. The Flow Director then starts applying the request part of the Security Flow definition.

  5. For each Plugin the Flow Director:

    • Checks if the Plugin's matcher matches the request.

    • If so, it executes the Plugin, if not, it executes the next Plugin.

    • If the Plugin indicates success it executes the next Plugin.

    • If the Plugin indicates an error it applies the Plugin's error policy. If the policy dictates to abort the connection:

      • It fills error details and hands back the connection to the Transport Director, aborting the execution of the flow.

      • The Transport Director closes the connection, sending error details to the client if allowed by the policy.

  6. Once, the last Plugin has been executed the connection is handed back to the Transport Director.

  7. The Transport Director initiates the connection towards the Backend:

    • It handles load balancing if necessary.

    • It handles TLS if necessary.

    • It sends the request itself to the Backend server.

  8. The Backend server sends its response to the Transport Director.

  9. Once, the response has been received the Transport Director again hands over the connection to the Flow Director.

  10. The Flow Director then starts applying the response part of the Security Flow definition, executing the Plugins as above.

  11. Once, the last Plugin has been executed the connection is handed back to the Transport Director.

  12. Finally, the Transport Director sends the response to the client.

Usually, Plugins are organized in the following manner:

  • A Decompressor Plugin extracts the compressed body.

  • A Deserializer Plugin processes the decompressed request to understand the details in the body.

  • Filters are applied to filter unnecessary traffic.

  • Enforcers are applied for detailed validation of calls.

  • Insights are applied to collect data from the call.

  • Serializer Plugin serializes the body

  • Compressor Plugin compresses the serialized body

Though the order of the plugins can be changed based on the needs, note the followings:

  • When a Plugin needs access to the request body it requires Deserialized data. It is therefore strongly recommended that the first plugin is a Decompressor followed by a Deserializer.

  • At the end of the flow it is strongly recommended to place a Serializer plugin followed by a Compressor.

  • Generally Insights are applied after Filters and Enforcers so that they are not executed on possibly invalid calls.

  • Anything that operates on the HTTP headers or the body of the message will be aware of the call direction: The same Plugin in the request and response flow will act on the request or response data.

  • However, the Flow Director handles a request-response exchange together, so you can still use details from the request in Plugins of the response flow. The most notable example of this is using URI or method matchers in the response flow.

  • Plugins in the request flow, however, cannot access details of the response flow (since they are not available yet.)

It is also worth noting that Insight Plugins instantly hand over data to the Insight Director, and let the execution continue.

4. Installation of Proxedo API Security in Kubernetes environment

The forthcoming sections describe the installation of PAS in Kubernetes.

To manage Kubernetes (K8s) applications, Helm, the package manager for Kubernetes is used. Packages are called charts in the Helm context.

4.1. Prerequisites for installing PAS

The followings are needed prior to the installation of PAS:

  • the license file for PAS

  • a technical user for accessing Balasys' download site

  • the Helm chart

Prior to the installation of the Helm chart, the Helm chart itself must be configured. For minimum configuration of the Helm chart see section Minimum configuration settings for the Helm chart.

4.1.1. Cluster components necessary for PAS

To make use of some of the features, PAS shall be deployed in a cluster, with the following components installed:

  • metrics server for auto-scaling

  • Persistent volume for storing configuration in the management component

Persistent Volume Claim parameters can be set up to match a manually managed Persistent volume, so is Storage Class name.
  • access for the target namespace to deploy PAS in

4.1.2. Tools necessary for the installation

To create the basic configuration for the installation, the following tools are necessary:

  • openssl for storage certificate generation

  • the htpasswd tool, which is part of the apache2-utils package on debian distributions, the httpd-tools package on Red Hat based distributions

  • the helm command line tool to manage the package installation

  • the kubectl command line tool to communicate with the Kubernetes cluster

4.1.3. Minimum configuration settings for the Helm chart

The Helm chart contains the following:

  • configuration parameters to bootstrap PAS in K8s

  • definitions of

    • pods

    • services

    • autoscaling configuration for the core component

    • a Persistent Volume Claim for the management

Ingress configuration for any component is not included.
HTTP and HTTPS management access is recommended to be configured using an Ingress (kubernetes object).
In order to be able to install the Helm chart the minimum configuration settings have to be completed. The following sections contain the details only for the necessary minimum configuration, however for checking further possible configuration options, see section Base system configuration for PAS in Kubernetes.

The files detailed in the next sections need to be created and filled in prior to PAS installation.

4.1.3.1. Using values.yml file
  1. Use the values.yml (values file) with the default and necessary values. Run the following command to output the configuration options:

helm show values /path/to/chart/proxedo-api-security-4.8.0.tgz
  1. Create a local values.yml file with the preferred values to overwrite the default values if required. The values file with minimum configuration is as follows (with example values):

config:
  storage:
    consul:
      gossip_encryption_key: MhstT80sqle63WC7knOak+c7GfK7k5OY2n/4Qk/fSXs=
    blob_store:
      access_key: "8i8YJB3JhFmkT5KK6EV5EGw9dK10B4ZllWjEYlvUwKM="
      secret_key: "L/aLsKkoDFDFnMNdp8MFl1/CIkAQC1hrXV+HlbgKyOM="
  1. Generate these necessary secrets with the help of the following command. The values above are examples, they shall not be copied directly.

# config.consul.gossip_encryption_key
$ openssl rand -base64 32
gI97yg2Zcq4XL20ne8NBwH2e0PbzkmXjqMFdp8jQZac=

# consig.blob_store.access_key
$ openssl rand -base64 32
+WDpoDV7EcJrgkRgK65M3y8OcLdrZmYBASVTFE1I8pg=

# config.blob_store.secret_key
$ openssl rand -base64 32
ECuGiOwyJtjlB8Bl3yNgIgdk/nlb4HFmxE/4oiq5V+w=
4.1.3.2. Creating certificates for storage

For technical reasons, a TLS certificate is necessary for configuration storage purposes. Create the internal CAs and signed certificates either with a preferred method, or else the necessary files can be created with the following example commands as well.

  1. Generate a CA key pair.

    The -days parameter in the example commands define the validity period of the generated certificates in days. Change it, if it is required.
    The certificate files generated here and used with the Helm chart are sensitive pieces of information, therefore handle those with attention.
openssl req -nodes -new -x509 -days +3650 -keyout storage-ca-key.pem -out storage-ca.pem -subj "/CN=PAS Storage CA"
  1. Generate a private server key and a Certificate Signing Request (CSR).

openssl req -nodes -new -keyout consul-0-key.pem -out consul-0.csr -days +3650 -subj "/CN=storage.pas"
  1. Sign the CSR using the CA.

openssl x509 -req -days +3650 -in consul-0.csr -CA storage-ca.pem -CAkey storage-ca-key.pem -CAcreateserial  -out consul-0.pem

With the help of the above examples, further files need to be generated. These files will need to be provided for the Helm chart:

  • consul-0.csr

  • consul-0-key.pem

  • consul-0.pem

  • storage-ca-key.pem

  • storage-ca.pem

4.1.3.3. Creating management users' file

For logging into the management component, the users.htpass file is required. Run the following command to generate one, and provide the password.

htpasswd -c users.htpass username

4.2. Installing PAS in Kubernetes

The following sections and the example commands use the proxedo-api-security kubernetes namespace as an example, but it can be replaced with any other namespace name.

It is recommended to install PAS in a namespace separate from the backend application(s).

To create a new namespace, run the following command:

kubectl create namespace proxedo-api-security

4.2.1. Setting up docker registry connection

  1. Log in to the PAS docker registry to access the docker images of PAS.

  2. Create the proxedo-api-security-registry-credentials secret using the following command to enable kubernetes to access the docker images:

kubectl create --namespace proxedo-api-security \
    secret docker-registry proxedo-api-security-registry-credentials \
    --docker-server=docker.balasys.hu \
    --docker-username=<<your username>> \
    --docker-password="$(read -sp "Docker registry password: " DOCKER_PASSWORD; echo $DOCKER_PASSWORD)"

4.2.2. Providing the necessary files for Helm installation

Provide the created files for the Helm install command, an example of which can be seen below (substitute your values):

helm upgrade --install proxedo-api-security --namespace=proxedo-api-security \
    --values /path/to/config/files/values.yml \
    --set-file license=/path/to/config/files/license.txt \
    --set-file mgmt_users=/path/to/config/files/users.htpass \
    --set-file storage_ca_key=/path/to/config/files/storage-ca-key.pem \
    --set-file storage_ca_cert=/path/to/config/files/storage-ca.pem \
    --set-file storage_server_key=/path/to/config/files/consul-0-key.pem \
    --set-file storage_server_cert=/path/to/config/files/consul-0.pem \
    /path/to/chart/proxedo-api-security-4.8.0.tgz

4.3. Verifying the installation of PAS in Kubernetes

If everything is correct, the Helm command will present the following output:

NAME: proxedo-api-security
LAST DEPLOYED: Mon May  2 13:51:46 2022
NAMESPACE: proxedo-api-security
STATUS: deployed
REVISION: 1
TEST SUITE: None
  1. Run the kubectl get pods --namespace=proxedo-api-security --selector=app=proxedo-api-security command to investigate the running pods. The output shall be similar to the following example:

NAME                                                              READY   STATUS              RESTARTS   AGE
proxedo-api-security-blob-store-86ccc6d864-frc5k                  1/1     Running             0          40s
proxedo-api-security-config-api-76d587d6cd-wpw5d                  1/1     Running             0          40s
proxedo-api-security-consul-68c5c87f75-mvlct                      1/1     Running             0          40s
proxedo-api-security-content-filtering-director-55b859df9-sztwp   1/1     Running             0          40s
proxedo-api-security-flow-director-5cddf58677-qxczd               0/1     ContainerCreating   0          40s
proxedo-api-security-frontend-676bfd8956-qrtm4                    1/1     Running             0          40s
proxedo-api-security-insight-director-585cc5f86-j8rrz             0/1     ContainerCreating   0          40s
proxedo-api-security-transport-director-5bbdf58d7d-whzsq          0/1     ContainerCreating   0          40s

The core pod is missing the core configuration, therefore it will not enter the "Running" state until the first configuration is applied in the management.

  1. Run the following command to access the management component for verification.

kubectl port-forward --namespace=proxedo-api-security service/proxedo-api-security-frontend 8080:80
  1. Open the http://127.0.0.1:8080/ in the browser.

5. Base system configuration for PAS in Kubernetes

This chapter explains configuration details for setting up a working PAS. Configuration settings are detailed here, which are based on the installation of the Helm chart.

The Helm chart carries Kubernetes manifest files for each component, and requires a set of parameters to be configured by the user for the installation.

The values.yml file

The configuration of PAS components is condensed into a values.yml file. The default version of this file can be printed by using the following command:

helm show values /path/to/chart/proxedo-api-security-4.8.0.tgz

To configure the necessary parameters and to overwrite the not suitable default values, save the output to a file, and keep only those parts that has to be overwritten. The modified file can be provided as --values my-values.yml to the Helm installation command.

There are two main sections of this file:

  1. Infrastructure - This section defines the options necessary for kubernetes to deploy the components.

  2. Configuration - This section defines the options for PAS itself. The main configuration of the storage and management components is defined in this file.

The format of this file must adhere to the YAML 1.1 specification.

There are different sections in this configuration file, some of which, as for example, the 'config.mgmt.frontend' section, might not need specific configuration. However, the default values of these sections must be set by {}.

For information on how to provide the custom values.yml file, see section Providing the necessary files for Helm installation. See configuration examples in Appendix B.

5.1. Infrastructure configuration

In this infrastructure part of the configuration, many parameter fields are directly associated with the configuration attributes defined for the Kubernetes objects. For such parameters that have a Kubernetes equivalent, the Kubernetes parameter is referenced in the format that can directly be used with the kubectl explain command. This command provides the most specific documentation of each field. However, for using this command, access to a cluster is required.

In case it is not feasible to use the kubectl explain command, the referenced format can also be used to navigate to the correct object and field at the following site: Kubernetes API.

The following tables describe the infrastructure parameters and their Kubernetes equivalent if that exists.

Table 1. Docker-related parameters
Parameter field Default value Description

infrastructure.docker.registry

docker.balasys.hu

The registry to download docker images from.

infrastructure.docker.pull_policy

IfNotPresent

This parameter has a Kubernetes equivalent in all pods: pod.spec.containers.

infrastructure.docker.image_tag

The image tag to use instead of the one corresponding to the current PAS version.

Table 2. Storage-related infrastructure parameters
Parameter field Default value Description

infrastructure.storage.volume_claim

This parameter has a Kubernetes equivalent: PersistentVolumeClaim.

infrastructure.storage.storage_class_name

This parameter has a Kubernetes equivalent: PersistentVolumeClaim.spec.storageClassName.

infrastructure.storage.access_modes

ReadWriteOnce

This parameter has a Kubernetes equivalent: PersistentVolumeClaim.spec.accessModes.

infrastructure.storage.requests

This parameter has a Kubernetes equivalent: PersistentVolumeClaim.spec.resources.requests.

infrastructure.storage.requests.storage

100Mi

This parameter has a Kubernetes equivalent: PersistentVolumeClaim.spec.resources.requests.storage.

Table 3. Blob-store infrastructure parameters
Parameter field Default value Description

Resources

infrastructure.storage.blob_store.resources

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.

infrastructure.storage.blob_store.resources.autofill_limits

false

When true and limits are not defined, limits will be the same as the requests. When false and limits are not defined, there are no limits. Setting limits overrides this setting.

infrastructure.storage.blob_store.resources.limits

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.limits. If this is defined, either a CPU limit value, a memory limit value, or both must be provided.

infrastructure.storage.blob_store.resources.limits.cpu

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.limits.cpu.

infrastructure.storage.blob_store.resources.limits.memory

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.limits.memory.

infrastructure.storage.blob_store.resources.limits.ephemeral_storage

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.limits.ephemeral-storage.

infrastructure.storage.blob_store.resources.requests

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.requests.

infrastructure.storage.blob_store.resources.requests.cpu

350 m

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.requests.cpu.

infrastructure.storage.blob_store.resources.requests.memory

450 Mi

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.requests.memory.

infrastructure.storage.blob_store.resources.requests.ephemeral_storage

50Mi

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.requests.ephemeral-storage.

Table 4. Consul infrastructure parameters
Parameter field Default value Description

Resources

infrastructure.storage.consul.resources

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.

infrastructure.storage.consul.resources.autofill_limits

false

When true and limits are not defined, limits will be the same as the requests. When false and limits are not defined, there are no limits. Setting limits overrides this setting.

infrastructure.storage.consul.resources.limits

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.limits. If this is defined, either a CPU limit value, a memory limit value, or both must be provided.

infrastructure.storage.consul.resources.limits.cpu

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.limits.cpu.

infrastructure.storage.consul.resources.limits.memory

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.limits.memory.

infrastructure.storage.consul.resources.limits.ephemeral_storage

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.limits.ephemeral-storage.

infrastructure.storage.consul.resources.requests

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.requests.

infrastructure.storage.consul.resources.requests.cpu

350 m

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.requests.cpu.

infrastructure.storage.consul.resources.requests.memory

450 Mi

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.requests.memory.

infrastructure.storage.consul.resources.requests.ephemeral_storage

50 Mi

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.requests.ephemeral-storage.

Table 5. Transport Director infrastructure parameters
Parameter field Default value Description

Service

infrastructure.core.transport_director.service

This parameter has a Kubernetes equivalent: service.

infrastructure.core.transport_director.service.type

ClusterIP

This parameter has a Kubernetes equivalent: service.spec.type.

infrastructure.core.transport_director.service.ports

This parameter has a Kubernetes equivalent: service.spec.ports. A port with a specific target_port value needs to be set up for each listener port in the PAS configuration on the management interface.

infrastructure.core.transport_director.service.ports.name

HTTP

This parameter has a Kubernetes equivalent: service.spec.ports.name.

infrastructure.core.transport_director.service.ports.port

80

This parameter has a Kubernetes equivalent: service.spec.ports.port.

infrastructure.core.transport_director.service.ports.protocol

TCP

This parameter has a Kubernetes equivalent: service.spec.ports.protocol.

infrastructure.core.transport_director.service.ports.target_port

49 000

This parameter has a Kubernetes equivalent: service.spec.ports.targetPort.

infrastructure.core.transport_director.service.ports.node_port

This parameter has a Kubernetes equivalent: service.spec.ports.nodePort.

Resources

infrastructure.core.transport_director.resources

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.

infrastructure.core.transport_director.resources.autofill_limits

false

When true and limits are not defined, limits will be the same as the requests. When false and limits are not defined, there are no limits. Setting limits overrides this setting.

infrastructure.core.transport_director.resources.limits

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.limits. If this is defined, either a CPU limit value, a memory limit value, or both must be provided.

infrastructure.core.transport_director.resources.limits.cpu

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.limits.cpu.

infrastructure.core.transport_director.resources.limits.memory

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.limits.memory.

infrastructure.core.transport_director.resources.limits.ephemeral_storage

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.limits.ephemeral-storage.

infrastructure.core.transport_director.resources.requests

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.requests.

infrastructure.core.transport_director.resources.requests.cpu

250 m

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.requests.cpu.

infrastructure.core.transport_director.resources.requests.memory

450 Mi

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.requests.memory.

infrastructure.core.transport_director.resources.requests.ephemeral_storage

50 Mi

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.requests.ephemeral-storage.

Scaling

infrastructure.core.transport_director.scaling

For scaling parameters, see the separate table on scaling, Parameters for Scaling - Transport Director, Flow Director, Insight Director.

Table 6. Flow Director infrastructure parameters
Parameter field Default value Description

Resources

infrastructure.core.flow_director.resources

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.

infrastructure.core.flow_director.resources.autofill_limits

false

When true and limits are not defined, limits will be the same as the requests. When false and limits are not defined, there are no limits. Setting limits overrides this setting.

infrastructure.core.flow_director.resources.limits

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.limits. If this is defined, either a CPU limit value, a memory limit value, or both must be provided.

infrastructure.core.flow_director.resources.limits.cpu

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.limits.cpu.

infrastructure.core.flow_director.resources.limits.memory

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.limits.memory.

infrastructure.core.flow_director.resources.limits.ephemeral_storage

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.limits.ephemeral-storage.

infrastructure.core.flow_director.resources.requests

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.requests.

infrastructure.core.flow_director.resources.requests.cpu

250 m

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.requests.cpu.

infrastructure.core.flow_director.resources.requests.memory

600 Mi

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.requests.memory.

infrastructure.core.flow_director.resources.requests.ephemeral_storage

200 Mi

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.requests.ephemeral-storage.

Scaling

infrastructure.core.flow_director.scaling

For scaling parameters, see the separate table on scaling, Parameters for Scaling - Transport Director, Flow Director, Insight Director.

Table 7. Insight Director infrastructure parameters
Parameter field Default value Description

Resources

infrastructure.core.insight_director.resources

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.

infrastructure.core.insight_director.resources.autofill_limits

false

When true and limits are not defined, limits will be the same as the requests. When false and limits are not defined, there are no limits. Setting limits overrides this setting.

infrastructure.core.insight_director.resources.limits

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.limits. If this is defined, either a CPU limit value, a memory limit value, or both must be provided.

infrastructure.core.insight_director.resources.limits.cpu

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.limits.cpu.

infrastructure.core.insight_director.resources.limits.memory

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.limits.memory.

infrastructure.core.insight_director.resources.requests

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.requests.

infrastructure.core.insight_director.resources.requests.cpu

120 m

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.requests.cpu.

infrastructure.core.insight_director.resources.requests.memory

350 Mi

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.requests.memory.

Scaling

infrastructure.core.insight_director.scaling

For scaling parameters, see the separate table on scaling, Parameters for Scaling - Transport Director, Flow Director, Insight Director.

Table 8. Content Filtering Director infrastructure parameters
Parameter field Default value Description

Resources

infrastructure.core.content_filtering_director.resources

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.

infrastructure.core.content_filtering_director.resources.autofill_limits

false

When true and limits are not defined, limits will be the same as the requests. When false and limits are not defined, there are no limits. Setting limits overrides this setting.

infrastructure.core.content_filtering_director.resources.limits

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.limits. If this is defined, either a CPU limit value, a memory limit value, or both must be provided.

infrastructure.core.content_filtering_director.resources.limits.cpu

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.limits.cpu.

infrastructure.core.content_filtering_director.resources.limits.memory

1 Gi

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.limits.memory.

infrastructure.core.content_filtering_director.resources.limits.ephemeral_storage

20 Gi

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.limits.ephemeral-storage.

infrastructure.core.content_filtering_director.resources.requests

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.requests.

infrastructure.core.content_filtering_director.resources.requests.cpu

250 m

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.requests.cpu.

infrastructure.core.content_filtering_director.resources.requests.memory

600 Mi

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.requests.memory.

infrastructure.core.content_filtering_director.resources.requests.ephemeral_storage

1 Gi

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.requests.ephemeral-storage.

Table 9. Parameters for Scaling - Transport Director, Flow Director, Insight Director
Parameter field Default value Description

infrastructure.core.<transport/flow/insight>_director. scaling

This parameter has a Kubernetes equivalent: HorizontalPodAutoscaler.

infrastructure.core.<transport/flow/insight>_director. scaling.create_autoscaler

true

This parameter defines whether to create the HoizontalPodAutoscaler object with the forthcoming configuration options. If it is set to false, the HPA object to enable core autoscaling will need to be created manually.

infrastructure.core.<transport/flow/insight>_director. scaling.min_replicas

1

This parameter has a Kubernetes equivalent: horizontalpodautoscaler.spec.minReplicas.

infrastructure.core.<transport/flow/insight>_director. scaling.max_replicas

10

This parameter has a Kubernetes equivalent: horizontalpodautoscaler.spec.maxReplicas.

infrastructure.core.<transport/flow/insight>_director. scaling.metrics

This parameter has a Kubernetes equivalent: horizontalpodautoscaler.spec.metrics.

infrastructure.core.<transport/flow/insight>_director. scaling.metrics.cpu

This parameter defines the CPU metric configuration.

infrastructure.core.<transport/flow/insight>_director. scaling.metrics.cpu.average_utilization

80

This parameter has a Kubernetes equivalent: horizontalpodautoscaler.spec.metrics.resource. target.averageUtilization.

infrastructure.core.<transport/flow/insight>_director. scaling.metrics.memory

This parameter defines the memory metric configuration.

infrastructure.core.<transport/flow/insight>_director. scaling.metrics.memory.average_utilization

80

This parameter has a Kubernetes equivalent: horizontalpodautoscaler.spec.metrics.resource. target.averageUtilization.

infrastructure.core.<transport/flow/insight>_director. scaling.metrics.behavior

This parameter has a Kubernetes equivalent: horizontalpodautoscaler.spec.behavior. If it is defined, either scale_down or scale_up parameter must be defined.

infrastructure.core.<transport/flow/insight>_director. scaling.metrics.behavior.scale_down

This parameter has a Kubernetes equivalent: horizontalpodautoscaler.spec.behavior.scaleDown. If it is defined, all included parameters need to be defined.

infrastructure.core.<transport/flow/insight>_director. scaling.metrics.behavior.scale_down.stabilization_window_seconds

This parameter has a Kubernetes equivalent: horizontalpodautoscaler.spec.behavior.scaleDown. stabilizationWindowSeconds.

infrastructure.core.<transport/flow/insight>_director. scaling.metrics.behavior.scale_down.policies

This parameter has a Kubernetes equivalent: horizontalpodautoscaler.spec.behavior.scaleDown. policies.

infrastructure.core.<transport/flow/insight>_director. scaling.metrics.behavior.scale_down.policies.type

This parameter has a Kubernetes equivalent: horizontalpodautoscaler.spec.behavior.scaleDown. policies.type.

infrastructure.core.<transport/flow/insight>_director. scaling.metrics.behavior.scale_down.policies.value

This parameter has a Kubernetes equivalent: horizontalpodautoscaler.spec.behavior.scaleDown. policies.value.

infrastructure.core.<transport/flow/insight>_director. scaling.metrics.behavior.scale_down.policies.period_seconds

This parameter has a Kubernetes equivalent: horizontalpodautoscaler.spec.behavior.scaleDown. policies.periodSeconds.

infrastructure.core.<transport/flow/insight>_director. scaling.metrics.behavior.scale_down.select_policy

This parameter has a Kubernetes equivalent: horizontalpodautoscaler.spec.behavior.scaleDown. selectPolicy.

infrastructure.core.<transport/flow/insight>_director. scaling.metrics.behavior.scale_up

This parameter has a Kubernetes equivalent: horizontalpodautoscaler.spec.behavior.scaleUp. If it is defined, all included parameters need to be defined.

infrastructure.core.<transport/flow/insight>_director. scaling.metrics.behavior.scale_up.stabilization_window_seconds

This parameter has a Kubernetes equivalent: horizontalpodautoscaler.spec.behavior.scaleUp. stabilizationWindowSeconds.

infrastructure.core.<transport/flow/insight>_director. scaling.metrics.behavior.scale_up.policies

This parameter has a Kubernetes equivalent: horizontalpodautoscaler.spec.behavior.scaleUp. policies.

infrastructure.core.<transport/flow/insight>_director. scaling.metrics.behavior.scale_up.policies.type

This parameter has a Kubernetes equivalent: horizontalpodautoscaler.spec.behavior.scaleUp. policies.type.

infrastructure.core.<transport/flow/insight>_director. scaling.metrics.behavior.scale_up.policies.value

This parameter has a Kubernetes equivalent: horizontalpodautoscaler.spec.behavior.scaleUp. policies.value.

infrastructure.core.<transport/flow/insight>_director. scaling.metrics.behavior.scale_up.policies.period_seconds

This parameter has a Kubernetes equivalent: horizontalpodautoscaler.spec.behavior.scaleUp. policies.periodSeconds.

infrastructure.core.<transport/flow/insight>_director. scaling.metrics.behavior.scale_up.select_policy

This parameter has a Kubernetes equivalent: horizontalpodautoscaler.spec.behavior.scaleUp. selectPolicy.

Table 10. Config-api infrastructure parameters
Parameter field Default value Description

Resources

infrastructure.mgmt.config_api.resources

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.

infrastructure.mgmt.config_api.resources.autofill_limits

false

When true and limits are not defined, limits will be the same as the requests. When false and limits are not defined, there are no limits. Setting limits overrides this setting.

infrastructure.mgmt.config_api.resources.limits

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.limits. If this is defined, either a CPU limit value, a memory limit value, or both must be provided.

infrastructure.mgmt.config_api.resources.limits.cpu

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.limits.cpu.

infrastructure.mgmt.config_api.resources.limits.memory

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.limits.memory.

infrastructure.mgmt.config_api.resources.limits.ephemeral_storage

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.limits.ephemeral-storage.

infrastructure.mgmt.config_api.resources.requests

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.requests.

infrastructure.mgmt.config_api.resources.requests.cpu

350 m

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.requests.cpu.

infrastructure.mgmt.config_api.resources.requests.memory

450 Mi

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.requests.memory.

infrastructure.mgmt.config_api.resources.requests.ephemeral_storage

100 Mi

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.requests.ephemeral-storage.

Table 11. Frontend infrastructure parameters
Parameter field Default value Description

Resources

infrastructure.mgmt.frontend.resources

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.

infrastructure.core.mgmt.frontend.resources.autofill_limits

false

When true and limits are not defined, limits will be the same as the requests. When false and limits are not defined, there are no limits. Setting limits overrides this setting.

infrastructure.core.mgmt.frontend.resources.limits

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.limits. If this is defined, either a CPU limit value, a memory limit value, or both must be provided.

infrastructure.core.mgmt.frontend.resources.limits.cpu

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.limits.cpu.

infrastructure.core.mgmt.frontend.resources.limits.memory

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.limits.memory.

infrastructure.core.mgmt.frontend.resources.limits.ephemeral_storage

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.limits.ephemeral-storage.

infrastructure.core.mgmt.frontend.resources.requests

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.requests.

infrastructure.core.mgmt.frontend.resources.requests.cpu

350 m

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.requests.cpu.

infrastructure.core.mgmt.frontend.resources.requests.memory

450 Mi

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.requests.memory.

infrastructure.core.mgmt.frontend.resources.requests.ephemeral_storage

70 Mi

This parameter has a Kubernetes equivalent: pod.spec.containers.resources.requests.ephemeral-storage.

5.2. PAS configuration in Kubernetes

5.2.1. Configuration options for the storage component

The config.storage section controls keys to be used between the management and storage components.

The configuration file has three main sections, namely common, consul and blob-store.

The 'common' section has no required parameters, the defaults can be set by {}.

Table 12. Storage configuration common options
Key Default Description

config.storage.common.standalone_mode

true

This parameter must be set to 'true'. It denotes whether the storage is run in standalone or in cluster mode. If it is set to true, the cluster-related parameters are ignored. The required parameters still need to be provided.

Table 13. Storage configuration consul options
Key Default Description

config.storage.consul.bind_cluster_addr

127.0.0.1

The address to bind on as a cluster member. This will be used to communicate with other members. This is a required parameter.

config.storage.consul.gossip_encryption_key

The encryption key to use for the gossip protocol. It is a 32-byte shared key encoded into base64 format. Use openssl rand -base64 32 to generate it. For more information on the keys produced as part of the configuration, see Using values.yml file.

This is a required parameter.

config.storage.consul.log_level

INFO

The log level of consul. The possible values are: TRACE, DEBUG, INFO, WARN, ERR

The options with ’N/A’ default value are such sections that cannot have exact values, only the values described afterwards in the table.
Table 14. Storage configuration blob-store options
Key Default Description

config.storage.blob_store.access_key

The access key used for connecting to MinIO. A preferably random generated string must be provided. Min length: 3 This is a required parameter.

config.storage.blob_store.secret_key

The secret key used for connecting to MinIO. A preferably random generated string must be provided. Min length: 8. This is a required parameter.

The options with ’N/A’ default value are such sections that cannot have exact values, only the values described afterwards in the table.

For configuration examples, see section Minimal configuration.

5.2.2. Configuration options for the management component

The config.mgmt section controls:

  • Web service parameters

  • Authentication

The configuration file has two main sections, namely frontend and configapi.

The default values for both frontend and configapi sections are automatically effective. If the attributes have to be configured with specific values, other than the default values, the {} curly braces have to be deleted and the new values have to be added.

Table 15. Management configuration frontend options
Key Default Description

config.mgmt.frontend.server_name

_

The hostname the web server should serve the requests on. The default value means that the management interface will be served regardless of the provided hostname.

config.mgmt.frontend.cors_api

N/A

This section configures cross origin request sharing options for API access.

config.mgmt.frontend.allow_origin

The value of the Access-Control-Allow-Origin header. This is a required parameter in case of enabled CORS API.

The options with ’N/A’ default value are such sections that cannot have exact values, only the values described afterwards in the table.
Table 16. Management configuration log level setting options - configapi section
Key Default Description

config.mgmt.configapi.log_level

INFO

The log level can be set to DEBUG, INFO, WARNING, ERROR, CRITICAL.

Table 17. Management configuration user session options - configapi section
Key Default Description

config.mgmt.configapi.session

N/A

This section configures the options for session lifetimes.

config.mgmt.configapi.session.session_validity

600

The allowed lifetime of a login session token in seconds. It determines the time period between group membership and user existence checks. This DOES NOT control the length of a user session.

config.mgmt.configapi.session.renew_validity

36000

The validity of the renew token. It determines for how long session tokens can be renewed. Therefore the maximum length of a user session is the sum of the two parameters.

The options with ’N/A’ default value are such sections that cannot have exact values, only the values described afterwards in the table.

For further details on configapi section parameters related to LDAP authentication, see Management configuration LDAP authentication options - configapi section.

For configuration examples on the management component, see section Minimal configuration and section Management configuration with LDAP authentication.

5.2.2.1. Configuring authentication and local users in PAS

There are two methods available to configure authentication in PAS:

  • htpasswd authentication

  • Lightweight Directory Access Protocol (LDAP) authentication

It is required to provide the htpass file already for the Helm chart installation. See section Providing the necessary files for Helm installation.

Using htpasswd for authentication and for the configuration of local users

By using htpasswd authentication, the administrator can define individual user credentials directly in the htpasswd file. This file is created and provided for the Helm installation command. As local users are stored in an htpasswd file, the standard htpasswd tool needs to be used.

It is not possible to configure user groups, or to define different access levels for the users with htpasswd authentication, yet it is possible to define as many user credentials as necessary one by one. The user credentials are encrypted in the configuration file. If you want to add new users to the htpasswd file, run the htpasswd users.htpass username command and provide the password.

Example command and output
$ htpasswd users.htpass new-user
New password:
Re-type new password:
Adding password for user new-user

Consider the followings related to the command and the example output:

  • the htpasswd file is created and provided for the Helm installation command

  • new-user is the name of the new user

As a result, similar content is expected to appear in the referred file:

new-user:$apr1$GDRF00xV$DmqFFfl.O5GWFpDjQl6tJ.

LDAP authentication

LDAP authentication is a more elaborate way to configure authentication for PAS. With LDAP authentication it is possible to define user groups and attach different levels of access to these users, however, PAS does not support different levels of authorization based on these attributes yet at the moment.

If LDAP authentication is used, only the administrator user - and no other user - can authenticate with the htpasswd file.

The following configapi parameters, which are part of the configuration file’s configapi section, take part in LDAP authentication:

Table 18. Management configuration LDAP authentication options - configapi section
Key Default Description

config.mgmt.configapi.ldap

N/A

This section configures the options for LDAP authentication. LDAP authentication is disabled by default.

config.mgmt.configapi.ldap.ldap_url

The URL of the LDAP server. It must start with ldap[s]://. This is a required parameter in case of LDAP authentication.

config.mgmt.configapi.ldap.bind_user

The service user to use, for searching the LDAP server. If use_ntlm parameter is OFF, this must be the whole DN. If it is ON, it must be the Active Directory domain and the username concatenated by a backslash (eg. AD_domain\administrator). This is a required parameter in case of LDAP authentication.

config.mgmt.configapi.ldap.bind_password

The password of the service user. This is a required parameter in case of LDAP authentication.

config.mgmt.configapi.ldap.use_ntlm

OFF

Set this parameter to ON to use NTLM authentication. This is only available when the LDAP server is Microsoft Active Directory.

config.mgmt.configapi.ldap.tls_version

TLSv1_2

The TLS version for the LDAPS connection. It must be one of the following: SSLv23, TLS, TLS_CLIENT, TLS_SERVER, TLSv1, TLSv1_1, TLSv1_2.

config.mgmt.configapi.ldap.validate_cert

no

Set it to yes to validate certificates.

config.mgmt.configapi.ldap.ca_certs_file

/opt/balasys/etc/ldap_ca_certs.pem

This file contains the certificate files of the certificate authorities. Provide the path and filename for the certificate file. The certificate file must be in PEM format. See a single CA file configuration example in Single CA file example.

In case a self-signed certificate is used, the server certificate must also be included in this file.

In case a chain of certificates is used, the certificate of each level must be included in this file, beginning with the certificate of the signer of the server certificate, followed by the signer of that certificate up to the root certificate. For example on a Certificate chain with multiple CA, see Example on certificate chain with multiple CAs.

In case multiple chains of certificates are used, the chains must be concatenated in the same file. The first matching chain will be used for verification.

The above details are based on the Python SSL library documentation, available at https://docs.python.org/3.10/library/ssl.html#certificates.

Use the --set-file mgmt_ldap_ca_certs_file=<path/to/file> command during helm installation to specify this file. Also uncomment the ca_certs_file parameter without changing its value.

config.mgmt.configapi.ldap.user_base_dn

The base DN under which users reside. This is a required parameter in case of LDAP authentication.

config.mgmt.configapi.ldap.username_attribute

sAMAccountName

The attribute that contains the name of the user.

config.mgmt.configapi.ldap.user_object_class

user

The object class of the users.

config.mgmt.configapi.ldap.memberof_attribute

memberof

The attribute that contains membership information (groups) on user objects.

config.mgmt.configapi.ldap.group_base_dn

The base DN under which groups reside. This is a required parameter in case of LDAP authentication.

config.mgmt.configapi.ldap.groupname_attribute

name

The attribute that contains the name of the group.

config.mgmt.configapi.ldap.member_attribute

member

The attribute that contains membership information (users) on group objects.

config.mgmt.configapi.ldap.group_object_class

group

The object class for groups.

config.mgmt.configapi.ldap.allowed_groups

A list of group names (as contained by 'groupname_attribute') allowed to log in. This is a required parameter in case of LDAP authentication.

6. Configuration of Proxedo API Security on the Web User Interface

This chapter explains configuration details for setting up a working Proxedo API Security (PAS) with the help of the Web User Interface.

The Proxedo API Security Web User Interface (UI) is installed together with the installation of Proxedo API Security. The URL for Proxedo API Security Web UI and the necessary credentials are generated when the management component is first started. The password for the administrator can be found in the journal under the pas-config-api identifier.

For information on how to set up more users, see section Configuring authentication and local users in PAS.

By using OpenAPI schemas, as defined in OpenAPI specifications (also known as Swagger), Proxedo API Security verifies that the traffic passing through conforms to the API endpoint’s specification. An OpenAPI Swagger schema detailing the Configuration API is available at: <frontend_url>/api/v1/openapi. <frontend_url> here refers to the URL address of the user’s Proxedo API Security Web User Interface.

6.1. Minimum configuration

It is possible to run PAS with a minimum, basic configuration. For a minimum configuration the following items need to be configured in the Web UI:

This basic configuration can be further improved with the completion of more configuration units later. The minimum configuration can also be used to test the installation settings.

6.2. Login Page

The main component of the Login page is the login form where the user needs to provide the credentials in order to be authorized to use the Web UI of Proxedo API Security.

As part of the initial configuration of Proxedo API Security, the administrator defines the necessary credentials, which can now be used.