The GCP project crlite-beta has a Kubernetes pod which needs to be able to write its results to the Kinto settings-writer endpoint. In bug 1513619 we constructed a Kinto account for this service, but now we need to permit the firewall access.

This would be nice to get done by December.

:jcj, would you provide us with a static IP address that kinto-writer can whitelist?

Thanks.

I will figure out the NAT gateway mechanism for GKE as soon as I can next week. Thanks!

Julien,

Here's needinfo so cloudops can see that I'm not actually sneaking this past you as part of a secret plan to subvert kinto with crlite. Previous RRA: https://docs.google.com/document/d/1R7-A6VlLfAyYPxa3Oxt31P_qsoVYp24yfUEvyIbNkEk/edit#

That said, I think it reasonable and rational to discuss what it would look like to deploy to infra to prod, as we're approaching that general time. Whether there should be a prod environment with access to settings-writer.prod vs a staging environment with settings-writer.stage, how to sync Firestore in that case (since it takes several months to download CT at present) and overall how to maintain ops discipline for this, given that the developer isn't ops. Perhaps that should be its own bug.

Indeed the right approach here is to have crlite-beta operated in cloudops prod. Kinto-writer is sensitive enough that we don't want to let 3rd party apps not managed by cloudops access it directly.

Julien,

We're approaching deployment by cloudops for a prod environment. I do want to ask though - is it feasible for an engineer-controlled staging env to have access to the staging kinto-writer?

Discussed in https://github.com/mozilla/crlite/issues/88 and closed to await a CloudOps staging deployment