Conversation
|
+1 please! |
|
@sabre1041 I guess after merging this no integration test is running anymore. Could you provide basic documentation how to setup the appropriate certs please? |
|
The following documentation corresponds to the creation of the requisite java certificate stores and usage within the docker-java client. Please let me know if you how you want to handle incorporating into official documentation Configuring SSLFollow the steps as documented in the Running Docker with https to create a CA, server and client key. The following files are produced:
TruststoreCreate a truststore for the CA key KeystoreThe keystore will hold the server and client certificates Create a PKCS12 archive containing the server and client certificates Import the PKCS12 archive into a Java keystore Create a SSL Enabled Docker ClientDockerClientConfig.DockerClientConfigBuilder configBuilder = new DockerClientConfig.DockerClientConfigBuilder()
.withKeystore("/path/to/file/docker.ks")
.withKeystorePassword("changeit")
.withTruststore("/path/to/file/docker.ts")
.withTruststorePassword("changeit")
.withUri("https://localhost:2375");
DockerClientConfig config = configBuilder.build();
DockerClient client = DockerClientBuilder.getInstance(config).build(); |
|
@sabre1041 Thanks! But wait, what do you think of examples mentioned in #77? I think this approach would be much easier to setup. |
|
@marcuslinke I like the idea of loading the pem formatted certificates as referenced in the link in #77 but still would like to give the users options to specify their own keystore. I can go ahead and add the following methods
Thoughts? |
|
Could we use the same mechanism as the authentication? I.e. ~/.docker.io.properties, or System.getProperty(...) |
|
@alexec I was planning on adding a "docker.io.dockerCertPath" system property when leveraging system properties instead of explicitly calling these methods as used elsewhere in the DockerClientConfigBuilder |
|
@sabre1041 I think as long as we achieve the default behavior to load certs from DOCKER_CERT_PATH everything will be fine. Absent certs configuration should be accepted to support older (non-secured) server versions also. |
|
@marcuslinke that works for me. I would recommend at least having the option for a user to define the DOCKER_CERT_PATH in the event they wish to not set an environment variable. I will go ahead and remove the references to keystore and truststore configurations |
|
@sabre1041 Great! Thanks. |
…ty to leverage environment variable or explicitly specify location of default certificates
|
Functionality to utilize default pem files (ca.pem, cert.pem and key.pem) implemented. Will attempt to locate file locations when set in the following order:
|
|
@sabre1041 Thanks! I will definitely merge it within the next few days. |
|
After updating to the latest Boot2Docker we ran into this exact same issue. I've verified that the code changes provided here solve our problem. We're excited to see this get in! |
|
@sabre1041 I've done some minor modifications to make it compile and run under java 1.6. |
|
@marcuslinke Successful execution of secured TLS client using java 7. I am receiving errors when running building the project though (connection refused in AbstractDockerClientTest) |
|
@sabre1041 This is because of wrong configuration probably. I've just pushed a fix for the default configuration. Please test again. |
|
@marcuslinke same result on freshly pulled code |
|
@sabre1041 Whats your test environment? Do you test against local running docker? For me all integration tests passes with jdk1.7.0_67 on MacOS and local running boot2docker v1.3.0. |
|
@sabre1041 Integration tests are now enabled by default: See #79 |
|
I can confirm that the build runs successfully on a Linux machine (no boot2docker, no TLS). But I can confirm that the error message above occurs when the |
|
After confirming and configuring values in properties file, integration tests pass successfully on MacOS jdk1.7.0.67. I do question whether integration tests should be run as part of the default build. There is up front work that is required to be able to build the project without specifying maven options to disable tests. This breaks the "fail fast" principles Continuous Integration/Continuous Delivery where only unit tests are validated during an initial build and integration/finer grained testing occurs in subsequent builds. I agree that integration tests which do take longer than straight unit tests should belong to the own testing group as brought up in #79, but should also be separated out potentially into their own maven profile that focuses on integration testing specifically. thoughts? |
There was a problem hiding this comment.
This is cool. Do we want to use a common set of env properties for configuration for consistency? E.g. DOCKER_USERNAME etc.?
|
+1 for @alexec's suggestion. It would be quite convenient to support well known default env variables like |
|
P.S. that would be another pull request/issue though ;-) |
|
I've created a new pull for the updated config. #81 |
|
@alexec Thanks! Just merged it. In my opinion it great to use the default docker env variables (DOCKER_HOST, DOCKER_CERT_PATH ...) but we should NOT introduce additional ones. |
5 participants
Added SSL support for defining a keystore/password and truststore/password to Docker client. Latest release of Boot2Docker (OSX) enables TLS by default and SSL support is needed for continued interoperability with Docker