Configure Polyspace Access on Kubernetes

R2026b

The values.yaml file is the primary configuration file for the Polyspace^® Access™ Helm chart. You can override the default values by providing one or more override files at install time using the -f flag:

helm upgrade --install RELEASE_NAME . -f my-values.yaml

You can also combine multiple override files. Later files take precedence:

helm upgrade --install RELEASE_NAME . -f values.yaml -f values-external-db.yaml -f values-ldap.yaml

Deployment Flavors Quick Reference

A deployment flavor is a combination of configuration choices that defines how you deploy Polyspace Access. Choose the flavor that matches your infrastructure.

The following table summarizes which values you must configure for each deployment flavor. Values marked as common are required regardless of the flavor you choose.

Flavor	Required Values	Notes
Common (all flavors)	`global.ingress.host`, `polyspaceAccess.webServer.license.secretName`, `usermanager.server.authPrivateKey.secret.name`, `usermanager.server.config.adminIds`, `usermanager.server.config.adminInitialPassword`	These values are required for every installation. You must also create the license and auth private key Secrets before installing.
Internal DB	`polyspaceAccess.db.passwordString` (or `passwordSecret`), `usermanager.server.config.db.username`, `usermanager.server.config.db.password`	The chart deploys PostgreSQL containers. No external DB setup required.
External DB	`polyspaceAccess.db.external.enabled`, `.host`, `.port`, `.passwordSecret`, `usermanager.db.external.enabled`, `.host`, `.port`, `usermanager.server.config.db.username`, `.password`, `.sslEnabled`	You must provision and initialize the databases before installing.
LDAP authentication	`usermanager.server.config.providers[]` (type, credentials, url, searchOptions)	Provide bind credentials and search configuration for your LDAP directory.
SAML + LDAP	`usermanager.server.config.saml.enabled`, `.metadataUrl`, `.relyingParty`, `.binding`, `.corsDomain`, `.user.*`, plus the LDAP `providers[]` array	LDAP is required alongside SAML for user synchronization.
Internal authentication (no IdP)	(no additional values)	Users are managed through the User Manager Dashboard. No LDAP or SAML configuration needed.
Issue Tracker	`issuetracker.enabled`, `issuetracker.server.provider`, `issuetracker.server.config.*` (or `configSecret`)	Optional. Configure only if you want to integrate with Jira, Polarion, or Redmine.
Private image registry	`global.image.registry`, `global.image.pullSecrets[]`	Required if images are hosted in a private container registry rather than loaded locally.
TLS / HTTPS	`global.ingress.tls.enabled`, `global.ingress.tls.secretName`	Provide a Kubernetes TLS Secret with your certificate and key.

Image Registry Configuration

By default, the chart looks for images locally. If you host images in a private container registry, configure the registry and pull secrets:

global:
  image:
    registry: your-registry.example.com
    pullSecrets:
    - name: my-registry-secret

The pullSecrets field references a Kubernetes Secret of type kubernetes.io/dockerconfigjson that contains credentials for pulling images from your private registry.

Ingress Configuration

The Ingress resource controls how external traffic reaches the Polyspace Access web application.

global:
  ingress:
    annotations:
      kubernetes.io/ingress.class: nginx
      nginx.ingress.kubernetes.io/proxy-body-size: "0"
    host: polyspace.example.com
    tls:
      enabled: true
      secretName: tls-polyspace

Set global.ingress.host to the hostname of your cluster. The host must be a DNS name — IP addresses are not accepted. Set nginx.ingress.kubernetes.io/proxy-body-size: "0" to remove the upload size limit for result uploads.

To enable TLS, set tls.enabled to true and specify the name of a Kubernetes TLS Secret that contains your certificate and key.

Persistent Volume Configuration

The chart requires persistent storage for databases, uploads, and working directories. You can configure volumes in two ways:

