Custom user credentials are stored as plaintext in the datagrid pod filesystem

[sereneshikari]

When I follow this section on "[configuring] access to Infinispan cluster endpoints with custom credentials", I am able to see the credentials are stored as plaintext in the filesystem of the datagrid pods.

Steps to Reproduce

Create a throwaway K8s cluster with kind

kind create cluster

Install the Infinispan operator

I installed the operator from OperatorHub.io by following the instructions here...

curl -sL https://github.com/operator-framework/operator-lifecycle-manager/releases/download/v0.25.0/install.sh | bash -s v0.25.0

kubectl create -f https://operatorhub.io/install/infinispan.yaml

kubectl get csv -n operators

Create a basic Infinispan datagrid with custom user credentials

I followed the instructions here to create the K8s secret for the custom user credentials and referenced it in the Infinispan CR...

credentials:
- username: myfirstusername
  password: changeme-one
- username: mysecondusername
  password: changeme-two

The above YAML is saved to identities.yaml and used to create the K8s secret

kubectl create secret generic --from-file=identities.yaml connect-secret

apiVersion: infinispan.org/v1
kind: Infinispan
metadata:
  name: infinispan
  spec:
    replicas: 2
    service:
      type: DataGrid
    security:
      endpointSecretName: connect-secret

The above manifest is saved to infinispan-cr.yaml and applied

kubectl apply -f infinispan-cr.yaml

Verify that custom user credentials are stored as plaintext

After the datagrid is created, I exec into one of the datagrid pods...

> kubectl exec -it infinispan-0 -- sh
sh-4.4$ cat /etc/security/user/identities.yaml
credentials:
- username: myfirstusername
  password: changeme-one
- username: mysecondusername
  password: changeme-two
sh-4.4$ cat /etc/security/conf/operator-security/identities.cli
user create operator --realm admin -p clxTbohJvObCkwXt --users-file cli-admin-users.properties --groups-file cli-admin-groups.properties --groups admin,controlRole
user create myfirstusername --realm default -p changeme-one --users-file cli-users.properties --groups-file cli-groups.properties
user create mysecondusername --realm default -p changeme-two --users-file cli-users.properties --groups-file cli-groups.properties

Interestingly, the same credentials are encrypted in the cli-users.properties

sh-4.4$ cat server/conf/cli-users.properties
#$REALM_NAME=default$
#$ALGORITHM=encrypted$
#Mon Aug 21 07:00:33 GMT 2023
mysecondusername=scram-sha-1\:BYGcIAyvGgp2j38zR9zX46/Knf0DJ1h6ZoVTIIRaf5a1XkT2ew\=\=;scram-sha-256\:BYGcIAwPrWvzXalAd1R/V48roVijdPtQuTmySMqw+Go0PkiriHOO6p0hD/g4B/obXQ\=\=;scram-sha-384\:BYGcIAzuUK8SzC8z5P4Trl00BxPwKQgJ3Q2ofAXDCtOlbtqMqptE6gE194MUGa9U13akSNyvWzMRVvbXXTsElIM\=;scram-sha-512\:BYGcIAzKB7xvk4aYsvGRIZA1A0hKxOUqDxDwSmnF3m84Din3oPsH6Vttm9Y5SjwefkyOHSQsdlZ7SrFrWZp5guB+H7enPmNEG/CL5vAjGfuQ;digest-md5\:AhBteXNlY29uZHVzZXJuYW1lB2RlZmF1bHQ1Y6YQvWfJkpsSQQt8BNAx;digest-sha\:AhBteXNlY29uZHVzZXJuYW1lB2RlZmF1bHRPDBD7hrqo89NYccDQTrTEg3R+Aw\=\=;digest-sha-256\:AhBteXNlY29uZHVzZXJuYW1lB2RlZmF1bHTg0dHuu/jJ1EzWyhkjTMIt6ADSsohBlVusHI7380kQiQ\=\=;digest-sha-384\:AhBteXNlY29uZHVzZXJuYW1lB2RlZmF1bHRvHgIZO1P8UxIF/sv+pNOqYZk56KvvP8cT1i0vkopgjdJ2g9oR06WUMP2UQ2Uw/vc\=;digest-sha-512\:AhBteXNlY29uZHVzZXJuYW1lB2RlZmF1bHRInlsYMfFqGeGYQrYB8injPWMx1YP6GPRBuj8KZbVXLRRFNRKzKsall7ymIIZHtrnage1JI12lQVQoues7z0zL;
myfirstusername=scram-sha-1\:BYGcIAzY1LZOeiN38BhEuR33iZbo5OVZzb8+dvAHMwKgHysDlw\=\=;scram-sha-256\:BYGcIAzuUYz5EIMsuY5u6wA9OFndn9D44NqXcprXv3j90mWmD7euoRWryYDEBcVC3Q\=\=;scram-sha-384\:BYGcIAw2x2MNsp4MlLc1176T/xS1qRZA80vwqtzPtFXcSlsDjen6hfAi9DN0Dv1J5mrLqlN7yh8hV2bYECojw9E\=;scram-sha-512\:BYGcIAyvqTLDu9UrYzyu8XhipHSfeiorYte6VtrS3oOOakbusSWV9rcSlvHWkL7UC3KI5HQVq3IsYD23nMLdNnE+4tLYHuZLl7uHxXi/dySJ;digest-md5\:Ag9teWZpcnN0dXNlcm5hbWUHZGVmYXVsdLuULo8IoqTU3DRpk2Z6lJA\=;digest-sha\:Ag9teWZpcnN0dXNlcm5hbWUHZGVmYXVsdPAwJdluzbraV9AlTlG0AXb+4lo8;digest-sha-256\:Ag9teWZpcnN0dXNlcm5hbWUHZGVmYXVsdDw9prD6rwKreDdXqNwrElbBajActBgAh+o07mH0uOmW;digest-sha-384\:Ag9teWZpcnN0dXNlcm5hbWUHZGVmYXVsdJuMlw0uZXdMMJtVKM7BDv5O0PwlrNpZMWcJ62I5AvYy9SrUTpKRztUJbjjVXC9qEQ\=\=;digest-sha-512\:Ag9teWZpcnN0dXNlcm5hbWUHZGVmYXVsdPdmMAkdwceIWClQ2Z4+scAJ7Ornonfqxl/sRwRi41QMKnCF0WWsY159dpxL03uAzGEGqFCp0xgABBYi1dQ9Lwg\=;

Questions

1. Is this expected behaviour? If so, why?
2. Is it possible to encrypt the credentials in identities.yaml?

[ryanemerson]

• Is this expected behaviour? If so, why?

Yes this is expected behaviour, as the secret referenced by spec.security.endpointSecretName is simply mounted inside the StatefulSet pods as per k8s conventions. In order to access these files a user needs to have exec permissions for pods in the deployment namespace. You can limit access by configuring k8s RBAC according to your needs.

Interestingly, the same credentials are encrypted in the cli-users.properties

These are the hash forms of the passwords using the different authentication mechanisms supported by the server and are created on pod startup.

2. Is it possible to encrypt the credentials in identities.yaml?

No