Skip to main content
Version: 3.2

Enable authorization in FlashArray

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.

note
  • 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.

  1. First, familiarize yourself with the Security spec in the StorageCluster article.

  1. Create a Kubernetes secret for your shared-secret:

    kubectl create secret generic -n <px-namespace> px-shared-secret \
    --from-literal=shared-secret=$EXISTING_SHARED_SECRET_VALUE

  1. Add the following spec.security section in your StorageCluster:

    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'
  2. Remove the PORTWORX_AUTH_JWT_ISSUER and PORTWORX_AUTH_JWT_SHAREDSECRET env variables from your StorageCluster env spec.

  3. 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:

  1. 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'
  2. Remove the PORTWORX_AUTH_SYSTEM_KEY and PORTWORX_AUTH_SYSTEM_APPS_KEY environment variables in your StorageCluster spec.env.

  3. Remove the PX_SHARED_SECRET environment variable in your StorageCluster 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:

  1. 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)

  1. Create a secret for all PX-Security keys:

    kubectl 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

  1. 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.