|
3 | 3 | Unit tests, which do not rely on a Vault server being available, are separated from |
4 | 4 | these integration tests, which do require a Vault instance. |
5 | 5 |
|
6 | | -Configuring a Vault Server |
7 | | -========================== |
8 | | -It's not necessary to have a production-grade Vault server. To run these tests, you |
9 | | -can simply run a [Dev Server](https://www.vaultproject.io/intro/getting-started/dev-server.html) |
10 | | -process: |
| 6 | +Running the Integration Tests |
| 7 | +============================= |
| 8 | +Originally this test suite required a decent amount of manual setup. You had to run and configure a Vault server |
| 9 | +instance on your machine, and populate several environment variables with values that would be picked up by the |
| 10 | +tests. |
11 | 11 |
|
12 | | -``` |
13 | | -$ vault server -dev` |
| 12 | +Since then, the tests have been modified to work with [TestContainers](https://www.testcontainers.org/), a Java |
| 13 | +library that efficiently manages Docker containers and makes them available to JUnit tests. So now, setup of the |
| 14 | +Vault server instance is entirely automated, and dealt with by the test suite itself. |
14 | 15 |
|
15 | | -==> WARNING: Dev mode is enabled! |
| 16 | +However, to run these tests you do need to have a current version of Docker installed on your machine. This is |
| 17 | +supported for Linux, OS X, and Windows, although the details vary significantly between those operating systems. |
| 18 | +See the [Docker website](https://www.docker.com/) for information on installing Docker on your OS, after checking |
| 19 | +also with the TestContainers website for OS-specific caveats (Windows in particular). |
16 | 20 |
|
17 | | -In this mode, Vault is completely in-memory and unsealed. |
18 | | -Vault is configured to only have a single unseal key. The root |
19 | | -token has already been authenticated with the CLI, so you can |
20 | | -immediately begin using the Vault CLI. |
| 21 | +With Docker installed on your machine, you can run this test suite using the `integrationTest` Gradle task: |
21 | 22 |
|
22 | | -The only step you need to take is to set the following |
23 | | -environment variables: |
24 | | -
|
25 | | - set VAULT_ADDR=http://127.0.0.1:8200 |
26 | | -
|
27 | | -The unseal key and root token are reproduced below in case you |
28 | | -want to seal/unseal the Vault or play with authentication. |
29 | | -
|
30 | | -Unseal Key: 642e33b1c397c292743df56da6129a25df6a6349934931f55a2baac34a6e2c80 |
31 | | -Root Token: 764cf317-d3b9-3d52-dc7d-e4f0198f6a8c |
32 | | -
|
33 | | -... |
34 | | -``` |
35 | | - |
36 | | -Some of the integration tests verify that an authentication token can be retrieved |
37 | | -from various auth backends (e.g. [App Id](https://www.vaultproject.io/docs/auth/app-id.html), |
38 | | -[Username & Password](https://www.vaultproject.io/docs/auth/userpass.html), etc). |
39 | | -So prior to running these tests, you will need to run some Vault CLI commands to |
40 | | -enable auth backends and populate user and app data: |
41 | | - |
42 | | -``` |
43 | | -vault auth-enable app-id |
44 | | -vault write auth/app-id/map/app-id/fake_app display_name=fake_app |
45 | | -vault write auth/app-id/map/user-id/fake_user value=fake_app |
46 | | -
|
47 | | -vault auth-enable userpass |
48 | | -vault write auth/userpass/users/fake_user password=fake_password |
49 | | -
|
50 | | -vault mount -path=pki pki |
51 | | -vault mount -path=other-pki pki |
52 | | -vault write pki/root/generate/internal common_name=myvault.com ttl=99h |
53 | | -
|
54 | | -vault auth-enable approle |
55 | | -vault write auth/approle/role/testrole secret_id_ttl=10m token_ttl=20m token_max_ttl=30m secret_id_num_uses=40 |
56 | | -``` |
57 | | - |
58 | | -Configuring and Running the Integration Tests |
59 | | -============================================= |
60 | | -The Gradle `integrationTest` task is used to execute the integration test suite. |
61 | | -When running this Gradle task, you need to pass several JVM options so that Gradle |
62 | | -will make them available to the tests: |
63 | | - |
64 | | -* `VAULT_ADDR`: The connection URL for the Vault server. The Dev Server displays |
65 | | - this when the server starts up (e.g. `http://127.0.0.1:8200`) in the example above. |
66 | | -* `VAULT_TOKEN`: The root token, to enable Vault API calls. The Dev Server also |
67 | | - displays this at startup (e.g. `764cf317-d3b9-3d52-dc7d-e4f0198f6a8c` in the |
68 | | - example above). |
69 | | -* `VAULT_APP_ID`: An application ID that has been created in the Vault server, |
70 | | - for testing the App Id auth backend. This can be whatever you populate (e.g. |
71 | | - `fake_app` in the example CLI command above). |
72 | | -* `VAULT_USER_ID`: A user ID that has been created in the Vault server, for testing |
73 | | - the Username and Password auth backend. This can be whatever you populate (e.g. |
74 | | - `fake_user` in the example CLI command above). |
75 | | -* `VAULT_PASSWORD`: The password corresponding to the above user (e.g. `fake_password` |
76 | | - in the CLI command above). |
77 | | - |
78 | | -Example Gradle invocation: |
79 | | - |
80 | | -`$ gradle integrationTest -DVAULT_ADDR=http://127.0.0.1:8200 -DVAULT_TOKEN=764cf317-d3b9-3d52-dc7d-e4f0198f6a8c -DVAULT_APP_ID=fake_app -DVAULT_USER_ID=fake_user -DVAULT_PASSWORD=fake_password` |
| 23 | +`$ ./gradlew integrationTest` |
0 commit comments