<p>What is the best way to allow CORS requests at this time? (Given that CORS support in the Contour Ingress currently is in the &quot;<a href="https://github.com/projectcontour/contour/issues/437" rel="nofollow noreferrer">parking lot</a>&quot;)</p>
<p>My particular use case is hosting a GRPC service, which envoy reverse proxies. Conveniently, contour also supports grpc-web out-of-the-box, which we'd like to use for our web service.</p>
<p>However, given that CORS are not supported, we cannot do cross-domain requests.</p>
<p>Apart from making our web app use the same domain as the GRPC api, is there any other solution that could fill our need at the moment?</p>
<p>Basically, we'd want the envoy to be configured very similarly to the <a href="https://github.com/grpc/grpc-web/blob/master/net/grpc/gateway/examples/echo/envoy.yaml" rel="nofollow noreferrer">GRPC web example config</a>.</p>

Hannes Lohmander
<p>For anyone that stumbles upon this question trying to setup Controur, gRPC, and TLS;</p>
<p>you want to use <code>HTTPProxy</code> instead. Working configuration with TLS:</p>
<pre class="lang-yaml prettyprint-override"><code>apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
  name: service-proxy 
spec:
  virtualhost:
    fqdn: service.example.com 
    corsPolicy:
      allowCredentials: true
      allowOrigin:
        - &quot;*&quot; 
      allowMethods:
        - GET
        - POST
        - OPTIONS
      allowHeaders:
        - authorization
        - cache-control
        - x-grpc-web
        - User-Agent
        - x-accept-content-transfer-encoding
        - x-accept-response-streaming
        - x-user-agent
        - x-grpc-web
        - grpc-timeout
        - Grpc-Message
        - Grpc-Status
        - content-type
    tls:
      secretName: service-secret
  routes:
    - conditions:
      - prefix: /
      services:
        - name: my-service
          port: 80
---
apiVersion: apps/v1
kind: Deployment metadata:
  labels:
    app: my-app
    run: my-service
  name: my-service
spec:
  replicas: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  selector:
    matchLabels:
      app: my-app
      run: my-service
  template:
    metadata:
      labels:
        app: my-app
        run: my-service
    spec:
      containers:
        - image: image:latest
          name: my-service
          resources: {}
          imagePullPolicy: Always
          readinessProbe:
            initialDelaySeconds: 10
            periodSeconds: 2
            httpGet:
              path: /health-check
              port: 3000
---
apiVersion: v1
kind: Service
metadata:
  name: my-service
  labels:
    app: my-app
    run: my-service
  annotations:
    projectcontour.io/upstream-protocol.h2c: &quot;80&quot;
spec:
  ports:
  - port: 80
    targetPort: 50051
    protocol: TCP
  selector:
    run: my-service
</code></pre>
<h2>A Couple notes</h2>
<ol>
<li>My understanding from the documentation is that the <code>projectcontour.io/upstream-protocol.h2c</code> should actually be <code>projectcontour.io/upstream-protocol.h2</code>, but doing that I get a <code>TLS error: 268435703:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER</code> error in the response. This configuration, with <code>h2c</code>, seems to be working and actually employing TLS to transport request/response data.</li>
<li>I haven't gone through and groomed the <code>allowHeadrs</code>, this is just a set that's working for me right now using <code>grpcurl</code> and a web application frontend built with React using the awesome <a href="https://github.com/deeplay-io/nice-grpc/tree/master/packages/nice-grpc-web" rel="nofollow noreferrer">nice-grpc-web</a> library.</li>
<li>Obligatory - <strong>you should not use &quot;*&quot; as an allow origin in production</strong> because it is a security concern - warning (<em>really...</em> don't do it).</li>
<li>The TLS secret <code>secret-service</code> was actually manually generated, I haven't tested the cert-manager stuff yet.</li>
</ol>