Helm-managed volumes — The chart creates PersistentVolumeClaims automatically when global.volume.create is true (or global.volume.storageClassName is set):
```
global:
  volume:
    create: true
    storageClassName: standard
```
Caution
Depending on the reclaim policy of the StorageClass, deleting the Helm release might delete the PersistentVolumes and all stored data. For production deployments, use pre-provisioned volumes instead.
Pre-provisioned volumes (recommended) — Create PersistentVolumeClaims manually before installing the chart. This approach gives you full control over storage class, reclaim policy, and backup strategy:
```
global:
  volume:
    create: false
```

Required PersistentVolumeClaims

The following table lists all PVCs that must exist before you run helm install when using pre-provisioned volumes. The PVC names must match the values in the volumes section of your values.yaml.

PVC Name (default)	values.yaml Key	Purpose	Access Mode	Min. Size
`polyspace-access-db`	`volumes.polyspaceAccess.db.claimName`	PostgreSQL data folder for the Polyspace Access database. Not required if using an external database.	ReadWriteOnce	10Gi
`usermanager-db`	`volumes.usermanager.db.claimName`	PostgreSQL data folder for the User Manager database. Not required if using an external database.	ReadWriteOnce	1Gi
`polyspace-access-storage`	`volumes.polyspaceAccess.etl.claimName.storage`	Persistent storage for processed analysis results managed by the ETL service.	ReadWriteOnce	50Gi
`polyspace-access-working`	`volumes.polyspaceAccess.etl.claimName.working`	Temporary working directory used by the ETL service during result processing.	ReadWriteOnce	10Gi
`polyspace-access-invalid`	`volumes.polyspaceAccess.etl.claimName.invalid`	Stores results that failed validation or import. Used for troubleshooting.	ReadWriteOnce	50Gi
`polyspace-access-upload`	`volumes.polyspaceAccess.etl.claimName.upload`	Staging area for results uploaded by users before ETL processing. This volume is shared by the web server and ETL services.	ReadWriteMany	10Gi
`polyspace-access-temp-upload`	`volumes.polyspaceAccess.webServer.claimName.tempUpload`	Temporary storage for in-progress uploads received by the web server.	ReadWriteOnce	10Gi
`polyspace-access-download`	`volumes.polyspaceAccess.webServer.claimName.download`	Stores files prepared for user download from the web interface.	ReadWriteOnce	10Gi

Note

The minimum sizes listed are starting recommendations. Size the polyspace-access-storage and polyspace-access-upload volumes based on the number and size of analysis results you expect to store. A single Polyspace analysis result can range from a few megabytes to several gigabytes depending on the size of the codebase.

Creating PVCs Manually

Create each PVC in the same namespace where you install the Helm chart. The following example creates the polyspace-access-storage PVC:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: polyspace-access-storage
  namespace: NAMESPACE
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: your-storage-class
  resources:
    requests:
      storage: 50Gi

Apply with:

kubectl apply -f polyspace-access-storage-pvc.yaml

Repeat for each required PVC. You can also define all PVCs in a single YAML file separated by ---.

The polyspace-access-upload PVC requires ReadWriteMany access because it is shared by the web server and ETL services. The provisioning of ReadWriteMany volumes is platform-specific. Consult your cloud provider documentation for instructions.

After creating all PVCs, verify they are bound:

kubectl get pvc -n NAMESPACE

All PVCs must show a status of Bound before you run helm install. If a PVC remains in Pending state, check that the specified StorageClass exists and that the underlying storage provisioner is available.

Note

If you use the internal PostgreSQL database containers, configure subPath for the database PVCs (polyspace-access-db and usermanager-db). PostgreSQL requires an empty directory to initialize. A newly created PVC might contain a lost+found directory that prevents PostgreSQL from starting. Setting a subPath creates an empty subdirectory within the PVC.

Using Custom PVC Names

If your PVCs use names that differ from the defaults, update the volumes section in your values.yaml:

volumes:
  usermanager:
    db:
      claimName: my-um-db-pvc
  polyspaceAccess:
    db:
      claimName: my-psaccess-db-pvc
    etl:
      claimName:
        storage: my-etl-storage
        invalid: my-etl-invalid
        working: my-etl-working
        upload: my-etl-upload
    webServer:
      claimName:
        tempUpload: my-temp-upload
        download: my-download

Database Configuration

