Control backend service IAM policy from BackendConfig

[abstrctn]

We can now grant the IAP-Secured Web App User role to individual users on a single backend service.

Currently this needs to be configured manually after the GLBC creates a new backend service; and because they're attached to the with the backend service, anything that causes it to be recreated would cause the permissions to be lost. This is somewhat limiting from a portability standpoint, as the kubernetes manifests aren't sufficient to configure IAP access from scratch.

Having a way to control those permissions from within a BackendConfig seems like a useful extension that would prevent accidental loss and allow for more seamless configuration when creating a new service for the first time.

Would adding something like a members array to the BackendConfig spec make sense for controlling this?

apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: my-backend-config
spec:
  iap:
    enabled: true
    members:
    - user@example.com
    - server@example.gserviceaccount.com

One question here would be how to treat members granted access outside of Kubernetes. My preference would be to have the BackendConfig serve as the canonical access list, meaning changes made outside would get reverted, but that would complicate the change detection trigger for the controller.

[rramkumar1]

@abstrctn I'm curious as to why creating a new backend service would wipe away the IAM role (IAP-Secured Web App User) you are giving to your users?

BackendService has no notion of IAM. Giving this role to your users should be a one-time operation unless there have been fundamental changes to these API's that I am not aware of

[rramkumar1]

@abstrctn ping

[eversC]

I believe what @abstrctn is saying (correct me if I'm wrong), is that they're not using IAM to control IAP access, they're manually adding users to each backend registered on the IAP separately.

I think I'm in the same boat: I have multiple backends registered on a single IAP, with a different set of people I want to give access to for each one. I can't use IAM for that, as it'd mean giving each enabled IAM user access to ALL the backends.

Say I then recreate my k8s cluster, the control lists for each backend are all lost. It also means a manual step when making new services accessible via IAP.

Being able to set a member list on the BackendConfig (seems like the best place to do it..?) would allow for the persistence of the control lists across backend creations/recreations.

[rramkumar1]

@eversC You can add ACL's to individuals GCE Backend Service's? This is news to me...

[eversC]

I'm unsure of the exact term for the control list on backend services... Sorry....

I'll update my previous comment to be more clear in that regard.

We digress..are you clear on what @abstrctn means now?

[rramkumar1]

is that they're not using IAM to control IAP access, they're manually adding users to each backend registered on the IAP separately.

How are you doing this?

[eversC]

Hi @rramkumar1, at the moment we're just adding users via the "info panel" on the right hand side of the console/IAP page.

Role: Cloud IAP > IAP-Secured Web App User

Rest API reference: https://cloud.google.com/iap/docs/reference/rest/

could this be used to apply a policy to a specific backend?

[rramkumar1]

Hi @rramkumar1, at the moment we're just adding users via the "info panel" on the right hand side of the console/IAP page.

Right, but that gives each user permission to all backends

could this be used to apply a policy to a specific backend?

Hmm, the documentation for that looks really ambiguous. I'm not sure that would even work but I could be proven wrong.

@abstrctn Can you please clarify your setup and how you are able to specify policy on specific backends, rather than all of them at once?

[eversC]

Right, but that gives each user permission to all backends

From what I'm experiencing, it only gives each user access to the specific backend, and not to any others.

Is there any other information I can give you that might help?

[rramkumar1]

@eversC Unless I'm completely missing something, I'm not sure that is true.

See https://cloud.google.com/iap/docs/managing-access

Specifically look for the line "All backend services will be secured."

[eversC]

Dare I say it but I think that documentation is incomplete.

The hierarchy of resources I have is:

- All Web Services
    - Backend Services (GCE/GKE)
        - backend1
        - backend2
        - backend3

the 2 bulleted 'tiers' of resources in the section of documentation you referenced is only "All Web Services" and "Backend Services", i.e., only the top 2 tiers.

The documentation also states:

"Resources and Permissions

The Cloud IAP API enables you to apply Cloud IAM permissions to individual resources in a Cloud IAP-secured project. Cloud IAM permissions granted at a certain level apply to all levels underneath it."

^^ this is exactly what I'm seeing. I can set access permission on a specific resource in any of the 3 tiers, and whenever I do so, the permission is applied to everything underneath, but nothing above, that tier (to clarify further, the permission isn't applied to everything else in that tier, e.g. setting permission on backend1 is NOT then applied to backends 2 and 3).

