Error initializing configuration '/etc/envoy/envoy.yaml': Invalid path: /etc/envoy/envoy.yaml about aqua-helm HOT 13 CLOSED

Hey,
Thanks for reporting, we will investigate and update

from aqua-helm.

@ericgomes56 I noticed that a PR #152 was merged about 20+ hours ago from KoppulaRajender for this very problem. I pulled down the new chart and reran my code and envoy came up with no problem. His PR appears to fix my problem with envoy.

from aqua-helm.

I just ran into this same issue. Trying to figure out what is causing the issue in the config map template.

from aqua-helm.

@FeedTheDarkside @mitchellmaler We were able to reproduce the issue when we failed to provide the envoy.certsSecretName value along with envoy.enabled=true

[2020-12-09 15:49:29.341][8][critical][main] [source/server/server.cc:101] error initializing configuration '/etc/envoy/envoy.yaml': Invalid path: /etc/ssl/envoy/tls.crt

I have also fixed some typos in the https://github.com/aquasecurity/aqua-helm/blob/master/server/README.md#advanced-configuration

Please give it a try again and let us know if you still see any errors.

from aqua-helm.

I am still able to recreate the issue where the envoy ConfigMap is missing the data.

$ helm template aqua-helm/server -s templates/envoy-config.yaml --set imageCredentials.create=false --set envoy.enabled=true
---
# Source: server/templates/envoy-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: RELEASE-NAME-envoy-conf
  labels:
    app: RELEASE-NAME-envoy
    chart: "server-5.3.0"
    release: "RELEASE-NAME"
    heritage: "Helm"
data:

$ 

Though I was able to figure out the issue. In the ConfigMap you have {{- range $key, $value := .Values.envoy.files }} to loop through the files however in the values you have envoy.yaml: |. The issue is helm is interpreting that as a yaml object like

envoy:
  yaml: |

I was able to fix is by quoting the file name (key) in the values.yml file and it rendered it.

  files:
    ## refs:
    ## - https://www.envoyproxy.io/docs/envoy/latest/start/start#quick-start-to-run-simple-example
    ## - https://raw.githubusercontent.com/envoyproxy/envoy/master/configs/google_com_proxy.v2.yaml
    "envoy.yaml": |

$ helm template . -s templates/envoy-config.yaml --set imageCredentials.create=false --set envoy.enabled=true
---
# Source: server/templates/envoy-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: RELEASE-NAME-envoy-conf
  labels:
    app: RELEASE-NAME-envoy
    chart: "server-5.3.0"
    release: "RELEASE-NAME"
    heritage: "Helm"
data:
  envoy.yaml: |-
    static_resources:
      listeners:
      - address:
          socket_address:
            address: 0.0.0.0
            port_value: 8443
        filter_chains:
        - filters:
          - name: envoy.filters.network.http_connection_manager
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
              stream_idle_timeout: 0s
              drain_timeout: 20s
              access_log:
              - name: envoy.access_loggers.file
...

from aqua-helm.

Just opened a PR to fix this.

from aqua-helm.

@mitchellmaler when enabling Envoy in the server/values.yaml, did you create the certificate and pass that into a Kubernetes Secret? That Kubernetes Secret is then referenced on line 249.

from aqua-helm.

Yes in my deployment I am creating a secret with the tls certificate values in place and referencing it so it can be mounted. The error I am seeing is that the envoy.yaml config file is invalid since the configmap is empty. The certificate secret exists and is mounted to the pod as expected. The fix for the config is to make sure helm renders it using the quoted file name as the key.

from aqua-helm.

@mitchellmaler thanks for following up. Previously, we had an issue where the Envoy configuration that was once provided was not consistent with the certificate and key names. Part 1 had us creating certificates and keys with, ‘mydomain.com.crt’, and ‘mydomian.com.key’, but Part 2 has us using ‘tls.crt’ and ‘tls.key’. 

The configMap is expecting us to have ‘tls.crt’ and ‘tls.key’, so Aqua would error out if using ‘mydomain.com.crt’, and ‘mydomian.com.key’.

There was also a dash missing from ‘-from-file’ (--from-file) for the certificate secret.

I was able to resolve the behavior on my end when I last tested this a week or two ago.

from aqua-helm.

Yes in my deployment I am creating a secret with the tls certificate values in place and referencing it so it can be mounted. The error I am seeing is that the envoy.yaml config file is invalid since the configmap is empty. The certificate secret exists and is mounted to the pod as expected. The fix for the config is to make sure helm renders it using the quoted file name as the key.

I second this. We are mounting the TLS certificates as a secret and referencing in the values.yaml file on line 249 for value, certsSecretName. We also confirmed that the secret does in fact exist, but still leaves the data section blank in the configMap.

from aqua-helm.

@mitchellmaler thanks for following up. Previously, we had an issue where the Envoy configuration that was once provided was not consistent with the certificate and key names. Part 1 had us creating certificates and keys with, ‘mydomain.com.crt’, and ‘mydomian.com.key’, but Part 2 has us using ‘tls.crt’ and ‘tls.key’. 

The configMap is expecting us to have ‘tls.crt’ and ‘tls.key’, so Aqua would error out if using ‘mydomain.com.crt’, and ‘mydomian.com.key’.

There was also a dash missing from ‘-from-file’ (--from-file) for the certificate secret.

I was able to resolve the behavior on my end when I last tested this a week or two ago.

@ericgomes56 in our case, we are using the tls.crt and tls.key keys for the TLS secret. In our situation, we setup the secret using Terraforms Kubernetes provider as shown below:

`resource "kubernetes_secret" "aquaServerTls" {
metadata {
name = var.kubernetes_secret_aquaServerTls
namespace = kubernetes_namespace.aqua.metadata.0.name
}

data = {
"tls.crt" = file(var.kubernetes_secret_aquaServerTls_crtFilePath)
"tls.key" = file(var.kubernetes_secret_aquaServerTls_keyFilePath)
}

depends_on = [
module.gke,
kubernetes_namespace.aqua,
]
}`

As part of troubleshooting, I also attempted to do this using the kubectl commands and commenting out the terraform code.

from aqua-helm.

@FeedTheDarkside walking through the aqua-helm deployment on a GKE cluster, all of the container workloads are instantiated successfully and Envoy is providing 200 status codes for the health check after the SSL handshake.

from aqua-helm.

@FeedTheDarkside thanks for your input.
Happy to hear the issue is solved. closing this issue.

from aqua-helm.