Login / Password protect ingress?

[bradenwright]

First off, I love the idea of this project. I love ArgoCD and have been looking for something better for our Terraform Deploys. I'm still working through getting the MR part working. Really a great looking tools so far.

I was curious about the details of keeping things secure but still making Burrito accessible both the UI and for the webhook to work. I haven't come across anything about setting up password or a login. So curious about a few things:

Short Term Questions:

1. Can I use basic auth on the ingress
2. If I do so can I expose a path for the webhook, or do I need to do anything to allow the webhook to work if I put auth on the ingress
3. if I do 1 & 2, whats the exposure or what could someone do if they were trying to be malicious.
4. if I don't 1 & 2, whats the exposure or what could someone do if they were trying to be malicious.
5. Are there long term plans to support login / user and rbac for Burrito? or maybe even SSO. I know its still new so more than happy to be patient.

Again thanks so much I'm really excited to finish setting up and playing with burrito

[corrieriluca]

Thanks for giving a try to Burrito!

Here are some answers to your questions:

1. Yes it's recommended to put authn/authz mechanisms in front of Burrito's ingress. Basic auth or IP allow-listing can be enough for your use-case. You can also use oauth2-proxy or a cloud provider service (IAP, Cognito, AD...).
2. In the case of the webhook path (/api/webhook) it must be accessible to your Git provider. If you're using GitHub for example, I suggest you to create a dedicated Ingress, bypassing authentication, for GitHub to send webhook events. Using a webhook secret is highly recommended.
3. If you do 1 & 2 you ensure that only authorized users access the Burrito UI while letting webhook events come from your Git provider, authenticated with a strong webhook secret.
4. If you don't do 1 an attacker could access to private information (contained in Terraform logs) and run Terraform Apply jobs that could have destructive consequences. If you don't do 2, the webhook feature might not work if you're using a SaaS Git provider.
5. Yes, RBAC as well as authentication/authorization mechanisms are planned in the long term, for the moment we are focused on delivering new core features.

Do not hesitate to open a thread in the Discussions section if you need help / debugging with the PR/MR workflow 😉

[LucasMrqes]

Hi, thanks for your message!

We just released version 0.6 of Burrito, and it includes a big update to how Git credentials are managed. This might make it easier for you to set up the MR workflow since you don’t need to mount environment variables to the controller anymore. Instead, you can handle all the credentials in a single secret referenced by the TerraformRepository resource.

You can find more details in the updated docs here: PR/MR Workflow with GitLab.

[bradenwright]

Thanks for the quick replies! I'll looking to the suggestions around ingress. I'll also have to check out 0.6 a little more, when I tried to upgrade without making any changes I was getting some credential errors, but I'll look into it more. I'm interested in using extraApplyArgs and extraPlanArgs to pass in a var-file.

[corrieriluca]

when I tried to upgrade without making any changes I was getting some credential errors

If it's credentials error on the <tenant>/burrito-runner service account (default SA created in every tenant) it's likely the bug mentioned in #512 that will be fixed with #513. We will release a 0.6.1 with this bug fix soon.

In the meanwhile, you can create a "custom" service account in your tenant, it will have the correct RBAC permissions:

In your chart values:

tenants:
  - namespace:
      create: true
      name: "burrito-tenant-1"
    serviceAccounts:
      - name: burrito-tenant-1