. We are now leveraging nix for portable dependency handling. . There are now three types of tests: client, server and end-to-end. . server tests exercise the actual kapow server being tested, while the requests are performed using the test steps. . client tests exercise the actual kapow client being tested, while the requests are served using the test steps. . e2e test exercise the actual kapow program in its dual role of client and server (¡como tiene que ser!). Co-authored-by: Roberto Abdelkader Martínez Pérez <robertomartinezp@gmail.com>
96 lines
3.3 KiB
Gherkin
96 lines
3.3 KiB
Gherkin
#
|
|
# Copyright 2021 Banco Bilbao Vizcaya Argentaria, S.A.
|
|
#
|
|
# Licensed under the Apache License, Version 2.0 (the "License");
|
|
# you may not use this file except in compliance with the License.
|
|
# You may obtain a copy of the License at
|
|
#
|
|
# http://www.apache.org/licenses/LICENSE-2.0
|
|
#
|
|
# Unless required by applicable law or agreed to in writing, software
|
|
# distributed under the License is distributed on an "AS IS" BASIS,
|
|
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
# See the License for the specific language governing permissions and
|
|
# limitations under the License.
|
|
#
|
|
|
|
Feature: Communications with the control interface are secured with mTLS.
|
|
Trust is anchored via certificate pinning.
|
|
The Kapow! server only allows connections from trusted clients.
|
|
The Kapow! clients only establish connections to trusted servers.
|
|
|
|
@server
|
|
Scenario: Reject clients not providing a certificate.
|
|
|
|
Given I have a running Kapow! server
|
|
When I try to connect to the control API without providing a certificate
|
|
Then I get a connection error
|
|
|
|
@server
|
|
Scenario: Reject clients providing an invalid certificate.
|
|
|
|
Given I have a running Kapow! server
|
|
When I try to connect to the control API providing an invalid certificate
|
|
Then I get a connection error
|
|
|
|
@client
|
|
Scenario: Connect to servers providing a valid certificate.
|
|
A valid certificate is the one provided via envvars.
|
|
|
|
Given a test HTTPS server on the control port
|
|
When I run the following command
|
|
"""
|
|
$ kapow route list
|
|
"""
|
|
And the HTTPS server receives a "GET" request to "/routes"
|
|
And the server responds with
|
|
| field | value |
|
|
| status | 200 |
|
|
| headers.Content-Type | application/json |
|
|
| body | [] |
|
|
Then the command exits with "0"
|
|
|
|
@client
|
|
Scenario: Reject servers providing an invalid certificate.
|
|
|
|
Given a test HTTPS server on the control port
|
|
When I run the following command (with invalid certs)
|
|
"""
|
|
$ kapow route list
|
|
"""
|
|
Then the command exits immediately with "1"
|
|
|
|
@server
|
|
Scenario Outline: The control server is accessible through an alternative address
|
|
The automatically generated certificated contains the Alternate Name
|
|
provided via the `--control-reachable-addr` parameter.
|
|
|
|
Given I launch the server with the following extra arguments
|
|
"""
|
|
--control-reachable-addr "<reachable_addr>"
|
|
"""
|
|
When I inspect the automatically generated control server certificate
|
|
Then the extension "Subject Alternative Name" contains "<value>" of type "<type>"
|
|
|
|
Examples:
|
|
| reachable_addr | value | type |
|
|
| localhost:8081 | localhost | DNSName |
|
|
| 127.0.0.1:8081 | 127.0.0.1 | IPAddress |
|
|
| foo.bar:8081 | foo.bar | DNSName |
|
|
| 4.2.2.4:8081 | 4.2.2.4 | IPAddress |
|
|
| [2600::]:8081 | 2600:: | IPAddress |
|
|
|
|
|
|
@e2e
|
|
Scenario: Control server dialog using mTLS
|
|
If the user provides the corresponding certificates to the
|
|
`kapow route` subcommand, the communication should be possible.
|
|
|
|
Given I have a just started Kapow! server
|
|
When I run the following command (setting the control certs environment variables)
|
|
"""
|
|
$ kapow route list
|
|
|
|
"""
|
|
Then the command exits with "0"
|