Previous Releases

The utilitySidecar field under a given product can be used to run a sidecar container that will permanently alongside the product container. This sidecar can be used for utility command-line processes, such as running the collect-support-data tool or running a backup.

An example can be found in the docs/examples/pingdirectory-backup directory for running a PingDirectory backup every 6 hours via a CronJob.

A PingDirectory utility sidecar container needs to share the process namespace with the main PingDirectory container running in the same pod in order to get useful output out of tools like jps. More support to come on the utility sidecar in future Helm release.

In the interest of better security practice, this enhancement provides the ability to generate this password via the derivedPassword function in helm. With this, several items can be used by default and overridden by the deployer to generate a secure password. When it generates the password:

NOTES (see the generated password as well as the WARNING)

The values used to drive the creation of this password are:

values.yaml

This issue was created since the initContainer resources were hard coded in the template, not allowing the implementor to provide their own values, causing issues when trying to deploy the pingfederate-engine in openshift.

Moving a lot of the hard coded yaml out of the template files into the default values.yaml file. This will give the implementor full control of how the initContainer runs.

One breaking change with the values.yaml if anyone has overridden, is that the {image name} in the global.externalImage.{name}: {image name} value is moved into a map. The default pingtoolkit externalImage looks like:

When there are two waitFor’s together, allow for combining them to run them within same initContainer, with a definition like:

creating a couple of initContainers of:

The current envs for pingauthroize in the values.yaml file are:

Just a side note here, the baseline/pingauthorize PATH includes a connection to pingdirectory, which will cause this to fail (pingauthorize https will return a 503).

If someone wants to override these, they need to be sure to uset/override the SERVER_PROFILE_PARENT variable, so the parent profiles aren’t brought in.

The better default values.yaml should probably be:

For pingauthorizepap, it should have a default SERVER_PROFILE variables as empty, as no SERVER_PROFILE is needed by default.

Update the testFramework to pull in all attributes of the testSteps and finalStep into the init containers and final container. This allow for setting any resource, imagePullPolicy, …​

This came about as there was no way to set resource or imagePullPolicy details.

With this change, will be adding a couple of defaults into the value.yamls file for the finalStep:

Release 0.7.2 created the new variable PF_ADMIN_BASEURL. Due to the current user of the same variable with added _PUBLIC_, the actual variable name needs to be PF_ADMIN_PUBLIC_BASEURL.

Currently, the PUBLIC hostname/ports in the global env vars configmap are created if and only if the ingress in enabled.

Normally, this would be fine, except that some of the products (i.e PingFederate) use the PUBLIC environment variable to setup items like BASE URLs and redirects for the browser. This is required for use cases when there is no ingress, but the user creates a port forward, as well as testing with no ingresses.

So, if no ingress is created, then the PUBLIC_HOSTNAMES should be set to localhost and the PUBLIC_PORT_* should be set to the same port as the contianerPort.

If ingress is used, then the functionality will not be changed, and the public hostname will be constructed as well as the public ingressPort.

With the 10.3 release of PingFederate, there is a variable used to provide redirect links called the PF_ADMIN_BASEURL. This needs to be set by the helm chart, as it will either be a public host or localhost, depending on if the ingress is available. The container has no idea which it should be as it doesn’t have insight into the environment it’s running.

If ingress is enabled, an example for this variable is:

PF_ADMIN_BAESURL=https://pingfederate-admin.example.com

If ingress is not enable, an example for this variable:

PF_ADMIN_BASEURL=https://localhost:9999

To allow for a role to be created during testing, an rbac section is added to the testFramework allowing for the definition of that Role. If enabled, it will create a ServiceAccount, Role and RoleBinding using the same naming rules of resources and add that serviceAccount to the test pod.

testFramework default rbac set to:

When using the testFramework there are additional pod level config items that need to be provided (i.e. serviceAccountName) along with the existing securityContext.

To allow for any item to be configured, we should add a testFramework.pod that will pull in all items into the testFramework pod definition.

Example:

During resoluton of issue #170 providing support for ingress apiVersion v1, the necessary ingress yaml fields wearn’t updated to relfect that new version. This is a fix. The backend definition of the Ingress will now reflect the proper definition based on a v1 or v1beta1 apiVersion.

Example: If KubeVersion > 1.18

Example: If KubeVersion ⇐ 1.18

Additionally, adding the pathType for all versions as it is now required in ingress v1.

If kubernetes version is >1.18, setting the ingress apiVersion to v1. Otherwise, current default will be used v1beta1.

Adding startupProble as well as re-organizing how the probes are defined, allowing the deployer to use standard k8s probe definitions out of the box.

The new default looks like:

This includes the pre-release to PingAuthorize 8.3. It includes the necessary config for PingAuthorize and PingAuthorizePAP, even though there isn’t a release for 2105. The current edge release is required to use the default server-profiles provided in the values.yaml. Once the global tag is changed to 2106 (over next few days) PingAuthorize will be default for use over PingDataGoverance. This will be tracked in a ticket released 2105.

