Pomerium Config with Kubernetes secrets and Gitops (Flux)

What happened?

Hi Guys,

I’m using pomerium and I’ve installed it with our Gitops engine (flux). I’ve also forked the helm chart to replace the secret by a configmap (I did not know about some sensitive data like set_request_headers) and I’ve added another secret with the others properties (IDP settings, shared secrets, cookie…). I’ve also developed a small operator (before yours existed) whose goal is to generate the pomerium config and routes by using 2 CRs.

Now, if I want to go back to a Kubernetes secret instead of using a Configmap I’m faced to a big chicken-and-egg problem and I will try to explain it. We are using external-secrets which is linked to GCP Secret Manager . If we store all the configuration in GCP and let external-secret reconcile it and use the property useExistingSecret in your helm charts we can think that is working. But, if we use our operator or maybe your ingress controller, whose goal is to update the pomerium config we will have an infinite update loop as described below:

FluxCD → reconcile/install → Pomerium
ExternalSecret → fetch GCP secret → Create secret with pomerium config (with no routes)
Operator or Pomerium Ingress Controller → Update the pomerium secret.
ExternalSecret → Recreate the secret (because we have some diffs)

I’m a little bit stuck with the management of this secret May be you have some idea to help me ?

1 Like

Hi,

Our ingress controller does not manipulate the Pomerium secret anymore, so you can safely deploy it with external-secrets managing an existing secret.

You might also have luck with the config.existingSharedSecret option. It allows you to provide selected sensitive data such as idp configuration in an existing secret without having to manage the entire base Pomerium config in said secret.

Hi @travisgroth

Where the routes are stored then because the helm chart still create the secret to store the config ? The ingress controller is a replacement of the pomerium proxy ?

I would like to use the ingress controller but I have one problem. I’m currently using istio ingress gateway as our main gateway to access to our services and I’m a little bit hesitant to have another internet-facing endpoint to reach our applications. Moreover, I know that I can expose the ingress gateway with a clusterIP service and create a virtualservice with istio but when a request come, we will have another network hop before reaching our applications (istio → pomerium ingress → pomerium proxy → app)