IV. Test.md

IV. Test

1. Testing CipherSuite Configuration at Different Granularity Levels

Before testing, remove existing configurations and namespaces

yes | istioctl uninstall --purge && \
kubectl delete ns test test1 test2 2>/dev/null; while kubectl get ns test test1 test2 >/dev/null 2>&1; do sleep 1; done

Test scenarios cover the following configurations:
    a. Deploy and verify the operation of cluster-level settings
    b. Deploy and verify the operation of namespace-level settings
    c. Deploy and verify the operation of settings based on labels

a. Deploy and verify the operation of cluster-level settings

Configure cluster-wide settings through meshconfig

yes | istioctl install \
  --set profile=default \
  --set hub=docker.io/boanlab \
  --set tag=cryptoflex \
  --set meshConfig.accessLogFile=/dev/stdout \
  --set meshConfig.enableTracing=true \
  --set meshConfig.meshMTLS.cipherSuites[0]=TLS_AES_256_GCM_SHA384

Deploy a workload to verify the cluster-level settings
As with the previous tests, create a dedicated test namespace, enable Istio injection, and deploy the test workload

kubectl create ns test && \
./cryptoflex-test/prerequisite/kubernetes/istio/enable-istio-injection.sh test && \
kubectl apply -f cryptoflex-test/deployment/ -n test

Inspect the logs of the TLS Inspector in the test workload

kubectl logs -n test deployments/echo-server -c tls-inspector

It can be confirmed that AES_256_GCM_SHA384 is specified as set

b. Deploy and verify the operation of namespace-level settings

Similarly, create a test namespace and enable Istio injection

kubectl create ns test1 && \
./cryptoflex-test/prerequisite/kubernetes/istio/enable-istio-injection.sh test1

Set annotations on the namespace using the kubectl annotate command
Next, deploy the test workload

kubectl annotate --overwrite namespace test1 cipherSuites=TLS_AES_128_GCM_SHA256 && \
kubectl apply -f cryptoflex-test/deployment/ -n test1

Inspect the logs of the TLS Inspector in the test workload

kubectl logs -n test1 deployments/echo-server -c tls-inspector

This confirms AES_128_GCM_SHA256 is specified as set

c. Deploy and verify the operation of settings based on labels

As in the previous examples, proceed with creating a test namespace, activating Istio injection, and deploying the test workload

kubectl create ns test2 && \
./cryptoflex-test/prerequisite/kubernetes/istio/enable-istio-injection.sh test2 && \
kubectl apply -f cryptoflex-test/deployment/ -n test2

Modify the annotation of the Pod using the kubectl annotate command to specify settings based on labels

kubectl annotate pods -n test2 -l app=echo-server --overwrite cipherSuites="TLS_CHACHA20_POLY1305_SHA256"

Inspect the logs of the TLS Inspector for the test workload

kubectl logs -n test2 deployments/echo-server -c tls-inspector

Similarly, the specified CHACHA20_POLY1305_SHA256 is successfully applied to the label unit as well

Use the command below to check the CipherSuites of the entire test workload with the applied granular settings

for ns in test test1 test2; do echo "=== $ns ==="; kubectl logs -n $ns deployment/echo-server -c tls-inspector --tail=3; done

As it appears, it verifies the settings specified at the cluster level, namespace level, and label level

2. Verify Configuration Priority

Before testing, remove existing configurations and namespaces

yes | istioctl uninstall --purge && \
kubectl delete ns test test1 test2 2>/dev/null; while kubectl get ns test test1 test2  >/dev/null 2>&1; do sleep 1; done

Specify cluster-level settings through meshconfig

yes | istioctl install \
  --set profile=default \
  --set hub=docker.io/boanlab \
  --set tag=cryptoflex \
  --set meshConfig.accessLogFile=/dev/stdout \
  --set meshConfig.enableTracing=true \
  --set meshConfig.meshMTLS.cipherSuites[0]=TLS_AES_256_GCM_SHA384

