Application-gateway-kubernetes-ingress: Support rewriting HTTP headers

[landro]

We'd like to be be able to define HTTP header rewrite rules (ref https://docs.microsoft.com/en-us/azure/application-gateway/rewrite-http-headers) using Kubernetes objects, either as Ingress annotations or as CRD.

A typical use case is the need to set certain security heades like for instance Strict-Transport-Security, Server, X-Content-Type-Options, X-Frame-Options, X-XSS-Protection. The link above contains several additional use cases.

Currently, these rewrite rules can not be set using the app gw ingress controller infrastructure, and risk being wiped if set using other mechanisms.

Related issue:
https://github.com/Azure/application-gateway-kubernetes-ingress/issues/437

[akshaysngupta]

Thanks for suggesting! This is definitely on our road map but we are yet to assign an ETA.

[landro]

Thanks for commenting on this, @akshaysngupta ! I realise you don't have an ETA yet, but what would be your best guess? Are we talking Q4 2019 or Q1 2020? I'm asking, because we're planning several major migrations to AKS in the coming months, and it would be kinda nice to know how much effort we should put in a workaround.

[landro]

Probably makes sense to have a look at how the standard nginx ingress controller does this kind of thing (ConfigMap config): https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/

[asridharan]

@landro instead of going the ConfigMap route we are probably going to define a CRD to have more strongly typed configurations.

As @akshaysngupta mentioned while this feature is on our road-map we probably won't get till Q4'19.

[rnarayana]

Hi, I also want to add the headers for security purposes. Is the workaround right now to add these at the backend services level?

[landro]

That's what we do, @rnarayana . Generally speaking, you could either:

• add a "reverse proxy" sidecar (apache, ngingx, haproxy etc) and rewrite headers there
• rewrite headers in the application itself

[rnarayana]

That's what we do, @rnarayana . Generally speaking, you could either:

* add a "reverse proxy" sidecar (apache, ngingx, haproxy etc) and rewrite headers there

* rewrite headers in the application itself

Thanks, I'll check something like https://helmetjs.github.io/

[evenh]

Any update on this functionality?

[mscatyao]

Hey @evenh - this is still on our backlog, unfortunately we don't have an ETA for this yet as we're working a couple other features right now.

[ahojman]

Hello everyone! 🙋🏻‍♂️- Upvoting this feature, as it's being also requested around! @mscatyao we'll much appreciate if this can be placed little bit up on the priority list.

[evmimagina]

Hi all,

I Agree, it would be great! actually, would be necessary :) or at least, while a more granular feature comes, would it be posible if routing rules don't get overwritten while routing rules don't require an update? (w.a. after deployment, attach the rewrite rule to the desired routing rule, new annotation?).

E.g. A new app get's registered using AGIC. with new release of the app there's a change on the pool members but there's no need to modify routing rules (as they are attached to the pool reference)

Regards,

[joelharkes]

yea also missing: Strict-Transport-Security:

i can set it manually in azure gateway, but it is reverted on every change.

We use nginx as well to do it now but it's a bit weird since nginx is unaware of any https traffic.

[Greg15153]

Any updates on this?

We're looking to roll our AKS cluster into our application gateway but without rewrite headers we lose a core portion of the Gateway. We currently use Nginx as our gateway and would rather not have to run both just to get headers working as we share the gateway with other apps and want to share the header responsibility also.

[kevinmarx]

Upvoting this feature as a priority ask for us. We are using rewrites to re-format the X-FORWARDED-FOR headers to be in the format that doesn't include the port as the final entry. We ensure that the rewrite rules are set after every one of our deploys, however, it seems that some update from the ingress controller will eventually disassociate them.

[manojpramesh]

Waiting forever for this feature!!

[Bougyz]

any progress on that feature, i see it was in the committed planning 2 month ago. I wish it this at least in preview. Appreciate your kind update as my customer is looking for that feature

[aelmanaa]

any ETA for this important feature?

[praveenpattisapu]

Any update on this feature, we have got number of Microsoft tickets open for this issue and they are all pointing to this issue

[mscatyao]

@ all the folks on the thread - we've committed this feature and want feedback on what you all would find most useful/would prefer:

1. an annotation that references rewrite rule sets on the AppGW so any changes to the rewrite rule would have to be made on the AppGW itself.
2. add the capability to create/update the rewrite rule sets entirely using annotations in Ingress manifest, rather than referencing the rule set.
3. add a new CRD for rewrite rule sets and reference it in Ingress manifest using annotations

