Dark-Alex-17/kapow
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

test(spec): Control Server API secured via cross-pinning mTLS

Browse Source 
. 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>
This commit is contained in:
pancho horrillo
2021-03-12 17:02:42 +01:00
parent b7b55d2f3b
commit ab50721f69
17 changed files with 1587 additions and 92 deletions
Download Patch File Download Diff File Expand all files Collapse all files
spec/test/features/control/mtls.feature
+95
View File
@@ -0,0 +1,95 @@
#
# 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"