Let me know if any of this does/doesn't make sense. The only other option I can think of is setting a dev environment up that we both have access to.

[rramkumar1]

@eversC I stand corrected. I just took a look at the UI and it looks like it has changed quite substantially. Now as you say, you can apply the policy on individual backends (for some reason I was not seeing this before).

The fact that you can now apply this policy on individual resources was something that was not true when we first implemented the IAP support.

Give me a couple days so I can ask around and see how we can address this.

/kind feature

[eversC]

@rramkumar1 no worries, thanks for persisting with it.

Seems like the functionality on IAP has been added fairly recently; I've been unable to track down exactly when though.

[eversC]

hi @rramkumar1, have you decided how to address this?

[msinton]

+1 I would also really appreciate this feature.

[eversC]

@rramkumar1 ping

[bowei]

We have this on our backlog and will try to figure out when this can be done.

/lifecycle frozen

[acondrat]

+1
This would makes things so much easier for us! Any updates on when this could be available?

[brugz]

I read through this issue a couple times, but can someone check my understanding here: Is recreating a backend simply wiping IAM users from the associated backend when it's being used with IAP? What sort of actions would we expect to recreate those backends? kubectl apply -f?

I'm following up on some possibly related issues internally @ Google and want to verify if this is related to a GKE issue I'm monitoring.

[eversC]

Hi @brugz, yes that's correct, the list of users able to access a specific backend via IAP get wiped when the associated backend is recreated.

What sort of actions would we expect to recreate those backends? kubectl apply -f?

I'm not sure I fully understand the question, but the team I was working with at the time of encountering this was using Helm to create their backends (+ BackendConfig), fwiw

[brugz]

FWIW, I'm tracking this here as well:
https://issuetracker.google.com/133192467

[hadim]

Bump here. Are you considering implementing such a feature?

[Jojoooo1]

Any news on this feature ?

[swetharepakula]

We will not be adding this feature per the decision in the public issue tracker: https://issuetracker.google.com/133192467.

[renaudguerin]

We will not be adding this feature per the decision in the public issue tracker: https://issuetracker.google.com/133192467.

Hi,

In that case, could you please recommend a workable infrastructure-as-code solution to define and apply these IAP-related IAM policies at the Backend resource level ?

This doesn't seem to be available in Config Connector.

The Terraform Google provider team didn't want to help either and pointed back at your team "I would recommend trying to raise an issue against the GCE Ingress implementation". That was before the public issue tracker closed the issue, though.

It seems that the relevant IAM API is here, but none of the declarative tools expose it.

[raj-saxena]

It's unfortunate that this issue still doesn't have a solution after 2 years. We faced the same blocker & solved it by using the Terraform's external data type & calling gcloud to fetch the backend-service by Kubernetes annotation.
Sharing the code here hoping to help someone else:

data "external" "backend_service" {
  for_each = local.services

  program = ["bash", "${path.module}/backend-service-by-k8s-service-name.sh",
    lookup(each.value, "k8s_namespace", "default"), # K8s namespace
    lookup(each.value, "k8s_service", each.key)     # K8s service
  ]
}

# For services, that have backend-service, create IAM policy
resource "google_iap_web_backend_service_iam_binding" "access" {
  for_each = { for k, v in data.external.backend_service : k => v.result.name if contains(keys(v.result), "name") }

  project             = var.project_id
  web_backend_service = each.value
  role                = "roles/iap.httpsResourceAccessor"
  members             = [ ] # members
}

The shell script:

#!/bin/bash

set -o errexit -o nounset -o pipefail

NAMESPACE=$1
SERVICE=$2
read -r FILTER<<EOF
description ~ \"kubernetes.io/service-name\"\:\"$NAMESPACE/$SERVICE\"
EOF

RESULT=$(gcloud compute backend-services list --filter="$FILTER" --format='json(name)' | jq '.[]')

if [[ -z "$RESULT" ]]; then
  echo "{}" # Needs to return a json
else
  echo "$RESULT"
fi

[sosimon]

@raj-saxena thanks for sharing. We are running into the same problem and it seems we are going to have to resort to pretty much your solution. Not ideal :(