Enable authorization in OCP IBM Cloud
Summary and Key concepts
Summary:
This article guides users on how to enable and configure Portworx authorization within a Kubernetes cluster using the Portworx Operator. It explains how to enable security in the StorageCluster
specification, either using environment variables or an auto-generated secret system. The guide also covers migrating from using environment variables to defining security settings in the StorageCluster
spec and how to upgrade from a non-authenticated to an authenticated Portworx environment. Additionally, it provides detailed instructions for different Kubernetes distributions on creating necessary Kubernetes secrets for security keys and enabling authorization.
Kubernetes Concepts:
Portworx Concepts:
Before proceeding with this document, please review the Security model used by Portworx.
- For a step by step setup of guide of how to enable Portworx authorization, please see Securing your Portworx system.
- The following will be a cluster level interruption event while all the nodes in the system come back online with security enabled.
Enabling authorization with the Portworx Operator
You can easily set up security in your StorageCluster
spec with a single flag:
apiVersion: core.libopenstorage.org/v1
kind: StorageCluster
metadata:
name: portworx
namespace: <px-namespace>
spec:
image: portworx/oci-monitor:2.6.0.1
security:
enabled: true
For a detailed guide of installing PX-Security with the Operator, please see Securing your storage with the Operator.
Migrating from Portworx Manifest to StorageCluster Security spec
In order for Portworx to start with security enabled, it requires a few different environment variables. If you wish to start using the StorageCluster
security spec, here is how you can migrate your environment variables to spec fields.
- First, familiarize yourself with the Security spec in the StorageCluster article.
-
Create a Kubernetes secret for your shared-secret:
oc create secret generic -n <px-namespace> px-shared-secret \
--from-literal=shared-secret=$EXISTING_SHARED_SECRET_VALUE
-
Add the following
spec.security
section in yourStorageCluster
:apiVersion: core.libopenstorage.org/v1
kind: StorageCluster
metadata:
name: px-cluster
namespace: <px-namespace>
spec:
security:
enabled: true
auth:
selfSigned:
issuer: '<value from your PORTWORX_AUTH_JWT_ISSUER environment variable>'
sharedSecret: 'px-shared-secret' -
Remove the
PORTWORX_AUTH_JWT_ISSUER
andPORTWORX_AUTH_JWT_SHAREDSECRET
env variables from your StorageCluster env spec. -
You can now apply the StorageCluster spec and wait until Portworx is ready.
Migrating to auto-generated PX-Security system secrets
Another feature of Portworx Operator Security is that you can allow the Operator to auto-generate all required system secrets. This can greatly decrease the complexity of your PX-Security deployment. The auto-generated secrets are random 64 character strings and are base64 encoded. This is a zero downtime migration and can be achieved with the following StorageCluster
changes:
-
Add the following to your
StorageCluster
security spec:apiVersion: core.libopenstorage.org/v1
kind: StorageCluster
metadata:
name: px-cluster
namespace: <px-namespace>
spec:
security:
enabled: true
auth:
selfSigned:
issuer: '<value from your PORTWORX_AUTH_JWT_ISSUER environment variable>'
sharedSecret: 'px-shared-secret' -
Remove the
PORTWORX_AUTH_SYSTEM_KEY
andPORTWORX_AUTH_SYSTEM_APPS_KEY
environment variables in yourStorageCluster
spec.env. -
Remove the
PX_SHARED_SECRET
environment variable in yourStorageCluster
spec.stork.env
After applying the above StorageCluster
, Portworx will restart with Security enabled using an auto-generated system secret and stork secret. These two secrets are used for internal Portworx communication between nodes and services.
Enabling authorization with a Portworx Manifest
To enable authorization you must simply edit your Portworx yaml
configuration
to add the appropriate information. You must first create a Kubernetes Secret which holds the values of the environment variables. Then populate the environment variables required from your Secret. Here is an example of how to
setup an environment variable from a Secret:
-
Generate the following random secret keys:
PORTWORX_AUTH_SYSTEM_KEY=$(cat /dev/urandom | base64 | fold -w 64 | head -n 1) \
PORTWORX_AUTH_SYSTEM_APPS_KEY=$(cat /dev/urandom | base64 | fold -w 64 | head -n 1) \
PORTWORX_AUTH_SHARED_SECRET=$(cat /dev/urandom | base64 | fold -w 64 | head -n 1)
-
Create a secret for all PX-Security keys:
oc create secret generic pxkeys \
--from-literal=system-secret=$PORTWORX_AUTH_SYSTEM_KEY \
--from-literal=shared-secret=$PORTWORX_AUTH_SHARED_SECRET \
--from-literal=stork-secret=$PORTWORX_AUTH_SYSTEM_APPS_KEY
-
Edit your Portworx manifest YAML to include the following:
...
name: stork
env:
- name: "PX_SHARED_SECRET"
valueFrom:
secretKeyRef:
name: pxkeys
key: stork-secret
...
name: portworx
args:
[..."-jwt_issuer", "myissuer", ...]
env:
- name: "PORTWORX_AUTH_JWT_SHAREDSECRET"
valueFrom:
secretKeyRef:
name: pxkeys
key: shared-secret
- name: "PORTWORX_AUTH_SYSTEM_KEY"
valueFrom:
secretKeyRef:
name: pxkeys
key: system-secret
- name: "PORTWORX_AUTH_SYSTEM_APPS_KEY"
valueFrom:
secretKeyRef:
name: pxkeys
key: stork-secret
...
Upgrading to Authorization enabled
Upgrading from auth disabled
to auth enabled
will not cause any issues for Kubernetes end users. This is because the system guest role will allow Kubernetes users to create and use public volumes. However, users are encouraged to make their volumes private by adding authorization to their PVCs.
Step by step guide
For a step by step guide of how to enable Portworx authorization, please see Securing your Portworx system.