Deploy a workload to verify the cluster-level settings
As with the previous tests, create a namespace, enable Istio injection, and deploy the test workload

kubectl create ns test && \
./cryptoflex-test/prerequisite/kubernetes/istio/enable-istio-injection.sh test && \
kubectl apply -f cryptoflex-test/deployment/ -n test

Create a new namespace (test1) and deploy a test workload consisting of a pair of echo-server and echo-client

kubectl create ns test1 && \
./cryptoflex-test/prerequisite/kubernetes/istio/enable-istio-injection.sh test1 && \
kubectl apply -f cryptoflex-test/deployment/ -n test1

Check the CipherSuite logs for each workload

kubectl logs -n test deployments/echo-server -c tls-inspector --tail=5
kubectl logs -n test deployments/echo-server2 -c tls-inspector --tail=5
kubectl logs -n test1 deployments/echo-server -c tls-inspector --tail=5

With cluster-level configuration in place, all workloads have the same CipherSuite configuration

Set the CipherSuite by specifying annotations in the namespace and verify it

kubectl annotate --overwrite namespace test1 cipherSuites=TLS_AES_128_GCM_SHA256 && \
kubectl rollout restart -n test1 deployment echo-server echo-client

Check the CipherSuite settings for each workload again

kubectl logs -n test deployments/echo-server -c tls-inspector --tail=5
kubectl logs -n test deployments/echo-server2 -c tls-inspector --tail=5
kubectl logs -n test1 deployments/echo-server -c tls-inspector --tail=5

As configured, the CipherSuite setting for the test1 namespace is updated

kubectl annotate pods -n test -l app=echo-server --overwrite cipherSuites="TLS_CHACHA20_POLY1305_SHA256"

Check the CipherSuite settings for each workload again

kubectl logs -n test deployments/echo-server -c tls-inspector --tail=5
kubectl logs -n test deployments/echo-server2 -c tls-inspector --tail=5
kubectl logs -n test1 deployments/echo-server -c tls-inspector --tail=5

The namespace settings have been redefined over the cluster settings, and the label settings have also been redefined, confirming that each setting has its own priority

3. Testing Supported CipherSuite

In Istio based on Vanilla Envoy, only the TLS_AES_128_GCM_SHA256 CipherSuite is available.
Additionally, if a different TLSv1.3 CipherSuite is specified, an error will occur

This section, we will directly verify this and test the method for specifying the CipherSuite

Before testing, remove existing configurations and namespaces

yes | istioctl uninstall --purge && \
kubectl delete ns test test1 test2 2>/dev/null; while kubectl get ns test test1 test2 >/dev/null 2>&1; do sleep 1; done

Specify the meshconfig without a CipherSuite and install Istio

yes | istioctl install \
  --set profile=default \
  --set hub=docker.io/boanlab \
  --set tag=cryptoflex \
  --set meshConfig.accessLogFile=/dev/stdout \
  --set meshConfig.enableTracing=true

Create a test namespace (test) and enable Istio injection, then deploy workloads to test the CipherSuite specification
Set the encryption library of the test workload to BoringSSL

kubectl create ns test && \
./cryptoflex-test/prerequisite/kubernetes/istio/enable-istio-injection.sh test && \
kubectl apply -f cryptoflex-test/deployment/ -n test && \
kubectl wait --for=condition=ready pod -l app=echo-server -n test --timeout=100s && \
cryptoflex -n test deployments/echo-server bssl

Since the CipherSuite is not specified at the cluster level, it is fixed to AES_128_GCM_SHA256

Now, test by specifying the TLSv1.3 CipherSuite as CHACHA20_POLY1305_SHA256

HUB=<HUB> TAG=<TAG> ./cryptoflex-test/script/build_and_test_istio.sh

Create another namespace (test1) and add the test workload

kubectl create ns test1 && \
./cryptoflex-test/prerequisite/kubernetes/istio/enable-istio-injection.sh test1 && \
kubectl apply -f cryptoflex-test/deployment/ -n test1

