You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You have to benchmark an actual version of the TSC, though this can be a `SNAPSHOT` version published locally.
19
21
Update the `pom.xml` to whatever version you'd like to test.
20
22
21
-
22
23
## Tenant Security Proxy
23
24
24
25
In order to run the benchmarks, the TSC needs to connect to a _Tenant Security Proxy (TSP)_.
25
26
This service is provided as a Docker container, so it is easy to run the proxy on any computer that has Docker
26
27
installed. IronCore Labs hosts the Docker container on a publicly accessible container registry, so you can pull
27
28
the image from there and run it locally.
28
29
29
-
The TSP has a companion Docker container, the _Tenant Security Logdriver_ (LD) that runs alongside it in your environment. It is also hosted on the same publicly accessible container registry.
30
-
31
-
32
30
In addition to the Docker containers, you need a configuration file that specifies how the TSP should communicate
33
31
with the IronCore Labs Configuration Broker and Data Control Platform, which work together to enable the end-to-end
34
32
encryption that keeps all of the tenant KMS configuration information secure. To simplify the process of running
35
33
these examples, we have created a demo vendor and tenants that you can use for the examples; all the necessary
36
34
configuration information is included in the [demo-tsp.conf](demo-tsp.conf) file in this directory.
35
+
37
36
**NOTE:** Normally, the file containing the configuration would be generated by the vendor and loaded into a
38
37
Kubernetes secret or similar mechanism for securely loading the configuration into the docker container. We
39
38
have included this configuration in the repository as a convenience. Also note that these accounts are all
40
39
created in IronCore's staging infrastructure.
41
40
42
-
The following `docker-compose` command will get a TSP+LD running on your computer with the provided configuration:
41
+
Production TSPs will often be accompanied by one or more
Because the purpose of this benchmark is to demonstrate the capabilities of the Tenant Security _Client_, we have chosen to not include
44
+
Logdriver in it. If you wish to modify the Docker Compose file to include Logdriver, be sure to consult its
45
+
[Deployment](https://ironcorelabs.com/docs/saas-shield/tenant-security-logdriver/deployment/) page to learn how to properly configure it
46
+
based on the resources you have available.
47
+
48
+
The following `docker compose` command will get a TSP running on your computer with the provided configuration:
49
+
43
50
```
44
-
docker-compose -f docker-compose.yml up
51
+
dockercompose up
45
52
```
53
+
46
54
This starts the TSP locally listening on port 32804. The benchmark expects to connect to the TSP at that address.
47
55
48
56
To connect with and use the TSP, you need to supply a couple more configuration values:
@@ -66,7 +74,7 @@ There are six tenants defined; their IDs are the following:
66
74
67
75
The last three are similar to the first three, but they have _key leasing_ enabled.
68
76
69
-
By default, the benchmark will use the `tenant-gcp` tenant. If you would like to experiment with a different tenant, just do:
77
+
By default, the benchmark will use the `tenant-gcp-l` tenant. If you would like to experiment with a different tenant, just do:
70
78
71
79
```bash
72
80
export TENANT_ID=<select tenant ID>
@@ -78,6 +86,6 @@ before running the benchmark.
78
86
79
87
Since TSC-java is a library that interacts with a back-end service (TSP), the benchmark results are not always straightforward to interpret. Most API calls in the TSC make a round-trip to the TSP, and the TSP also does some computation. If testing on a single machine, it is good to monitor the CPU/RAM usage of the TSP processes in addition to the Java benchmark process to make sure you aren't resource constrained.
80
88
81
-
In general, operation latency is a function of latency to the TSP + latency to the tenant's KMS (if key-leasing is disabled).
89
+
In general, operation latency is a function of latency to the TSP + latency to the tenant's KMS (if key-leasing is disabled).
82
90
83
-
The TSP's tenant logging mechanism has some tunable limits. By default, a TSP should be able to sustain 500 ops/sec/tenant, with the ability to burst higher for a limited time. The benchmark is using a single tenant, and (depending on your machine and benchmark config) can easily be executing a few thousand ops/sec. If you run a benchmark long enough you will overwhelm the TSP. In a real application, you would scale-out the TSP at this point. See [the TSP documentation](https://ironcorelabs.com/docs/saas-shield/tenant-security-proxy/overview/) for more details.
91
+
The TSP's tenant logging mechanism has some tunable limits. By default, a TSP should be able to sustain 500 ops/sec/tenant, with the ability to burst higher for a limited time. The benchmark is using a single tenant, and (depending on your machine and benchmark config) can easily be executing a few thousand ops/sec. If you run a benchmark long enough you will overwhelm the TSP. In a real application, you would scale-out the TSP at this point. See [the TSP documentation](https://ironcorelabs.com/docs/saas-shield/tenant-security-proxy/deployment/) for more details.
0 commit comments