Support of setting arbitrary password for PKCS12 truststore about trust-manager HOT 19 CLOSED

i would really appreciate that setting arbitrary password for PKCS12 truststore in current form of saving trustedcerts because of java itself is good enough.

I think we are heading for the solution outlined in #235 - where the password can be specified in clear text in Bundle resources. I'm hoping that @arsenalzp hasn't given up on that PR. 🙏

Let me exame solution of this theoretical issue in the wild:-) will create then another ticket.

Please do! I think you will find many different opinions about this. But I'll be surprised if you can find a valid threat model justifying a really secret password for trust stores.

Hello,
Sure I didn't give up, I'm still having vacation! :)

from trust-manager.

Oh, doesn't even Java 17 support password-less PKCS#12 truststores? Yes, then I think it makes sense to add a controller config to optionally set a password for all PKCS#12 truststores created by trust-manager. Note: I suggest making this a configuration of the controller globally for the cluster, and NOT per Bundle. Please submit a PR and assign me for review.

from trust-manager.

Opt-in to export in JKS/PKCS12 is there, but with hard-coded password (JKS) and password-less (PKCS12).

from trust-manager.

Of course we can user Secret resource which is retrieved by trust-manager controller, however this way adding some complication to the controller logic; this way is more secure.

Passwords for truststores are not about security, but integrity. And all consumers of the truststore need to know the agreed password. So I would not consider it a secret. Truststores contain only public information.

from trust-manager.

Hi, for the first step, i would really appreciate that setting arbitrary password for PKCS12 truststore in current form of saving trustedcerts because of java itself is good enough.

Let me exame solution of this theoretical issue in the wild:-) will create then another ticket.

And thank you so much for all your points!

Kind Regards,
Goran.

from trust-manager.

/good-first-issue

from trust-manager.

@erikgb:
This request has been marked as suitable for new contributors.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-good-first-issue command.

from trust-manager.

This issue is reasonable.
trust-manager exports bundles in PEM format by default.
Do we have to add feature to export bundles in PKCS12 format optionally, with arbitrary password option as well?

from trust-manager.

Ah, I found AdditionalFormats structure.

from trust-manager.

/assign

from trust-manager.

Hello,
I'm thinking about the best way providing arbitrary password to the trust-manager controller.
As it cluster scoped, it's possible to set it by using trust-manager CLI arguments or ether by using environment variables for trust-manager Deployment resource.
Of course we can user Secret resource which is retrieved by trust-manager controller, however this way adding some complication to the controller logic; this way is more secure.

from trust-manager.

Of course we can user Secret resource which is retrieved by trust-manager controller, however this way adding some complication to the controller logic; this way is more secure.

Passwords for truststores are not about security, but integrity. And all consumers of the truststore need to know the agreed password. So I would not consider it a secret. Truststores contain only public information.

Well for me is just all about usage scenario. If you have few clients to share password for trustore, it does not means it is publicly available to all. One case would be when the attacker adds rouge rootCA, all clients will trust him. I agree that this password must be shared between clients, but there is a difference between sharing password with group of clients and made it publicly. IMHO, this should be a capability and leave it for user various usage scenarios.

from trust-manager.

Of course we can user Secret resource which is retrieved by trust-manager controller, however this way adding some complication to the controller logic; this way is more secure.

Passwords for truststores are not about security, but integrity. And all consumers of the truststore need to know the agreed password. So I would not consider it a secret. Truststores contain only public information.

Well for me is just all about usage scenario. If you have few clients to share password for trustore, it does not means it is publicly available to all. One case would be when the attacker adds rouge rootCA, all clients will trust him. I agree that this password must be shared between clients, but there is a difference between sharing password with group of clients and made it publicly. IMHO, this should be a capability and leave it for user various usage scenarios.

That attack vector must be dealt with some other way. A truststore/keystore password will never protect you by itself. We treat the password as just as a technical requirement for keystores/truststores in our organization. If an attacker can take control over your trust roots, you have a problem anyway. And password-less is the new standard. And Java has been running with changeit as the well-known password for decades now.

from trust-manager.

Password-less does not mean that it is credential-less:-)
Pkcs12 is a standard which protects whole container with password, and inside container there is "shelf" for trustcerts, private(protected by additional password) and public keys, simmetric keys. Java default container store is pkcs12 which also needs password.
I vote that credentials like password should be properly stored in kubernetes secret object because they are sensitive data regardless what they protects, asymmetric keys or simmetric keys or trustedCA.
To make any IT system or subsystem from various attack vectors more resilient, security hardening are applied on each layers, like an onion. So even password protecting container and trusted CA inside seems useless, it may delay or stop attackers.
I think that softwer should be build by the standards and to support standards, and leave for users various usage scenarios to decide.

Thnx you so much for all your effort.

from trust-manager.

I agree with you, but if you need true secure store then it's not about Secret resource, because it's not secure by its nature. However, nobody has access to trust-manager controller namespace and its resources with properly configured RBAC, so pkcs12 arbitrary password is kept away of stranger's eyes :)

from trust-manager.

because it's not secure by its nature.

Yes they are not, but, applications usually user secret name to get values from secrets, and secrets can be then more secured with external solutions.

from trust-manager.

I think we will need a design proposal if you think the truststore password is a real secret that needs to be protected. It's a pretty big change going from well-known hardcoded passwords in source code to a full-blown Kubernetes secrets solution. I would at least have the following questions:

1. How will consumer applications of the bundle target configmaps/secrets get the password to the stores?
2. Will there be one password for all bundles in the cluster, or should it be possible to configure a separate password per bundle/store? The latter will require extending the Bundle API and more controller mechanics.

I don't think handling all this additional complexity makes much sense. The trust bundles provided by trust-manager should be considered as a dynamic alternative to trust bundles delivered as part of an operating system (or JVM default cacerts). Most consumers will also probably use the PEM trust bundle format - which is not protected by any password. And all target configmaps/secrets are controlled by the trust-manager controller, so any attempt to change the store - like adding a rouge root CA should be reverted pretty fast.

Most of your arguments make sense from a theoretical point of view, but I don't think it's worth the additional hassle in this context.

from trust-manager.

i would really appreciate that setting arbitrary password for PKCS12 truststore in current form of saving trustedcerts because of java itself is good enough.

I think we are heading for the solution outlined in #235 - where the password can be specified in clear text in Bundle resources. I'm hoping that @arsenalzp hasn't given up on that PR. 🙏

Let me exame solution of this theoretical issue in the wild:-) will create then another ticket.

Please do! I think you will find many different opinions about this. But I'll be surprised if you can find a valid threat model justifying a really secret password for trust stores.

from trust-manager.

I guess that optional password for each store is the good compromise, it was mentioned by @SgtCoDFish in the following comment: #229 (comment)

from trust-manager.