Enable Control Plane Security

Kubernetes NetworkPolicies, TLS/mTLS and optionally Istio can be used to protect components of the control plane. Specifically, traffic to connectors that run as part of the control plane must be secured. Follow this page to enable control plane security.

Ingress traffic policy

The installation of Fybrik applies a Kubernetes NetworkPolicy resource to the fybrik-system namespace. This resource ensures that ingress traffic to connectors is only allowed from workloads that run in the fybrik-system namespace and thus disallow access to connectors from other namespaces or external parties.

The NetworkPolicy is always created. However, your Kubernetes cluster must have a Network Plugin with NetworkPolicy support. Otherwise, NetworkPolicy resources will have no affect. While most Kubernetes distributions include a network plugin that enfoces network policies, some like Kind do not and require you to install a separate network plugin instead.

Transport Layer Security (TLS)

Configure Fybrik to use TLS

Fybrik can be configured to protect traffic between the manager and connectors by using TLS. In addition, mutual TLS authentication is possible too.

In the TLS mode, the connectors (aka the servers) should have their certificates available to provide them to the manager (aka client) in the TLS protocol handshake process. In mutual TLS mode, both the manager and connector should have their certificates available. If private Certificate Authorities (CA) is used then its credentials should be installed too.

Generating TLS certificates and keys

For development and testing the TLS certificates and certificate keys can be generated using openSSL library. For more information on the process please refer to online documentation such as this useful tutorial.

Cert-manager can also be used to automatically generate and renew the TLS certificate using its Certificate resource. The following is an example of a Certificate resource for the opa-connector where a tls type secret named tls-opa-connector-certs containing the certificate and certificate key is automatically created by the cert-manager. The issuerRef field points to a cert-manager resource name Issuer that holds the information about the CA that signs the certificate.

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: opa-connector-cert
  namespace: fybrik-system
spec:
  dnsNames:
  - opa-connector
  issuerRef:
    kind: Issuer
    name: ca-issuer
  secretName: tls-opa-connector-certs

Adding TLS Secrets

The manager/connectors certificates are kept in Kubernetes secret of type tls which are mounted to the manager/connectors pods in fybrik deployment.

For each component copy its certificate into a file named tls.crt. Copy the certificate key into a file named tls.key. (the files names used in this example can be changed)

Use kubectl with the tls secret type to create the secrets.

kubectl -n fybrik-system create secret tls tls-opa-connector-certs \
  --cert=tls.crt \
  --key=tls.key

If cert-manager is used to manage the certificates then the secret is automatically created as shown above.

Using a Private CA Signed Certificate

If you are using a private CA, Fybrik requires a copy of the CA certificate which is used by connector/manager to validate the connection to the manager/connectors. If no private CA certificates are provided then the system CA certificates are used, otherwise the private CA certificates replace the system CA certificates.

For each component copy the CA certificate into a file and use kubectl to create or patch the tls-ca secret in the fybrik-system namespace. In the following example ca.crt file is used to create the secret:

kubectl -n fybrik-system create secret generic tls-ca \
  --from-file=ca.crt=./ca.crt

Note that Fybrik expects that the keys of the CA certificates in the secret will end with .crt suffix.

Here is an example of a self-signed issuer managed by cert-manager. The secret tls-ca that holds the CA certificate is created and automatically renewed by cert-manager.

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: ca-issuer-self-signed
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: ca-issuer
  namespace: fybrik-system
spec:
  ca:
    secretName: tls-ca
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: ca-certificate
  namespace: fybrik-system
spec:
  isCA: true
  commonName: fybrik
  secretName: tls-ca
  issuerRef:
    name: ca-issuer-self-signed
    kind: ClusterIssuer
    group: cert-manager.io

Update Values.yaml file

To use TLS the infomation about the secrets above should be inserted to the fields in values.yaml file upon Fybrik deployment using helm.

Here is an example of the tls related fields in the opa-connector section that are filled based on the secrets created above:

opaConnector:
  tls:
    # MinVersion contains the minimum TLS version that is acceptable.
    # If not provided, minimal supported TLS protocol is taken as the minimum.
    minVersion: v13
    # Specifies whether the opa connector communication should use tls.
    use_tls: true
    # Specifies whether the opa connector communication should use mutual tls.
    use_mtls: true
    # Relavent if the connection between the manager and the connectors
    # uses tls.
    certs:
      # Name of kubernetes tls secret that holds opa-connector certificates.
      # The secret should be of `kubernetes.io/tls` type.
      # Relavent if tls is used.
      certSecretName: "tls-opa-connector-certs"
      # Name of kubernetes secret that holds the certificate authority (CA) certificates
      # which are used by opa-connector to validate the connection to the manager if
      # mtls is enabled.
      # The CA certificates key in the secret should have `.crt` suffix.
      # The provided certificates replaces the certificates in the system CA certificate store.
      # If the secret is not provided then the CA certificates are taken from the system
      # CA certificate store, for example `/etc/ssl/certs/`.
      cacertSecretName: "tls-ca"

Using Istio

Alternatively, if Istio is installed in the cluster then you can use automatic mutual TLS to encrypt the traffic to the connectors.

Follow these steps to enable mutual TLS:

• Ensure that Istio 1.6 or above is installed.

• Enable Istio sidecar injection in the fybrik-system namespace:

  kubectl label namespace fybrik-system istio-injection=enabled
  

  - Create Istio PeerAuthentication resource to enable mutual TLS between containers with Istio sidecars:

  cat << EOF | kubectl apply -f -
  apiVersion: "security.istio.io/v1beta1"
  kind: "PeerAuthentication"
  metadata:
  name: "premissive-mtls-in-control-plane"
  namespace: fybrik-system
  spec:
    mtls:
      mode: PERMISSIVE    
  EOF
  

  - Create Istio Sidecar resource to allow any egress traffic from the control plane containers:

  cat << EOF | kubectl apply -f -
  apiVersion: networking.istio.io/v1alpha3
  kind: Sidecar
  metadata:
  name: sidecar-default
  namespace: fybrik-system
  spec:
  egress:
  - hosts:
      - "*/*"
  outboundTrafficPolicy:
      mode: ALLOW_ANY
  EOF
  

  - Restart the control plane pods:

  kubectl delete pod --all -n fybrik-system