Check the Istiod log

kubectl logs -n istio-system deployments/istiod

Check the Istio-Proxy log

kubectl logs -n test1 deployments/echo-server -c istio-proxy

As demonstrated, this confirms specifying a CipherSuite for TLSv1.3 is not possible in Vanilla Envoy

4. Dynamic Transition of CipherSuites

Applying a new CipherSuite to a active workload allows for dynamic changes without interrupting the session

Before testing, remove existing configurations and namespaces

yes | istioctl uninstall --purge && \
kubectl delete ns test test1 test2 2>/dev/null; while kubectl get ns test test1 test2 >/dev/null 2>&1; do sleep 1; done

Specify cluster-level settings through meshconfig

yes | istioctl install \
  --set profile=default \
  --set hub=docker.io/boanlab \
  --set tag=cryptoflex \
  --set meshConfig.accessLogFile=/dev/stdout \
  --set meshConfig.enableTracing=true \
  --set 'meshConfig.meshMTLS.minProtocolVersion=TLSV1_3' \
  --set 'meshConfig.meshMTLS.cipherSuites[0]=TLS_CHACHA20_POLY1305_SHA256'

Create a test namespace (test) and enable Istio injection, then deploy workloads to test the Dynamic transition

kubectl create ns test && \
./cryptoflex-test/prerequisite/kubernetes/istio/enable-istio-injection.sh test && \
kubectl apply -f cryptoflex-test/deployment/ -n test

Existing session of the workload uses the TLS_CHACHA20_POLY1305_SHA256 CipherSuite

kubectl logs -n test deployments/echo-server -c tls-inspector -f

Specify a different CipherSuite from the existing one for the test workload through annotations

kubectl annotate --overwrite namespace test chiperSuites=TLS_AES_128_GCM_SHA256

This confirms the transition to TLS_AES_128_GCM_SHA256 occurs as specified

kubectl annotate --overwrite namespace test chiperSuites=TLS_AES_128_GCM_SHA256

5. Cryptography Library Dynamic Transition

Section 5 discusses the method for dynamic switching of encryption libraries
The encryption library is switched without interrupting the active workload through the previously installed Cryptoflex

Before testing, remove existing configurations and namespaces

yes | istioctl uninstall --purge && \
kubectl delete ns test test1 test2 2>/dev/null; while kubectl get ns test test1 test2 >/dev/null 2>&1; do sleep 1; done

Perform the Istio build as done in Section 3.3, and deploy the test workload

HUB=<HUB> TAG=<TAG> ./cryptoflex-test/script/build_and_test_istio.sh && \

Check the CipherSuite currently in use by the test workload

kubectl logs -n test deployments/echo-server -c tls-inspector

[스크린샷] 테스트 워크로드의 CipherSuite 재확인 (아직 없음)

This confirms no further communication occurs after the switch

Check the istio-proxy logs of the test workload to identify the reason for the communication interruption

kubectl logs -n test deployments/echo-server -c istio-proxy

[스크린샷] 테스트 워크로드의 istio-proxy 컨테이너 확인 (아직 없음)

This confirms an error occurred due to the unsupported CipherSuite, as mentioned above
BoringSSL does not support the specification of CipherSuites other than AES_128_GCM_SHA256 for TLS 1.3, so the currently specified CipherSuite cannot be applied in BoringSSL

Use the cryptoflex command to switch the encryption library of the current workload back to OpenSSL

cryptoflex -n test deployments/echo-server ossl

Check the CipherSuite of the test workload again

kubectl logs -n test deployments/echo-server -c tls-inspector

[스크린샷] 테스트 워크로드의 CipherSuite 재확인 (아직 없음)

This confirms communication is functioning normally

Due to the unsupported CipherSuite error caused by the library switch, communication was not possible.
However, after switching back, it has been confirmed that normal communication is occurring.