Edit: updated to clarify #2 and add a #3. (FYI @evmimagina your options have updated!)

[evmimagina]

+1 for option 2

Thanks,

[rnarayana]

In order of preference: Option2, Option3, Option1.

[praveenpattisapu]

In order of preference: Option2, Option1

[aelmanaa]

Maybe to have possibility of using Option1 or Option2 ?
I understand that for some organizations where developers have some freedom , the preferred way is Option2. However, there are many bigger organizations where the teams which work on AKS are not the same as the team which manage App gateways (kind of Network & security teams with very limited k8s expertise). The team which manages App gateways are generally responsible of everything related to APp gatewsay (rewrite rules, WAF setup..Etc).

Hence, I would rather not discard these 2 options

[yylai]

Our order of preference will be Option 2, Option 3, Option1. Exciting update and progress!

[egorchabala]

Option 2

[hueseyinkilic]

@ all the folks on the thread - we've committed this feature and want feedback on what you all would find most useful/would prefer:

1. an annotation that references rewrite rule sets on the AppGW so any changes to the rewrite rule would have to be made on the AppGW itself.
2. add the capability to create/update the rewrite rule sets entirely using annotations in Ingress manifest, rather than referencing the rule set.
3. add a new CRD for rewrite rule sets and reference it in Ingress manifest using annotations

Edit: updated to clarify #2 and add a #3. (FYI @evmimagina your options have updated!)

Option 2
Option 3
Option 1

[stweiz]

Option 2 would be nice. Else Option 3 > Option 1.

[Bougyz]

is the documentation updated as well to show how to use all 3 options!

[Bougyz]

After voting for which option, which one is available for testing @akshaysngupta? or shall we go with the sidecar solution for now

[FabTheMan]

Option 2 is the most K8S friendly as I see things.

[jaysonjc2]

We need this feature urgently. Option2 would be the most optimum one.

[bart-jansen]

Option 2 here. Any ETA for this?

[Bougyz]

+1 for option2

[galvesribeiro]

I think all the options are valid and they don't exclude each other since the AppGateway ingress controller loop can check and apply the changes on any direction.

If I have to choose the priority I would go:

3 - The CRDs approach still lives in "kubernetes landscape" and also allow the same set of rules to be referenced across multiple manifests;
1 - Some people prefer to use the Portal as much as possible;
2 - Defining rules on annotations will quickly become cumbersome and not flexible. If the rules are going to live inside the ingress object, then extend the properties of the object for that. Annotations is not a good way to express complex objects.

[Zeka13]

Any option to remove port information from the X-Forwarded-For header

[hueseyinkilic]

I think if we had it like nginx-ingress we would be a big step ahead. this config would be a basic example on nginx-ingress

annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
    cert-manager.io/acme-challenge-type: http01
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/configuration-snippet: |
      more_set_headers "X-Frame-Options: Deny";
      more_set_headers "X-Xss-Protection: 1; mode=block";
      more_set_headers "X-Content-Type-Options: nosniff";
      more_set_headers "X-Powered-by: NoTell";
      more_set_headers "X-Forwarded-For: ";
      .... and more request / response headers
    # here: instead of Modsecurity, azure AppGW got WAF v2   8-)
    nginx.ingress.kubernetes.io/enable-modsecurity: "true" 
    nginx.ingress.kubernetes.io/enable-owasp-core-rules: "true"

[samuelgautier]

+1 for option 2 to be consistent with other annotations features !
Is there any ETA ?

[bkarakashev]

Any ETA on this?

[bbreijer]

It has been quiet for two months, any news yet?

[hueseyinkilic]

It has been quiet for two months, any news yet?

bump

[kekovski]

Any update on this feature?

[ryandanieldonovan]

Coming from 1003 and realizing this is pretty much what that ticket was referring to. Manually applying (clicking) re-writes to 43 routing routes isn't fun on a daily basis. Love to test this feature out when ready.

[data-plum]

We're also looking forward for this update

[chtourou-youssef]

need update ( in app gateway )

[mscatyao]

Hi all - we're planning to work on this late Q2CY21/early Q3CY21 and will keep this thread posted once there's progress thats available to be tested.

[hueseyinkilic]

Azure is getting expensive

Please consider this issue as high priority

[Danlewis3]

Nearly over 2 years and still a key feature missing.

[mstrother]

Also looking for the ability to add rules via annotations. Without them we're forced to look for alternative ingress solutions.

[LiorHaim]

Any updated on this?
Could be extremely useful...