Example yaml to test PingAuthoize/PAP:

Allow for defining three top level maps to provide details for:

Example usages:

Adding the following to values.yaml:

This will only use the ConfigMap.data when creating checksums in workload rather than using the entire file. It will result in no checksum change when labels/annotations are the only thing changing. A good example is the helm chart version, which changes the label, but not data.

This is due to the fact that the global.image.tag is a non-floating tag. Once it is downloaded and present, it will not change. This small change will increase performance at startup as images are typically present when installing/updating releases.

Simply set global.image.pullPolicy=Always to pull every time if needed.

Cleaned up the generation of resources honoring the addReleaseNameToResource setting.

A testing framework is being created to allow for testing Ping Identity helm chart deployments using a testFramework set of values. This is currently in beta, with documentation to available soon. Expect that changes will be made to this work, until it’s fully released with documentation.

Resolves an issue with the DNS_QUERY_LOCATION when pingfederate clustering is used for >1 pingfederate-engines

Since the ClusterIP Services (aka Headless services) only provide access to the underlying container IP and port. The port, and by default targetPort, will be set to the containerPort value. The helm charts will start requiring the containerPort for any service where clusterService:true is set, otherwise it will fail with an error message.

Setting the cpu request to 50m, will provide at last some reservation of CPU, so that if there are multiple nodes, it will better even out the load.

Additionally, setting the replicaCount to 1 by default, as many cases in development, there isn’t a great need to have multiple replicas. If this is the case, simply set pingdirectory.container.replicaCount=2 or any number of replica’s.

This is one additional fix to the the same thing fixed in 0.5.4. volumeMounts: had the same issue as volumes:. This completes and resolves issue #126.

Due to the fact that volumes: is an array of items, volumes: usage with secret or configMap volumes exposed the issue that multiple volumes: entries were used, and only kept the last one. Fix included only using volumes: once. Note that the template will end up with a volumes: null if none are set (i.e. deployment with no Secret/ConfigMap volumes), but that is ok.

The status of this config map is used to form the checksum for the products. This will ensure that a simple addition/deletion of a product from the deployed mix won’t cause all products to be restarted.

The image tag is modified to 2103. This includes:

In order to provide HA with a PingAccess cluster between admin/engine nodes, it is required that the PingAccess Admin deploy as a StatefulSet with persistence. Otherwise if the PingAccess Admin goes down, the engines would lose connectivity to that node and be unable to get further config updates and subsequently have to bounce and lose their web-session information.

The new default yaml

Fixed issue that was created in Issue 95 (using annotations to provide vault details) to pull serviceAccountName from the proper location in annotations.

Support annotations at the workload level. For workloads, adding .spec.template.metadata.

Example telegraf annotation:

would lead to:

If the product was pingaccess-admin and release was acme, then the service name might be acme-ping-access-admin. This name by default will be added to the alternative hosts of the private certificate generation by default. Without this the pingaccess clustering will fail during setup.

Allow for a privateCert structure to contain optional arrays additionalHosts and additionalIPs:

In addition, if the ingress for the product is enabled, the host(s) created for that ingress will also be added to the alt-names.

The above example (with an ingress) will create a cert used by pingaccess-admin containing:

Update the default global image tag in base values.yaml and remove edge from example yamls.

Changing the default value pingfederate-engine.clustering.autoscaling.enabled=false, since the default CPU Request is set to 0.

Updated ability to add any hashicorp.vault annotation to the workload. As part of this effort, the existing name/values have been deprecated, however will continue to work for a period of time.

Updated details can be found in the Vault Config docs.

Additional cleanup of Notes.txt outputting detail of deployment.

Updating defaults to create a usage better reflecting actual memory usage by product. And minimizing amount of CPU needed as testing generally utilizes very little. Of course, it is definitely recommended that production deployments specify amount of cpu and memory required and limited to.

Current defaults are set to:

Example of creating 3 volume mounts in container from secret and configMap

In this case, a secret (called pingfederate-license) and configMap (called pingfederate-props) will bring in a couple of key values (license, hello) and (pf-props) into the container as specific files. The results will looks like:

Example of kubectl describe of pingfederate-admin container

Example values.yaml to add podAntiAffinity to pingdirectory

Adds following to pingdirectory-cluster:

{product-short-code with type}_{public or private}_{hostname or port}{_service if port}

ConfigMapRef names in workloads were not consistent with the ConfigMaps created by default when taking into account the addReleaseNameToResource setting of prepend, append or none. This fixes that issue ensuring that config maps are consistent.

The example below shows a container/service/ingress and how to specify the ports at each level.

PingFederate Admin waiting on pingdirectory ldaps service to be available:

An example securityContext that can be used might look like:

By default, the values.yaml in the chart will set the securityContext to empty: