Error in amq-credential-secret

[mrbq]

In the amq-broker-75-persistence-clustered-ssl there is an error when creating the amq-credential-secret. The value of the data in this secret is hardcoded, in particular the trust store and the key store password is hardcoded to password:

- apiVersion: v1
  kind: Secret
  metadata:
    annotations:
      description: Credentials used in broker config. Default values are admin(AMQ_USER and AMQ_PASSWORD), clusteruser(AMQ_CLUSTER_USER), clusterpassword(AMQ_CLUSTER_PASSWORD), password(AMQ_TRUSTORE_PASSWORD and AMQ_KEYSTORE_PASSWORD)
    name: amq-credential-secret
  type: Opaque
  data:
    ${AMQ_USER}: YWRtaW4=
    ${AMQ_PASSWORD}: YWRtaW4=
    ${AMQ_CLUSTER_USER}: Y2x1c3RlcnVzZXI=
    ${AMQ_CLUSTER_PASSWORD}: Y2x1c3RlcnBhc3N3b3Jk
    ${AMQ_TRUSTSTORE_PASSWORD}: cGFzc3dvcmQ=
    ${AMQ_KEYSTORE_PASSWORD}: cGFzc3dvcmQ=

If the password is not password the broker pods will fail:

2019-12-05 14:34:38,552 INFO  [io.hawt.system.ProxyWhitelist] Initial proxy whitelist: [localhost, 127.0.0.1, 10.1.10.121, broker-amq-0.broker-amq-headless.amq-test.svc.cluster.local]
--
  | java.io.IOException: keystore password was incorrect
  | at sun.security.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:2059)
  | at sun.security.provider.KeyStoreDelegator.engineLoad(KeyStoreDelegator.java:238)
  | at sun.security.provider.JavaKeyStore$DualFormatJKS.engineLoad(JavaKeyStore.java:70)
  | at java.security.KeyStore.load(KeyStore.java:1445)
  | at org.eclipse.jetty.util.security.CertificateUtils.getKeyStore(CertificateUtils.java:52)
  | at org.eclipse.jetty.util.ssl.SslContextFactory.loadKeyStore(SslContextFactory.java:998)
  | at org.eclipse.jetty.util.ssl.SslContextFactory.load(SslContextFactory.java:252)
  | at org.eclipse.jetty.util.ssl.SslContextFactory.doStart(SslContextFactory.java:219)
  | at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
  | at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:131)
  | at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:113)
  | at org.eclipse.jetty.server.SslConnectionFactory.doStart(SslConnectionFactory.java:72)
  | at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
  | at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:131)
  | at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:113)
  | at org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:270)
  | at org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:81)
  | at org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:236)
  | at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
  | at org.eclipse.jetty.server.Server.doStart(Server.java:431)
  | at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
  | at org.apache.activemq.artemis.component.WebServerComponent.start(WebServerComponent.java:229)
  | at org.apache.activemq.artemis.cli.commands.Run.execute(Run.java:105)
  | at org.apache.activemq.artemis.cli.Artemis.internalExecute(Artemis.java:150)
  | at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:98)
  | at org.apache.activemq.artemis.cli.Artemis.execute(Artemis.java:125)
  | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
  | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  | at java.lang.reflect.Method.invoke(Method.java:498)
  | at org.apache.activemq.artemis.boot.Artemis.execute(Artemis.java:129)
  | at org.apache.activemq.artemis.boot.Artemis.main(Artemis.java:49)
  | Caused by: java.security.UnrecoverableKeyException: failed to decrypt safe contents entry: javax.crypto.BadPaddingException: Given final block not properly padded. Such issues can arise if a bad key is used during decryption.
  | ... 32 more
  | 2019-12-05 14:34:40,167 INFO  [org.apache.activemq.artemis.core.server] AMQ221002: Apache ActiveMQ Artemis Message Broker version 2.10.0.redhat-00004 [589926a8-176c-11ea-ba2d-0a580a010a79] stopped, uptime 10.326 seconds

This is the secret created by the template:

apiVersion: v1
data:
  Q6yK5p3p: Y2x1c3RlcnBhc3N3b3Jk
  amq-user: YWRtaW4=
  passw0rd: YWRtaW4=
  useryWM: Y2x1c3RlcnVzZXI=
kind: Secret
metadata:
  annotations:
    description: Credentials used in broker config. Default values are admin(AMQ_USER
      and AMQ_PASSWORD), clusteruser(AMQ_CLUSTER_USER), clusterpassword(AMQ_CLUSTER_PASSWORD),
      password(AMQ_TRUSTORE_PASSWORD and AMQ_KEYSTORE_PASSWORD)
  creationTimestamp: null
  labels:
    template: amq-broker-75-persistence-clustered-ssl
    xpaas: 1.4.16
  name: amq-credential-secret
  selfLink: /api/v1/namespaces/amq-test/secrets/amq-credential-secret
type: Opaque

Should the parameters in the secret be moved to the value and not to the key?

[therevills]

I can confirm this is an issue.

[mgohashi]

I agree this is an issue

[pbertera]

The same issue is on amq-broker-76-ssl.yaml
EDIT: see next comment

[pbertera]

Digging more deeply seems to be not an issue: variables AMQ_USER AMQ_PASSWORD AMQ_KEYSTORE_PASSWORD AMQ_TRUSTSTORE_PASSWORD are intended to be used as keys of the secret with name defined by AMQ_CREDENTIAL_SECRET.

If you create the secret:

oc create secret generic my-amq-credential-secrets --from-literal=amqUser=amq --from-literal amqPassword=amq --from-literal=trustStorePassword=pippo123 --from-literal=keyStorePassword=pippo123

then you can instantiate the app with:

oc new-app --template=amq-broker-76-ssl \
    -p AMQ_USER=amqUser \
    -p AMQ_PASSWORD=amqPassword \
    -p AMQ_KEYSTORE_PASSWORD=keyStorePassword \
    -p AMQ_TRUSTSTORE_PASSWORD=trustStorePassword \
    -p AMQ_CREDENTIAL_SECRET=my-amq-credential-secrets \
    -p ....

[therevills]

Digging more deeply seems to be not an issue: variables AMQ_USER AMQ_PASSWORD AMQ_KEYSTORE_PASSWORD AMQ_TRUSTSTORE_PASSWORD are intended to be used as keys of the secret with name defined by AMQ_CREDENTIAL_SECRET.

If you create the secret:

Where did you find it out? Was there any instructions?

[gaohoward]

Yes the parameters are all the keys in the secret. They are used to retrieve the values from the secret. Related Jira: https://issues.redhat.com/browse/ENTMQBR-2629 Howard

…

On Fri, May 29, 2020 at 5:54 PM therevills ***@***.***> wrote: Digging more deeply seems to be not an issue: variables AMQ_USER AMQ_PASSWORD AMQ_KEYSTORE_PASSWORD AMQ_TRUSTSTORE_PASSWORD are intended to be used as keys of the secret with name defined by AMQ_CREDENTIAL_SECRET. If you create the secret: Where did you find it out? Was there any instructions? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#52 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFHR3ZRK5YOVSN5PTJKKE3RT6A57ANCNFSM4JV2SR2A> .

[pbertera]

Digging more deeply seems to be not an issue: variables AMQ_USER AMQ_PASSWORD AMQ_KEYSTORE_PASSWORD AMQ_TRUSTSTORE_PASSWORD are intended to be used as keys of the secret with name defined by AMQ_CREDENTIAL_SECRET.
If you create the secret:

Where did you find it out? Was there any instructions?

Is explained into the Red Hat AMQ deployment instructions, see here and here

[buuhsmead]

Can we please change this clever solution to something that an [average | enterprise] user is accustomed to!
I always have a hard time explaining this to customers. The value is used as a key to use the key as a value.