Authentication and Authorization Introduction

This topic provides a high-level overview of the design and implementation of the Authentication and Authorization feature in VMware Tanzu GemFire for Kubernetes. For details about Authentication and Authorization in VMware Tanzu GemFire, refer to the following Tanzu GemFire product documentation:

Cluster Management Service Credentials

To regulate, monitor, and heal the state of a Tanzu GemFire cluster, the gemfire-operator must have permission to connect and execute particular operations on the managed cluster.

When Authentication and Authorization are enabled, the gemfire-operator requires a set of valid credentials that must always be successfully authenticated by the configured SecurityManager. Once authenticated, the gemfire-operator must have the following Resource Permissions so that required operations can be successfully authorized by the configured: SecurityManager:

DATA:MANAGE
CLUSTER:READ
CLUSTER:MANAGE

An independent Kubernetes Secret is used to store these credentials. The contents are automatically read by the gemfire-operator when needed, and are also mounted as Kubernetes Volumes within each member pod so that the Kubernetes Lifecycle Hooks can interact with the Tanzu GemFire cluster.

For more information about Resource Permissions, see Resource Permissions in Implementing Authorization in the Tanzu GemFire product documentation.

For more information about the Kubernetes components, see the following in the Kubernetes documentation:

Provision

The Secret is not automatically provisioned by VMware Tanzu GemFire for Kubernetes. It must be created before deploying a secured Tanzu GemFire cluster. The contents of the secret depends on the type of authentication scheme used.

Token-based Authentication: When token-based authentication is required, the Secret must contain at least the token key.
```
kubectl -n NAMESPACE-NAME create secret generic SECRET-NAME --from-literal=token=<MY_TOKEN>
```
Where:
- NAMESPACE-NAME is the value of the metadata.namespace field from the the cluster deployment yaml file.
- SECRET_NAME is the value of the spec.security.mgmtSvcCredentialsSecretName from the the cluster deployment yaml file.
Basic Authentication: When basic authentication is required, the Secret must contain at least the username and password keys.
```
kubectl -n NAMESPACE-NAME create secret generic SECRET-NAME --from-literal=username=<MY_USERNAME> --from-literal=password=<MY_PASSWORD>
```
Where:
- NAMESPACE-NAME is the value of the metadata.namespace field from the the cluster deployment yaml file.
- SECRET_NAME is the value of the spec.security.mgmtSvcCredentialsSecretName from the the cluster deployment yaml file.

Retrieval

To retrieve the credentials:

# Token Authentication
$ kubectl -n NAMESPACE-NAME get secret SECRET-NAME -o=jsonpath='{.data.token}' | base64 --decode

# Basic Authentication
$ kubectl -n NAMESPACE-NAME get secret SECRET-NAME -o=jsonpath='{.data.username}' | base64 --decode
$ kubectl -n NAMESPACE-NAME get secret SECRET-NAME -o=jsonpath='{.data.password}' | base64 --decode

Where:

NAMESPACE-NAME is the value of the metadata.namespace field from the the cluster deployment yaml file.
SECRET_NAME is the value of the spec.security.mgmtSvcCredentialsSecretName from the the cluster deployment yaml file.

Rotation

You can update the credentials within the Secret at any time bu using standard kubectl commands without triggering a rolling update of the pods.

The gemfire-operator retrieves the credentials directly from the Secret when needed, so they should always be up-to-date.

The Lifecycle Hooks, however, retrieve the credentials from a Kubernetes Volume mounted within the Pod. Mounted Secrets are Updated Automatically, but an inherent delay exists from when the Secret is updated until new values are projected to the Pod. Because of this delay, internal Lifecycle Hooks used by VMware Tanzu GemFire for Kubernetes retrieve the credentials from the mounted Kubernetes Volume in every attempt. A propagation delay after a rotation might cause transient authentication or authorization errors, but the credentials will eventually be updated and the operations should succeed.

To rotate the credentials:

# Token Authentication
$ kubectl -n NAMESPACE-NAME get secret SECRET-NAME -o json | jq --arg token "$(echo <NEW_TOKEN> | base64)" '.data["token"]=$token' | kubectl apply -f -

# Basic Authentication
$ kubectl -n NAMESPACE-NAME get secret SECRET-NAME -o json | jq --arg user "$(echo <NEW_USER> | base64)" '.data["username"]=$user' | kubectl apply -f -
$ kubectl -n NAMESPACE-NAME get secret SECRET-NAME -o json | jq --arg pass "$(echo <NEW_PASSWORD> | base64)" '.data["password"]=$pass' | kubectl apply -f -

Where:

NAMESPACE-NAME is the value of the metadata.namespace field from the the cluster deployment yaml file.
SECRET_NAME is the value of the spec.security.mgmtSvcCredentialsSecretName from the the cluster deployment yaml file.