The Helm chart can deploy PostgreSQL database containers for both the User Manager and Polyspace Access services (internal databases). If your organization manages its own PostgreSQL instances (for example, Amazon RDS, Azure Database for PostgreSQL, or a self-hosted PostgreSQL server), you can connect to external databases instead.

Internal Database (Default)

When you use internal databases, the Helm chart deploys dedicated PostgreSQL containers and manages initialization automatically. No additional database setup is required. The chart creates all necessary roles, databases, and schemas on first deployment.

To use internal databases, either omit the external configuration or set enabled to false:

usermanager:
  db:
    external:
      enabled: false

polyspaceAccess:
  db:
    external:
      enabled: false

The internal database containers use the credentials specified in usermanager.server.config.db.username, usermanager.server.config.db.password, and polyspaceAccess.db.passwordString (or polyspaceAccess.db.passwordSecret).

External Database

When you enable external databases, the chart does not deploy the internal PostgreSQL containers. You must provision, initialize, and maintain the external database instances.

Prerequisites. Before installing with external databases, complete the following setup on your PostgreSQL server. The Polyspace Access services require two separate databases:

Polyspace Access Database — Stores analysis results, projects, and findings.
User Manager Database — Stores user identities, encrypted passwords of internal users (not LDAP users), and group information.

Polyspace Access Database Setup

Create the role and database required by the Polyspace Access ETL and web server services. The username prs_data is not configurable.

-- Connect as a PostgreSQL superuser
CREATE ROLE prs_data WITH LOGIN PASSWORD 'your-password';
ALTER ROLE prs_data CREATEDB;
CREATE DATABASE prs_data OWNER prs_data;

-- The role 'postgres' must also exist (used for migrations)
-- This role exists by default on most PostgreSQL installations

User Manager Database Setup

Create the role and database required by the User Manager service. You can choose a custom username, which must match the value specified in usermanager.server.config.db.username.

-- Connect as a PostgreSQL superuser
CREATE ROLE um WITH LOGIN PASSWORD 'your-password';
CREATE DATABASE umdb OWNER um;

-- Connect to the 'umdb' database and create the required tables
\c umdb

CREATE TABLE identity(
  id text NOT NULL CHECK (id <> ''),
  source text NOT NULL CHECK (source <> ''),
  type text NOT NULL CHECK (type <> ''),
  display_name text,
  email text,
  image_uri text,
  PRIMARY KEY (id, source)
);

CREATE TABLE password(
  id text NOT NULL,
  source text NOT NULL,
  password text NOT NULL,
  PRIMARY KEY (id, source),
  FOREIGN KEY (id, source) REFERENCES identity(id, source) ON DELETE CASCADE
);

Ensure the tables are owned by the role you created (for example, um).

values.yaml Configuration. After you provision the databases, configure the following values to connect to them.

Polyspace Access Database

polyspaceAccess:
  db:
    external:
      enabled: true
      host: your-db-host.example.com
      port: 5432
      passwordSecret:
        name: polyspace-access-db-secret
        key: password

Property	Description	Required
`external.enabled`	Set to `true` to disable the internal database container and connect to an external instance.	Yes
`external.host`	Hostname or IP address of your PostgreSQL server.	Yes
`external.port`	Port on which PostgreSQL listens.	Yes
`external.passwordSecret.name`	Name of the Kubernetes Secret containing the password for the `prs_data` role.	Yes
`external.passwordSecret.key`	Key in the Secret that holds the password value.	Yes

Create the Kubernetes Secret before installing:

kubectl create secret generic polyspace-access-db-secret \
  --from-literal=password='your-password' \
  -n NAMESPACE

User Manager Database

usermanager:
  db:
    external:
      enabled: true
      host: your-db-host.example.com
      port: 5432
  server:
    config:
      db:
        username: um
        password: your-password
        sslEnabled: false

