Migrating from privileged images to unprivileged-by-default images ¶
In the 2103 release, our product images were updated to run with an unprivileged user by default. Before this release, images ran as root by default.
The following are some the potential issues you could encounter when migrating to these newer images.
Persistent volumes ¶
In Kubernetes, persistent volumes created with our older containers have files owned by the root user. When the default non-privileged user attempts to use these existing volumes, there might be file permission errors.
To avoid this, you can either:
- Create a fresh deployment that doesn't use the old volumes.
- Continue to run the containers as root.
Additionally, the containers using persistent volume claims need to set the securityContext
fsGroup to a value allowing the container can write to the PVCs. An example of setting this value in the statefulSet workload needs to include the following fsGroup setting.
This example uses the same default groupId set by the image. The Ping Identity Helm Charts already provide this setting by default for the containers.
spec: template: spec: securityContext: fsGroup:9999
Default ports ¶
In our older images, certain default ports (
JMX_PORT) were set to privileged values (
689, respectively). The newer images don't use these values because they run as a non-privileged user. The updated default ports are
If you need, you can maintain the old values by setting the corresponding environment variables and running the container as root.
For our PingDirectory images, port changes aren't allowed on restart. If you're using a volume from an older image you may encounter an error due to changing port values.
You must either:
- Create a fresh deployment for PingDirectory with the new images and import your data from the old deployment.
- Set the environment variables to match the original privileged values and continue to run the container as root.
Running as root with the unprivileged-by-default images ¶
To run as root as mentioned in the two previous examples, you must use your container orchestrator:
- For pure Docker, the
-uflag allows specifying the user the container should use.
- For Docker Compose, you can define a
- In Kubernetes, you can set up a security context for the container to specify the user. To run as root, a user and group ID of
0:0should be used.