Petr Gladkikh's questions

We running or components in Kubernetes with Docker as container runtime. A problem with it is that pod environment is polluted with Docker-style link variables like

• SERVICENAME_PORT_8181_TCP
• SERVICENAME_PORT_HTTP
• .....
• SERVICENAME_PORT

for each visible service (the ones in same namespace). In this situation it is rather easy for automatically created variables to have conflicts with explicitly declared environment. This sometimes leads to hard-to-diagnose problems. I would also not want to rely on those automatic variables as would prefer containers not to depend on details of Kubernetes service configuration. Currently I am adding unique name prefixes to explicit variables to avoid such conflicts.

Is there a way to configure cluster to not add those automatic variables for each visible service? Alternatively, would using other runtimes like containerd solve this problem? I am surprised that there are no readily googleable solutions for this since configuration through environment variables is considered a good practice. How in general do I use environment without running into such naming conflicts? Or service names are considered a part of contract with containers and I should not change them freely?

I have to use a service that uses self-signed certificate (from Ubuntu). I have added the company's CA to the trusted list (Ubuntu). After that "self signed certificate in chain" error is gone but now I get "CA certificate too weak" error. E.g.

curl -vvv https://someservicehost.net
 *   Trying 93.184.216.34:443...
 * TCP_NODELAY set
 * Connected to someservicehost.net (93.184.216.34) port 443 (#0)
 * ALPN, offering h2
 * ALPN, offering http/1.1
 * successfully set certificate verify locations:
 *   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
 * TLSv1.3 (OUT), TLS handshake, Client hello (1):
 * TLSv1.3 (IN), TLS handshake, Server hello (2):
 * TLSv1.2 (IN), TLS handshake, Certificate (11):
 * TLSv1.2 (OUT), TLS alert, bad certificate (554):
 * SSL certificate problem: CA certificate key too weak
 * Closing connection 0
curl: (60) SSL certificate problem: CA certificate key too weak

I tried to search it but there is surprisingly little information on this. So I have 2 questions

• How do I find exactly which properties of this certificate make it "weak"? Is it hash, key length, something else? I deliberately omitted the certificate details as I want to know how do I diagnose the problem not the problem with this particular certificate.
• How do I force client software to trust it? I think I do not have a choice of upgrading the CA cert.