This message was deleted.

Hi! glad you liked the talk! We're still fairly early on, so a lot of features are still to be baked.

If I understood your machinery correctly your python platfrom CLI only operates on the local definitions in the git repo of a particular service (or do you even run a mono repo strategy?).

yupp only local definitions within the git repo. We do have a monorepo, so each service lives within the same repo in a different foler.

Afterwards the GitLab pipeline takes care of the heavy lifting and triggers the actual deployments. As you support multiple deployment targets, how do you handle authentication towards these different targets?

This is one of those things that's still under construction. Gitlab CI variables can be under a specific "environment", so the AWS key that accesses our prod account is locked within a gitlab environment that regular developers do not have access to. So, our production branch and production jobs use the production environment scopes. The pangea.yaml templates create a separate pipeline job to run within that environment that deploys a service to our production target

Are there just GitLab CI variables per cluster or something along those lines?

That is correct, and they're diced up based on their environment, so one environment cannot access another environment's secrets (kind of/there are global secrets that are used everywhere, but besides the point right now)

Do you have any tenancy baked into your machinery from the secret/cluster access side

Not sure I understood this, is this related to secrets a service needs to operate?

@Akshay Dongaonkar - sorry for not being 100% clear with my last question. I think my questions regarding multi-tenancy is somehow answered via your statement above:

so the AWS key that accesses our prod account is locked within a gitlab environment that regular developers do not have access to.

Do I understand your setup correctly according to the following desc.: their are certain people on your team that have access to the GitLab production environment (from a CI perspective) and review everything that is merged onto the production branch? So developers or project teams are not able to deploy towards production own their own? What I'm trying to stress here is the point that we thought about similar setups but ultimately always came to the point where a developer simply could add an

echo $MY_SUPER_SECRET_VAR

to a pipeline and get secrets he has otherwise no access to on the CI side. Without a well-thought-out multi-tenancy concept these secrets often have elevated privileges that need special protection.

@Daniel Haß yes exactly. We have codeowner guards on code that gets into the production branch. In our case our devs can absolutely do the

echo $MY_SECRET_VAR

in the dev environment but they already have access to those secrets