Property	Description	Required
`db.external.enabled`	Set to `true` to disable the internal database container and connect to an external instance.	Yes
`db.external.host`	Hostname or IP address of your PostgreSQL server.	Yes
`db.external.port`	Port on which PostgreSQL listens.	Yes
`server.config.db.username`	PostgreSQL role that owns the `umdb` database. Must match the role you created during setup.	Yes
`server.config.db.password`	Password for the database role.	Yes
`server.config.db.sslEnabled`	Set to `true` to require an SSL connection to the database. Required for managed services such as Amazon RDS.	No (default: `false`)

Note

The User Manager database password is specified in plaintext in values.yaml. Store your values file securely and restrict access. A future release will add Secret reference support for this field.

SSL Configuration for External Databases. When connecting to a managed database service (Amazon RDS, Azure Database for PostgreSQL, Google Cloud SQL), enable SSL to encrypt the connection between the Polyspace Access services and the database.

For the User Manager database, set sslEnabled:

usermanager:
  server:
    config:
      db:
        sslEnabled: true

If your database server uses a certificate signed by a private CA (common with Amazon RDS), you must provide the CA certificate. Create a Kubernetes Secret containing the CA file and configure TLS on the User Manager server:

kubectl create secret generic tls-um \
  --from-file=ca-certificates.crt=/path/to/rds-ca.pem \
  -n NAMESPACE

usermanager:
  server:
    tls:
      enabled: true
      ca:
        secretName: tls-um
        key: ca-certificates.crt

Complete External Database Example. The following example shows a complete values-external-db.yaml override file that configures both databases to use external instances:

usermanager:
  db:
    external:
      enabled: true
      host: psaccess-db.abc123.us-east-1.rds.amazonaws.com
      port: 5432
  server:
    config:
      db:
        username: um
        password: changeme
        sslEnabled: true
    tls:
      enabled: true
      ca:
        secretName: tls-um
        key: ca-certificates.crt

polyspaceAccess:
  db:
    external:
      enabled: true
      host: psaccess-db.abc123.us-east-1.rds.amazonaws.com
      port: 5433
      passwordSecret:
        name: polyspace-access-db-secret
        key: password

Install using the override file:

helm upgrade --install RELEASE_NAME . \
  -f values-external-db.yaml \
  -n NAMESPACE

Identity Provider Configuration

Polyspace Access uses the User Manager service to authenticate users. You can configure the User Manager to authenticate against an LDAP directory, a SAML identity provider, or a combination of both. If no external identity provider is configured, the User Manager uses its own internal user store.

LDAP Configuration

To authenticate users against an LDAP directory, configure the usermanager.server.config.providers array in your values.yaml:

usermanager:
  server:
    config:
      providers:
      - type: ldap
        syncIntervalNanoSeconds: 1800000000000
        properties:
          credentials:
            bindDN: cn=admin,dc=example,dc=com
            bindPassword: password
          url: ldap://your-ldap-server:389
          searchOptions:
            user:
              filter: (&(objectClass=inetOrgPerson))
              searchBaseDN: dc=example,dc=com
              schema:
                id: uid
                displayName: displayName
                email: mail
                image: jpegPhoto
                member: memberOf
            group:
              enabled: false
              filter: (objectClass=groupOfNames)
              searchBaseDN: dc=example,dc=com
              schema:
                id: cn
                displayName: cn
                email: ""
                image: ""
                member: member
          generalOptions:
            paginate: true
            pageSize: 1000

