Make it possible to configure secure access to Envoy admin endpoint

[nezdolik]

Description:
Make configurable access policy to Envoy admin endpoint a first class citizen in Gateway Api. E.g. Envoy admin exposes both read and write endpoints and Envoy Gateway operators may want to restrict access to write endpoints with auth.

[optional Relevant Links:]
Parent Envoy issue: envoyproxy/envoy#2763

[arkodg]

@nezdolik what is the UX you are looking for here ?
currently the admin endpoint is only available on localhost so only someone who has access to envoy-gateway-system can access this

[nezdolik]

@arkodg for the case when bunch of teams have access to localhost/namespace/cluster, so we could let all those teams have access to read only endpoints and only the team that operates the gateway write+read access.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days.

[ira-gordin-sap]

Hi, what happens with this issue?

[liorokman]

If you enable the Backends extension API (see https://gateway.envoyproxy.io/latest/tasks/traffic/backend/ ) then you can create a backend that looks like this:

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: Backend
metadata:
  name: admin
  namespace: default
spec:
  endpoints:
  - ip:
      address: 127.0.0.1
      port: 19000

Once you have this backend available, you can create a standard HTTPRoute and protect it with a SecurityPolicy to allow access to it. All the security features available in Envoy Gateway are at your disposal in this way.

For example, add the following to the quickstart configuration to expose the admin port on the envoy proxy:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: admin
  namespace: default
spec:
  hostnames:
  - admin.local
  parentRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: eg
  rules:
  - backendRefs:
    - group: gateway.envoyproxy.io
      kind: Backend
      name: admin
    matches:
    - path:
        type: PathPrefix
        value: /

[zirain]

If you enable the Backends extension API (see https://gateway.envoyproxy.io/latest/tasks/traffic/backend/ ) then you can create a backend that looks like this:

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: Backend
metadata:
  name: admin
  namespace: default
spec:
  endpoints:
  - ip:
      address: 127.0.0.1
      port: 19000

Once you have this backend available, you can create a standard HTTPRoute and protect it with a SecurityPolicy to allow access to it. All the security features available in Envoy Gateway are at your disposal in this way.

For example, add the following to the quickstart configuration to expose the admin port on the envoy proxy:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: admin
  namespace: default
spec:
  hostnames:
  - admin.local
  parentRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: eg
  rules:
  - backendRefs:
    - group: gateway.envoyproxy.io
      kind: Backend
      name: admin
    matches:
    - path:
        type: PathPrefix
        value: /

this's a good use case for Backend, @liorokman should we add it to doc site?

[liorokman]

@zirain

this's a good use case for Backend, @liorokman should we add it to doc site?

Upon further reflection, I think that the fact that this works is a bug.

There are two issues here:

1. If the envoy-proxy deployment was scaled to more than one pod then each time this route is accessed might end up at a different pod and return different results. Secure access to the Envoy Proxy console should be consistent and should allow choosing the specific Envoy Proxy instance.
2. There's actually code in the Backend translation that should have prevented this backend from being accepted. If it's possible for an HTTPRoute to reach the envoy proxy itself, then anybody with the ability to create an HTTPRoute could bypass any other HTTPRoute that has a SecurityPolicy by just creating his own.

I've opened issue #4203 to track this.

[guydc]

There's actually code in the Backend translation that should have prevented this backend from being accepted.

I believe that users can still use this technique by setting an FQDN endpoint like 127.0.0.1.nip.io or any other localhost alias maintained in the pod's /etc/hosts, kube-dns or external DNS provider.

I'm not sure that we should document that as a best practice, though.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days.