Infrastructure Testing

This section describe how to test each individual service that compose the Keyless Stack

Testing the correct deployment of Keyless service can be done with the following methods.

Testing Service Manually

Circuit Storage

To test the correct configuration of Circuit Storage it is possible to use the following commands to upload a file from your local environment to the storage.

If Circuit Storage is exposed outside the cluster ( meaning it has been deployed with publicRoute: true ) you can issue the following command to test the service

$ curl --location --request POST '<host>.<domain>:<port which the ingress controller is listening on>/api/v1/circuits/qqF0FC59D87AA45dC15DA1F8A3377A17E423E1F0833343A5865D5E365133090A/qqqB155F07FA55A74FDB3C244B600D5E727EC0982392B89EEDF72DB37A346235/ad000008374B155F07FA55A7000000106F54E35F5FC8C87BF8E4691E9AA98CB8/a4aqa107D779ABDEA0CC5DEF5623F1BB2691D49AFD0A7DDBB6FB0FF3CF0B00101D75AE93C21C3' --form 'pipelineId="pipeline_1"' --form 'blob=@"/home/$USER/<a test file>.txt"'

If Circuit Storage is not exposed with an Ingress object or it is not possible to reach it directly from outside the cluster you can issue a port-forward command so that the Circuit Storage service is exposed on localhost:

$ kubectl port-forward service/circuit-storage-keylessd -n <namespace> 8080:8080

Then it is possible to issue the following command from your local machine to upload a test file

$ curl --location --request POST 'localhost:8080/api/v1/circuits/qqF0FC59D87AA45dC15DA1F8A3377A17E423E1F0833343A5865D5E365133090A/qqqB155F07FA55A74FDB3C244B600D5E727EC0982392B89EEDF72DB37A346235/ad000008374B155F07FA55A7000000106F54E35F5FC8C87BF8E4691E9AA98CB8/a4aqa107D779ABDEA0CC5DEF5623F1BB2691D49AFD0A7DDBB6FB0FF3CF0B00101D75AE93C21C3' --form 'pipelineId="pipeline_1"' --form 'blob=@"/home/$USER/<a test file>.txt"'

Keyless Node

It is possible to test Keyless Node, running a dedicated docker testing container as shown below:

docker run -it -e KL_API_KEY="<your_sdk_key>" -e KL_HOSTNAME_PORT="<fqdn_of_node>:<port>" quay.io/keyless_technologies/kl-node-test:v2.2.3_int

As the docker is hosted on our quay.io registry make sure to be authenticated to it before running the command.

Operations API

To test the correct configuration of Operations API it is possible to use the following commands to upload a file from your local environment to the storage.

If Operations API is exposed outside the cluster ( meaning it has been deployed with publicRoute: true ) you can issue the following command to test the service:

curl -H "X-Api-Key:<you-sdk-key>" -vv http://<host>.<domain>:<port which the ingress controller is listening on>/v2/operations/<operation-id>

If Operations API is not exposed with an Ingress object or it is not possible to reach it directly from outside the cluster you can issue a port-forward command so that the Circuit Storage service is exposed on localhost:

kubectl port-forward service/operations-api-keylessd -n <namespace> 8080:8080

Then it is possible to issue the following command to read an operation-id, given that it is available in the database:

curl -H "X-Api-Key:<you-sdk-key>" -vv http://localhost:8080/v2/operations/<operation-id>

Testing Services Automatically

Starting from release 0.1.3 it is possible to test Keyless deployment automatically, using helm testing feature as show below

After deploying the Keyless service stack successfully ( please refer to this page to know how to do so) it is sufficient to invoke the following command

# with 'keylessd' as the release name
helm test keylessd --logs 

The above command will trigger individual test pods, one per each service.

It is also possible to adjust test configurations to fit customer's needs, in the test section of each service in values.yaml, as shown below:

keylessd:
  circuit-storage:
    ...
    test:
      image: postman/newman
      resources: {}
  operations-api:
    ...
    test:
      image: postman/newman
      resources: {}
  node-persistence:
    ...
    test:
      image: postman/newman
      resources: {}
  node:
    ...
    # The following variables are used to test the deployment
    # running `helm test <release-name>`
    test:
      # -- Name of the docker containing the test tool
      image: quay.io/keyless_technologies/kl-node-test:v2.2.3_int
      # -- Hostname endpoint of the Node (FQDN)
      hostname: ""
      # -- Test suit is shipped with 2 certificates
      # /ca/rootCA.crt is a test certifificate for local development
      # keylessCA.crt is used for client testing purposes, please use this one if in doubt
      cert: "/ca/rootCA.crt"
      # -- Api key available in the database
      apiKey: ""
      # -- Port where the service is expected to be exposed
      # If test is executed with hostname = fqdn it is the port
      # the cluster exposes as part of the external endpoint
      # probably 443
      port: ""
      resources: {}

Configuring Circuit Storage, Operations API and Node Persitence test

Circuit Storage, Operations API and Node Persistence services have a similar setup:

Tests for these services need a container with Postman so the default one from Docker Hub is set as default. It is still possible to change the image ( for example if you have an internal Postman image or if Docker Hub registy cannot be exposed internally )

In any case tests are executed from within the Kubernetes Cluster.

Configuring Keylessd Node test

Node tests are instead conducted from a proprietary container image. This test simulates a client connecting to the node from outside the cluster.

hostname: It is possible to specify the FQDN of the node ( i.e. the DNS record the node will be exposed outside the cluster, given that the endpoint is reachable)

cert: make sure the value is set to keylessCA.crt as this certificate is generated and trusted by the internal CA of Keyless.

apiKey: this is the same API Key we release to customers.

port: if the service is exposed externally the traffic flows from the internet towards the Ingress Controller which usually exposes his services with an https endpoint, so in most cases this port is 443.

Resources

For any service it is possible to limit the resources used by the test pod specifying them as shown below:

resources:
  ## -- Limits
  limits:
    cpu: 1000m
    memory: 1024Mi
  ## -- Requests
  requests:
    cpu: 800m
    memory: 1024Mi