Helm Chart
    • 11 Jul 2024
    • 5 Minutes to read
    • Dark
    • PDF

    Helm Chart

    • Dark
    • PDF

    Article summary

    Installing the Helm Chart

    As a best practice, we recommend using the file values-custom.yaml for setting the relevant parameter values.

    To install the Helm Chart by using the values-custom.yaml file, add --values parameter to the installation command, e.g.:

    helm install my-plainid-paa plainid-paa --values values-custom.yaml

    To install the chart:

    helm install [release-name] plainid-paa 

    To install the chart with the Release Name my-plainid-paa:

    helm install my-plainid-paa plainid-paa

    Uninstalling the Chart

    To uninstall/delete the my-release deployment:

    helm delete my-plainid-paa

    This command removes all the Kubernetes components associated with the chart and deletes the release.


    By default, these additional, dependent charts are installed:

    For higher envrionments (staging, production, etc.) it is recomended, as a best practice, to use an external, managed Redis instance.

    PlainID PAA Installation Guide

    In order to set up the PAA, you need to set the variables below in the values-custom.yaml file
    The values for these settings can be obtained from the PlainID Policy Manager Tenant Settings UI.

    tenantIdTenant ID (can be found in Tenant Settings > Hybrid Agent Keys)
    agentSecretKeyAgent Secret key (can be found in Tenant Settings > Hybrid Agent Keys)
    paaIdPAA ID (can be found in Tenant Settings > Policy Authorization Agents tab)
    remoteApiwss://remote.XXXXX.plainid.io/wstunnel - Possible values: us1, eu1 according to you PlainID Tenant URL.

    Configuring External Access to the PDP

    Enable Ingress by setting the runtime.ingress.enabled to true.

    Make sure you configure the runtime.ingress.annotations, runtime.ingress.hosts, and runtime.ingress.tls according to your technological stack requirements.

    Docker Images

    Refer to the Working with the PlainID Docker Hub article to learn how to authenticate to the PlainID private Docker Hub repository.


    Examples values-custom.*.yaml files for various deployment(s) can be found in ./examples directory

    Load Third-Party Drivers by Modifying the pipOperator Start Command

    In order to use third-party drivers for accessing data sources (e.g. MySQL, MS SQL, Oracle, Google BigQuery, etc.), they must be pre-loaded into the cluster. To do so, add the following command section under the pipOperator section of your values-custom.yaml file:

      command: [
        - /bin/sh
        - -ec
        - |
          curl -o /app/lib/sample.driver.one.jar https://www.provider-one.com/sample.driver.one.jar && \
          curl -o /app/lib/sample.driver.two.jar https://www.provider-two.com/sample.driver.two.jar && \
          java ${JVM_OPTS} -cp $JAR_NAME -Djava.net.preferIPv4Stack=true -Dloader.path=/app/lib/ -Dloader.main=com.plainid.pipoperator.Starter org.springframework.boot.loader.PropertiesLauncher]

    The command starting with java ${JVM_OPTS} -cp $JAR_NAME ..... must be included, and must be the last command executed when starting the pipOperator, otherwise pip-operator service will not start.

    The above configuration will override the PIP-Operator start command, so the 3rd party drivers will be put into the /app/lib folder by using the curl command.

    The java command will load the relevant drivers from the /app/lib folder.

    Load Third-Party Drivers by Building a Custom Dockerfile

    • Edit the Dockerfile to read:
    FROM plainid/pip-operator:5.0.16
    ADD third-party-driver.jar /app/lib/
    • Build the custom docker image from the Dockerfile:
    docker build -t plainid/pip-operator:5.0.16-custom-drivers .
    • Verify that the driver was loaded to the custom image:
    docker run -it plainid/pip-operator:5.0.16-custom-drivers ls /app/lib
    • Sample verification response:
    pip-auth-extensions-1.1.0.jar  third-party-driver.jar

    Upgrading An Existing Release To A New Minor Version

    A minor chart version change (like v2.1.x -> v5.2309.x) indicates that the new version can be upgraded without any breaking changes.

    What's New In 5.2309.x?

    Redis Image Update

    As part of security enhancements, we have taken the following actions:

    • The HA helm chart of the Official Redis image remained as-is.
    • The Bitnami Redis image was replaced with the Official Redis image for all Redis instances.
    • All necessary configuration changes have been made and encapsulated, so no action is required from the customers’ side.

    Note: If you are using a single Redis deployment, you may experience RT inactivity for approximately 1-2 minutes - make sure to take this into account when scheduling the upgrade.

    If you are using a High Availability (HA) Redis deployment, you will not experience any downtime during the upgrade process.

    New Service - Secret Management

    The Secret Management Service is used by the PDP to obtain secret keys (e.g. private keys to sign the PDP JWT response) from different sources (Files, Environment Variables, HashiCorp Vault).

    By default, the service is not enabled/activated. Customers that want to use the PDP JWT Signing capabilities will need to enable and configure the Secret-Management service.

    After configuring, and enabling the secrets-mgmt service, make sure to apply the new configuration, and rollout the update to the PDP (theruntime pod/s):

    kubectl rollout restart deploy my-plainid-paa-runtime

    The my-plainid-paa-runtime consists of the deployment name (my-plainid-paa) and the runtime pod prefix (runtime).

    More information and configuration of the Secret Management Service can be found here.

    Upgrading Chart

    helm upgrade -i my-plainid-paa plainid-paa --values values-custom.yaml

    External Redis

    When using an external Redis (e.g. a SaaS managed service), the following parameter will have to be set in the Redis configuration:

    Parameter: notify-keyspace-events
    Value: KA

    The Policy Authorization Agent uses the notify-keyspace-events Redis feature to sync settings between the Policy Information Point Services (pip-operator).

    The Policy Administration Point sends updated settings to the PAA on every change that is relevant for that PAA.

    Once one of the pip-operators validates these updated settings, the notify-keyspace-events allows the other pip-operators to get notified whenever a pip-operator setting is modified, this allows the relevant pip-operators to be in sync.

    Shared Redis

    When using more than one PIP using the same Redis store, a unique identifier is required for every PIP instance to avoid data collisions.
    To set this unique identifier, set a REDIS_SETTINGS_KEY_NAME for each PAA.

    For Redis Settings Key name, ensure that they have the same VDB_PASSWORD variable in the same place in the Helm values.yaml file, In the standalone installation, ensure that there is one enviornment variable instead of three with the same value.

    The default value for REDIS_SETTINGS_KEY_NAME is VDBSettings.


    PAA - USVDBSettingsUS
    PAA - EUVDBSettingsEU
    PAA - CAVDBSettingsCA
    Redis Settings

    Ensure that only one Redis instance is toggled to true.

    Using Different Deployment Procedures

    For users utilizing their own deployment procedure for Kubernetes, note there are changes that need to be made.

    PIP Operator Deployment:

    1. Remove the REDIS_SETTINGS_KEY_NAME for each PAA.
    2. Add two new Environment Variables in the pip-operator deployment:
    • PAA_ID

    Agent Deployment:
    Ensure that you add the PAA Version Number to the Agent Deployment.

    Environment Variable Example: PAA_PACKAGE_VERSION: PAA VERSION NUMBER

    Was this article helpful?