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.
Dependencies
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.
Value | Description |
---|---|
tenantId | Tenant ID (can be found in Tenant Settings > Hybrid Agent Keys) |
agentSecretKey | Agent Secret key (can be found in Tenant Settings > Hybrid Agent Keys) |
paaId | PAA ID (can be found in Tenant Settings > Policy Authorization Agents tab) |
remoteApi | wss://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
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:
pipOperator:
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.launch.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-operator
s 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.
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:
- Remove the
REDIS_SETTINGS_KEY_NAME
for each PAA. - Add two new Environment Variables in the pip-operator deployment:
TENANT_ID
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