Enabling Authorization
This page will give an overview of how to enable authorization in Portworx. For specific details on how to enable authorization in Portworx for a given container orchestration system, please refer to the appropriate installation instructions in this site.
Requirements
To enable authorization in Portworx, administrators must provide the following information:
- System shared key for secure cluster communications.
- If using Kubernetes and Stork, a Stork shared key for secure communications
- A trusted authorization model for users; either self-signed, OIDC, or both.
- If OIDC is used, then the following must be provided:
- OIDC Issuer
- OIDC Client id
- If self-signed token model is used, then the following must be provided:
- JWT issuer
- JWT shared secret or JWT public key
- If OIDC is used, then the following must be provided:
Setup
The information above must be provided to Portworx configuration. Sensitive information like shared secrets can only be provided as environment variables. These variables can then be filled in automatically by Secrets coming from your container orchestration system.
Environment variables
The following environment variables can be provided to enable authorization:
Environment Variable | Required | Description |
---|---|---|
PORTWORX_AUTH_SYSTEM_KEY |
Yes | Shared secret used by Portworx to generate tokens for cluster communications |
PORTWORX_AUTH_STORK_KEY |
Yes when using Stork | Share secret used by Stork to generate tokens to communicate with Portworx. The shared secret must match the value of PX_SHARED_SECRET environment variable in Stork. |
PORTWORX_AUTH_JWT_SHAREDSECRET |
Optional | Self-generated token shared secret, if any |
Configuration
All other non-sensitive information can be provided to px-runc
using the
following command line arguments:
Name | Description |
---|---|
oidc_issuer <URL> |
Location of OIDC service (e.g. https://accounts.google.com ). This must match the iss value in the claims of the tokens. |
oidc_client_id <id> |
Client id provided by the OIDC |
oidc_custom_claim_namespace <namespace> |
OIDC namespace for custom claims |
jwt_issuer <issuer> |
JSON Web Token issuer (e.g. openstorage.io). This is the token issuer for your self-signed tokens. It must match the iss value in the claims of the tokens. |
jwt_rsa_pubkey_file <file path> |
JSON Web Token RSA Public file path |
jwt_ecds_pubkey_file <file path> |
JSON Web Token ECDS Public file path |
username_claim <claim> |
Claim key from the token to use as the unique id of the user ( |
Upgrading from non-auth to auth
A few steps must be taken to upgrade a cluster from non-auth to auth:
- Make sure to add auth configurations as documented above.
If you plan to pair and migrate your clusters, then you must generate a new cluster token. You can do this by executing
pxctl cluster token reset
Ensure that all nodes are configured as auth-enabled. Mixed clusters of auth and non-auth nodes will allow for security vulnerabilities.