This section 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 Tanzu GemFire, please refer to the official product documentation at Authentication and Authorization.

Cluster Management Service Credentials

In order to regulate, monitor and heal the state of a Tanzu GemFire cluster, the gemfire-operator needs permission to connect and execute certain operations on the managed cluster.

When Authentication and Authorization are enabled, as a means of achieving the aforementioned goal, the gemfire-operator requires a set of valid credentials that must always be successfully authenticated by the configured SecurityManager. The subject , once authenticated, must have assigned the following Resource Permissions so the 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 the Lifecycle Hooks can interact with the Tanzu GemFire cluster.

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 will depend upon the authentication scheme used.

  • When token based authentication is required, the Secret must have at least the token key.
kubectl -n NAMESPACE-NAME create secret generic SECRET-NAME --from-literal=token=<MY_TOKEN>

where NAMESPACE-NAME and SECRET_NAME are the values used for fields metadata.namespace and spec.security.mgmtSvcCredentialsSecretName within the cluster deployment yaml, respectively.

  • When basic authentication is required, the Secret must have 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 and SECRET_NAME are the values used for fields metadata.namespace and spec.security.mgmtSvcCredentialsSecretName within the cluster deployment yaml, respectively.

Retrieval

To retrieve the credentials:

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

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

where NAMESPACE-NAME and SECRET-NAME are the values used for fields metadata.namespace and spec.security.mgmtSvcCredentialsSecretName within the cluster deployment yaml, respectively.

Rotation

The credentials within the Secret can be updated at any time through regular 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 there’s an inherent delay from the moment when the Secret is updated to the moment when new values are projected to the Pod, though. Because of this, internal Lifecycle Hooks used by VMware Tanzu GemFire for Kubernetes retrieve the credentials from the mounted Kubernetes Volume in every attempt so, even though the propagation delay after a rotation might cause transient authentication or authorization errors, the credentials eventually will be consistent 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 and SECRET_NAME are the values used for fields metadata.namespace and spec.security.mgmtSvcCredentialsSecretName within the cluster deployment yaml, respectively.

check-circle-line exclamation-circle-line close-line
Scroll to top icon