Update egress network policy of some charts

[mpgxvii]

Description of the change

• An error occurs when the network policy pod selector host name is > 63 characters, this will truncate that value
• Truncate postgres podselector so that it is within 63 character limit (update MP, appserver, upload-backend, and rest-sources-backend network policy egress)

Benefits

Possible drawbacks

Applicable issues

• fixes #

Additional information

Checklist

• Chart version bumped in Chart.yaml according to semver.
• Variables are documented in the README.md
• Title of the PR starts with chart name (e.g. [<name_of_the_chart>])

[github-actions]

Great PR! Please pay attention to the following items before merging:

Files matching charts/*/values.yaml:

• Is the PR adding a new container? Please reviewer, add it to the models (internal process)
• Is the PR adding a new parameter? Please, ensure it’s documented in the README.md

This is an automatically generated QA checklist based on modified files.

[mpgxvii]

@yatharthranjan @keyvaann This issue comes up because we are using AWS RDS so the hostname is greater than 63 characters. But I think this egress is only applicable if the postgres is hosted in the cluster? This solution is truncating that host name. Is this fine? Or is it better to check if postgres is installed instead? I feel that manually replacing the network policies would be too much duplication for each chart (for example if we replace this in production.yaml).

[baixiac]

Is k8s permitting the use of a trailing wildcard following the truncated to match the entire value?

[keyvaann]

Thanks @mpgxvii!
Yes truncating the host names is fine in order to prevent Kuberentes from complaining and this egress is indeed only applicable when the postgres is hosted on the cluster. It probably won't be needed to check if the Postgres is installed or not.
Do you know if the RDS address on the AWS is a private IP address or a public one?

[keyvaann]

Is k8s permitting the use of a trailing wildcard following the truncated to match the entire value?

I don't think so, especially when we're using matchLabels to select the pods.

[mpgxvii]

Thanks @mpgxvii! Yes truncating the host names is fine in order to prevent Kuberentes from complaining and this egress is indeed only applicable when the postgres is hosted on the cluster. It probably won't be needed to check if the Postgres is installed or not. Do you know if the RDS address on the AWS is a private IP address or a public one?

@keyvaann Oh ok I see. Thanks! Yes it is private for our installation.

[keyvaann]

Thanks @mpgxvii! Yes truncating the host names is fine in order to prevent Kuberentes from complaining and this egress is indeed only applicable when the postgres is hosted on the cluster. It probably won't be needed to check if the Postgres is installed or not. Do you know if the RDS address on the AWS is a private IP address or a public one?

@keyvaann Oh ok I see. Thanks! Yes it is private for our installation.

In that case we might need to remove the section that blocks the connection to local network. Would you be able to test if it works on your installation?

[keyvaann]

LGTM

[mpgxvii]

In that case we might need to remove the section that blocks the connection to local network. Would you be able to test if it works on your installation?

Oh ok I see. Yeah it seems to be working without removing the block.

[keyvaann]

In that case we might need to remove the section that blocks the connection to local network. Would you be able to test if it works on your installation?

Oh ok I see. Yeah it seems to be working without removing the block.

That's good. I'll try to investigate this at some point.