Property	Description	Required
`type`	Must be `ldap`.	Yes
`syncIntervalNanoSeconds`	How often (in nanoseconds) to synchronize users from the LDAP directory. Default is 1800000000000 (30 minutes).	Yes
`credentials.bindDN`	Distinguished Name of the service account used to bind to the LDAP server and perform searches.	Yes
`credentials.bindPassword`	Password for the bind DN service account.	Yes
`url`	LDAP server URL including protocol and port. Use `ldap://` for unencrypted or `ldaps://` for TLS.	Yes
`searchOptions.user.filter`	LDAP search filter to retrieve a subset of users from the LDAP database. The User Manager loads this subset on startup instead of loading all users in your organization, which improves performance. Use the format `attribute=value`, for example `CN=test*` matches all users with a common name starting with "test". Use parentheses to combine expressions: `(\|(CN=jdoe)(department=foo))`. For Active Directory, use `(&(objectClass=user)(objectCategory=person))`. The default is `objectClass=organizationalPerson`.	Yes
`searchOptions.user.searchBaseDN`	Base DN from which to search for users.	Yes
`searchOptions.user.schema.id`	LDAP attribute that uniquely identifies a user. For Active Directory, use `sAMAccountName`.	Yes
`searchOptions.user.schema.displayName`	LDAP attribute for the user's display name.	Yes
`searchOptions.user.schema.email`	LDAP attribute for the user's email address.	Yes
`searchOptions.user.schema.image`	LDAP attribute for the user's profile image. Set to an empty string if not used.	No
`searchOptions.user.schema.member`	LDAP attribute on user entries that lists group membership (for example, `memberOf`).	No
`searchOptions.group.enabled`	Set to `true` to synchronize LDAP groups into the User Manager.	No (default: `false`)
`searchOptions.group.filter`	LDAP search filter to retrieve a subset of groups. For Active Directory, use `(objectClass=group)`.	If groups enabled
`searchOptions.group.searchBaseDN`	Base DN from which to search for groups.	If groups enabled
`searchOptions.group.schema.id`	LDAP attribute that uniquely identifies a group.	If groups enabled
`searchOptions.group.schema.member`	LDAP attribute on group entries that lists members.	If groups enabled
`generalOptions.paginate`	Enable paged LDAP result retrieval.	No (default: `true`)
`generalOptions.pageSize`	Number of entries per page when pagination is enabled.	No (default: `1000`)

LDAPS (LDAP over TLS). To encrypt the connection to your LDAP server, use an ldaps:// URL and provide the CA certificate that signed the LDAP server's TLS certificate:

kubectl create secret generic tls-um \
  --from-file=ca-certificates.crt=/path/to/ldap-ca.pem \
  -n NAMESPACE

If the certificate chain includes intermediate certificates, combine the root and intermediate certificates into a single PEM file before creating the Secret.

usermanager:
  server:
    config:
      providers:
      - type: ldap
        properties:
          url: ldaps://your-ldap-server:636
          # ... remaining LDAP properties
    tls:
      enabled: true
      ca:
        secretName: tls-um
        key: ca-certificates.crt

Active Directory Example. The following example shows a typical configuration for Microsoft Active Directory:

usermanager:
  server:
    config:
      providers:
      - type: ldap
        syncIntervalNanoSeconds: 1800000000000
        properties:
          credentials:
            bindDN: cn=svc-polyspace,ou=ServiceAccounts,dc=corp,dc=example,dc=com
            bindPassword: ServiceAccountPassword
          url: ldaps://ad.corp.example.com:636
          searchOptions:
            user:
              filter: (&(objectClass=user)(objectCategory=person))
              searchBaseDN: ou=Users,dc=corp,dc=example,dc=com
              schema:
                id: sAMAccountName
                displayName: displayName
                email: mail
                image: ""
                member: memberOf
            group:
              enabled: true
              filter: (objectClass=group)
              searchBaseDN: ou=Groups,dc=corp,dc=example,dc=com
              schema:
                id: cn
                displayName: cn
                email: ""
                image: ""
                member: member
          generalOptions:
            paginate: true
            pageSize: 1000
    tls:
      enabled: true
      ca:
        secretName: tls-um
        key: ca-certificates.crt

SAML Configuration

SAML enables Single Sign-On (SSO) with an external identity provider. When SAML is enabled, users authenticate through your identity provider's login page rather than entering credentials directly in Polyspace Access.

SAML requires an LDAP provider to also be configured. The LDAP provider is used for user synchronization — it populates the user directory so that permissions and group membership can be managed and so that results can be assigned to users for review. SAML handles only authentication (login), not user discovery.

Configuring SAML has these prerequisites:

Your identity provider follows the SAML protocol.
You have access to your identity provider. Contact your identity management administrator to obtain access.
Your identity provider hosts an endpoint for its SAML metadata XML.

Users that you manually add to the User Manager dashboard cannot authenticate through the SSO service. You must add these users to your identity provider for SSO to authenticate their login.

