Currently VES supports 4 authentication methods:
noAuth --> Works by default. No changes are required.
basicAuth --> Works with/without https healthcheck endpoint (readiness) defined; DCAE healthcheck pass on either case. VES blueprint needs to be overwritten.
certOnly --> Works only when https healthcheck endpoint (readiness) is removed from blueprint; DCAE healthcheck also pass (when readiness is not explicitly defined). VES blueprint needs to be overwritten.
certBasicAuth-->Works with/without https healthcheck endpoint (readiness) defined; DCAE healthcheck pass on either case. VES blueprint needs to be overwritten.
For Dublin, there is created separate jira (DCAEGEN2-1593) for documentation updates to include steps for deploying VESCollector with above authentication enabled.
Readiness support on certOnly mode can be dealt vwith healtchecks disabled. Support for healtchecks is planned as future enhancement (DCAEGEN2-1594).
For enabling TLS, as new application port is involved the service should be redeployed (by modifying the parameters in blueprint), esp when changing from noAuth to basicAuth/certOnly/certBasicAuth. The latter 3 types use 8443 while the noAuth uses 8080. Any changes within basicAuth/certOnly/certBasicAuth can be done through consul update as k8s deployment descriptor (which contains the service definition and healthcheck spec) are still validauthentication methods certBasicAuth. It is possible to run as a option noAuth method, hovewer HTTP it is not supported by default.
High level test cases for auth.method = "
...
When application is setup for TLS and auth.method = "basicAuth", healthcheck endpoint must be using 8443 (change submitted to override and support 8080 for healthcheck is not required nor valid).
To change VES Collector flag to basic.auth and adopt healthhecks to use HTTPS, there is need to change VES blueprints. Steps:
...
certBasicAuth" :
| TC ID | Test Case Name | Test Case |
|---|
DescriptionExecution | Expected Result | Test Status |
|---|
| T01 | Client with correct basic auth and correct certificate | curl -vk --cert cert |
rootCAcrt rootCA.key --pass collector | key.pem -u sample1:sample1 -X POST https:// |
192.168.0.22 correct incorrect | correct certificate | curl -vk - |
u sample1:sample1 -X --cert incorrect_rootCA.crt --key rootCA.key --pass collector | -cert cert.pem --key key.pem -u sample1:sample2 -X POST https:// |
192.168.0.22 with correct without certificate| with correct certificate | curl -vk - |
u sample1:sample1 -X | -cert cert.pem --key key.pem -X POST https:// |
192.168.0.22 without basic auth and without | with correct basic auth and incorrect certificate | curl -vk --cert incorrect.crt --key rootCA.key --pass collector -u sample1:sample1 -X POST https:// |
192.168.0.22 HTTP/1.1 401| connection closed because of bad certificate | |
| T05 | Client |
without basic auth and with correct certificate| with correct basic auth and without certificate | curl -vk - |
-cert rootCA.crt --key rootCA.key --pass collector -192.168.0.22FAIL, 401 incorrect basic auth and with correct certificate| incorrect certificate and incorrect basic auth | curl -vk --cert |
rootCA| incorrect.crt --key rootCA.key --pass collector -u |
sample2 POS curl -vk --cert rootCA.crt --key rootCA.key --pass collector -u sample1:sample2 -X POS https://192.168.0.22192.168.0.22:30417/eventListener/v7 -d @event.json --header "Content-Type: application/json" HTTP/1.1 401| connection closed because of bad authentication | |
| T07 | Client |
with incorrect | without certificate and without basic auth |
and without certificatevk u sample2:sample1 - POS 192.168.0.22FAIL T01
curl -vk --cert rootCA.crt --key rootCA.key --pass collector -u sample1:sample1-X POST https://192.168.0.22:30417/eventListener/v7 -d @event.json "Content-Type: application/json"
T02
T03
...