To enable SAML, configure both the saml section and an LDAP providers entry:

usermanager:
  server:
    config:
      saml:
        enabled: true
        metadataUrl: https://your-idp.example.com/metadata.xml
        relyingParty: https://polyspace.example.com
        binding: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
        corsDomain: https://your-idp.example.com
        user:
          id: uname
          displayName: uname
          email: email
          image: image
      providers:
      - type: ldap
        syncIntervalNanoSeconds: 1800000000000
        properties:
          # ... LDAP configuration for user sync

Property	Description	Required
`saml.enabled`	Set to `true` to enable SAML authentication.	Yes
`saml.metadataUrl`	URL of the identity provider SAML metadata XML.	Yes
`saml.relyingParty`	The Entity ID registered with your identity provider. Typically set to the base URL of your Polyspace Access instance.	Yes
`saml.binding`	SAML binding method. Use `urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST` or `urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect`.	Yes
`saml.corsDomain`	Origin URL of your identity provider for cross-origin requests.	Yes
`saml.user.id`	SAML assertion attribute that maps to the user's unique identifier. Must match the user ID synchronized from LDAP.	Yes
`saml.user.displayName`	SAML assertion attribute for display name.	Yes
`saml.user.email`	SAML assertion attribute for email.	Yes
`saml.user.image`	SAML assertion attribute for profile image. Set to empty string if not provided by IdP.	No

Identity Provider Setup. When registering Polyspace Access as a Service Provider in your identity provider, use the following values:

Field	Value
Entity ID / Audience URI	Same value as `saml.relyingParty`
ACS URL	`https://your-host/authnz/saml/saml/acs`
SLO URL	`https://your-host/authnz/saml/saml/slo`
Name ID Format	`urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified`

Ensure that the SAML assertion includes attributes that match the values configured in saml.user.*. The saml.user.id attribute value must match the user ID that the LDAP provider synchronizes.

Internal Authentication

If you do not configure an LDAP provider or enable SAML, the User Manager uses its internal user store. Users are created manually through the User Manager Dashboard.

With internal authentication, configure administrator accounts and their initial password:

usermanager:
  server:
    config:
      adminIds:
      - admin
      adminInitialPassword: your-secure-password

The adminIds list specifies which user IDs are granted administrator privileges. The adminInitialPassword sets the password for these accounts on first installation.

Resource Requests and Limits

You can configure CPU and memory requests and limits for each service component. These settings enable Kubernetes^® to schedule pods appropriately based on available cluster resources.

polyspaceAccess:
  webServer:
    resources:
      requests:
        memory: "256Mi"
        cpu: "250m"
      limits:
        memory: "32Gi"
        cpu: "4"
  etl:
    resources:
      requests:
        memory: "128Mi"
        cpu: "125m"
      limits:
        memory: "256Mi"
        cpu: "250m"
  db:
    resources:
      requests:
        memory: "128Mi"
        cpu: "125m"
      limits:
        memory: "256Mi"
        cpu: "250m"

The webServer component typically requires the most resources. Adjust the limits based on the number of concurrent users and the size of results being processed.

Cloud-Specific Configuration

When installing on a managed Kubernetes service, adjust the following settings:

Set global.image.registry to your cloud container registry (for example, myregistry.azurecr.io).
Set global.volume.storageClassName to a StorageClass provided by your cloud provider (for example, managed for AKS).
Configure global.image.pullSecrets to authenticate with your cloud registry.
Configure Ingress annotations for your cloud load balancer (for example, kubernetes.io/ingress.class: azure/application-gateway for AKS Application Gateway).

Configure Polyspace Access on Kubernetes

Deployment Flavors Quick Reference

Image Registry Configuration

Ingress Configuration

Persistent Volume Configuration

Required PersistentVolumeClaims

Creating PVCs Manually

Using Custom PVC Names

Database Configuration

Internal Database (Default)

External Database

Identity Provider Configuration

LDAP Configuration

SAML Configuration

Internal Authentication

Resource Requests and Limits

Cloud-Specific Configuration

See Also