lunny/helm-chart
1
0
Fork 0
Code Issues 36 Pull Requests 14 Actions Packages Projects Releases 93 Wiki Activity

Add support for host aliases #400

New Issue
Closed
opened 2023-02-17 06:34:44 +00:00 by podain77 · 10 comments
podain77 commented 2023-02-17 06:34:44 +00:00 (Migrated from gitea.com)
Copy Link

Hi, I'm using gitea for my personal use.
I'm running keycloak in a private network which does not support DNS configuration.
The keycloak service is exposed behind nginx using my own host name.
In this situation, it is required to set host aliases to the gitea container so that it can use the keycloak as auth source.
It is also requried to call webhook servers with custom host names.

Here's my feature branch for this.
https://gitea.com/podain77/gitea-helm-chart/src/branch/support-host-aliases

Please consider merging the commit if it is acceptable.

Thank you.

Hi, I'm using gitea for my personal use. I'm running keycloak in a private network which does not support DNS configuration. The keycloak service is exposed behind nginx using my own host name. In this situation, it is required to set host aliases to the gitea container so that it can use the keycloak as auth source. It is also requried to call webhook servers with custom host names. Here's my feature branch for this. https://gitea.com/podain77/gitea-helm-chart/src/branch/support-host-aliases Please consider merging the commit if it is acceptable. Thank you.
pat-s commented 2023-02-17 07:58:41 +00:00 (Migrated from gitea.com)
Copy Link

I am also using NGINX+Keycloak in combination with Gitea and I haven't had this need.
I don't understand what you mean by "Keycloak does not support DNS configuration".
Can you elaborate?

And please open a PR against this repo so changes can be inspected.

I am also using NGINX+Keycloak in combination with Gitea and I haven't had this need. I don't understand what you mean by "Keycloak does not support DNS configuration". Can you elaborate? And please open a PR against this repo so changes can be inspected.
podain77 commented 2023-02-17 08:16:17 +00:00 (Migrated from gitea.com)
Copy Link

I'm running nginx in a kubernetes cluster as a nodeport service.
Let's say ingress host for keycloak is set to "keycloak.example.com"
Then the auto discovery url will be https://keycloak.example.com/realms/my-ream/.well-known/openid-configuration.
But gitea cannot resolve host "keycloak.example.com".
Because the host is not a public one, either adding dns record or host aliases will work.
But, dns option is not always possible for me.

I'm running nginx in a kubernetes cluster as a nodeport service. Let's say ingress host for keycloak is set to "keycloak.example.com" Then the auto discovery url will be https://keycloak.example.com/realms/my-ream/.well-known/openid-configuration. But gitea cannot resolve host "keycloak.example.com". Because the host is not a public one, either adding dns record or host aliases will work. But, dns option is not always possible for me.
podain77 commented 2023-02-17 08:20:05 +00:00 (Migrated from gitea.com)
Copy Link

And I have no permission to create PR on this repo.
Let me know if any steps are required.

And I have no permission to create PR on this repo. Let me know if any steps are required.
pat-s commented 2023-02-17 10:52:55 +00:00 (Migrated from gitea.com)
Copy Link

And I have no permission to create PR on this repo.

Everyone can create a PR using a fork. See the other open PRs. (unless something changed I am not aware of)

But gitea cannot resolve host "keycloak.example.com".

Can't you use an internal address for autoDiscoverUrl that routes to your keycloak instance? If both Keycloak and Gitea are in the same network, this should work. In the ends it's "just an address", as long as it can be resolved it does not matter whether it's a FQDN or an internal IP routing.

Keycloak should be able to expose the openid-configuration endpoint at some internal address if the ingress host is set correctly. If the ingress is set to a public address but keycloak is not publicly reachable, this won't of course. But then I don't understand how you would be able to reach Keycloak at all.

But maybe I understand the case better once I see the diff of your PR :)

> And I have no permission to create PR on this repo. Everyone can create a PR using a fork. See the other open PRs. (unless something changed I am not aware of) > But gitea cannot resolve host "keycloak.example.com". Can't you use an internal address for `autoDiscoverUrl` that routes to your keycloak instance? If both Keycloak and Gitea are in the same network, this should work. In the ends it's "just an address", as long as it can be resolved it does not matter whether it's a FQDN or an internal IP routing. Keycloak should be able to expose the `openid-configuration` endpoint at some internal address if the ingress host is set correctly. If the ingress is set to a public address but keycloak is not publicly reachable, this won't of course. But then I don't understand how you would be able to reach Keycloak at all. But maybe I understand the case better once I see the diff of your PR :)
👍 1
podain77 commented 2023-02-20 06:20:33 +00:00 (Migrated from gitea.com)
Copy Link

Everyone can create a PR using a fork. See the other open PRs. (unless something changed I am not aware of)

Now i can create PR using fork as you mentioned. I was trying to create PR from mirror repo.

Can't you use an internal address for autoDiscoverUrl that routes to your keycloak instance? If both Keycloak and Gitea are in the same network, this should work. In the ends it's "just an address", as long as it can be resolved it does not matter whether it's a FQDN or an internal IP routing.

I'm using nginx as reserve proxy for multiple hosts with one IP address.
Users access services by adding entries to their /etc/hosts pointing to the nginx IP.
But gitea container can't resolve the host, because it is not an IP address and the host is not registered in the DNS. hostAliases is just there for this kind of purpose.

Here's the PR for this feature.
https://gitea.com/gitea/helm-chart/pulls/401

> Everyone can create a PR using a fork. See the other open PRs. (unless something changed I am not aware of) Now i can create PR using fork as you mentioned. I was trying to create PR from mirror repo. > Can't you use an internal address for `autoDiscoverUrl` that routes to your keycloak instance? If both Keycloak and Gitea are in the same network, this should work. In the ends it's "just an address", as long as it can be resolved it does not matter whether it's a FQDN or an internal IP routing. I'm using nginx as reserve proxy for multiple hosts with one IP address. Users access services by adding entries to their /etc/hosts pointing to the nginx IP. But gitea container can't resolve the host, because it is not an IP address and the host is not registered in the DNS. hostAliases is just there for this kind of purpose. Here's the PR for this feature. https://gitea.com/gitea/helm-chart/pulls/401
pat-s commented 2023-02-20 16:30:38 +00:00 (Migrated from gitea.com)
Copy Link

Users access services by adding entries to their /etc/hosts pointing to the nginx IP.

Hmm, I've never heard of such an approach. Usually the services that nginx serves are mapped into it's config. Then in Gitea you define the ingress and your ingress controller takes care of the routing. Am I misunderstanding the case?

So you don't have a DNS resolution in your network and just use plain mappings in /etc/hosts for all users to be able to resolve DNS names?

Isn't it common to have a self-hosted DNS server running if a public one can't be used? ?

Not necessarily against the PR (from a technical POV) but I wonder if we should add this as I haven't seen this in any other helm chart yet.

@justusbunsi What are your thoughts on this?

> Users access services by adding entries to their /etc/hosts pointing to the nginx IP. Hmm, I've never heard of such an approach. Usually the services that nginx serves are mapped into it's config. Then in Gitea you define the ingress and your ingress controller takes care of the routing. Am I misunderstanding the case? So you don't have a DNS resolution in your network and just use plain mappings in `/etc/hosts` for all users to be able to resolve DNS names? Isn't it common to have a self-hosted DNS server running if a public one can't be used? ? Not necessarily against the PR (from a technical POV) but I wonder if we should add this as I haven't seen this in any other helm chart yet. @justusbunsi What are your thoughts on this?
podain77 commented 2023-02-21 02:27:57 +00:00 (Migrated from gitea.com)
Copy Link

Hmm, I've never heard of such an approach. Usually the services that nginx serves are mapped into it's config. Then in Gitea you define the ingress and your ingress controller takes care of the routing. Am I misunderstanding the case?

So you don't have a DNS resolution in your network and just use plain mappings in /etc/hosts for all users to be able to resolve DNS names?

Isn't it common to have a self-hosted DNS server running if a public one can't be used? ?

Yes, DNS can solve my problem, but that is not an option this time.
Our network is managed securely by dedicated team.
Any records in the DNS server should take steps to be granted permissions.
With host aliases, I can control name resolution completely myself.
And there might be still more cases that can benefit from host aliases.

Not necessarily against the PR (from a technical POV) but I wonder if we should add this as I haven't seen this in any other helm chart yet.

I don't know about other charts but all charts I'm currently using support host aliases.
Please check out links below.

abf9719f38/charts/jenkins/values.yaml (L515)

99932a96c2/charts/argo-cd/values.yaml (L90)

96b18873ff/bitnami/keycloak/values.yaml (L344)

> Hmm, I've never heard of such an approach. Usually the services that nginx serves are mapped into it's config. Then in Gitea you define the ingress and your ingress controller takes care of the routing. Am I misunderstanding the case? > > So you don't have a DNS resolution in your network and just use plain mappings in `/etc/hosts` for all users to be able to resolve DNS names? > > Isn't it common to have a self-hosted DNS server running if a public one can't be used? ? > Yes, DNS can solve my problem, but that is not an option this time. Our network is managed securely by dedicated team. Any records in the DNS server should take steps to be granted permissions. With host aliases, I can control name resolution completely myself. And there might be still more cases that can benefit from host aliases. > Not necessarily against the PR (from a technical POV) but I wonder if we should add this as I haven't seen this in any other helm chart yet. I don't know about other charts but all charts I'm currently using support host aliases. Please check out links below. https://github.com/jenkinsci/helm-charts/blob/abf9719f38820a818b8ce2463b5bb5ca0a7d851f/charts/jenkins/values.yaml#L515 https://github.com/argoproj/argo-helm/blob/99932a96c28af3d06432ace85dc00b52abcbae5d/charts/argo-cd/values.yaml#L90 https://github.com/bitnami/charts/blob/96b18873ffde02c34383b0bc66ce96e25a6a86d0/bitnami/keycloak/values.yaml#L344
pat-s commented 2023-02-21 09:01:31 +00:00 (Migrated from gitea.com)
Copy Link

Our network is managed securely by dedicated team.
Any records in the DNS server should take steps to be granted permissions.
With host aliases, I can control name resolution completely myself.

If I would be a member of the "dedicated security team", I am not sure I would like this ?️

I don't know about other charts but all charts I'm currently using support host aliases.

Thanks, that helps! In that case, I am fine with the proposed changes! Thanks for the detailed replies and patience!

> Our network is managed securely by dedicated team. Any records in the DNS server should take steps to be granted permissions. With host aliases, I can control name resolution completely myself. If I would be a member of the "dedicated security team", I am not sure I would like this ?️ > I don't know about other charts but all charts I'm currently using support host aliases. Thanks, that helps! In that case, I am fine with the proposed changes! Thanks for the detailed replies and patience!
podain77 commented 2023-02-21 12:14:14 +00:00 (Migrated from gitea.com)
Copy Link

@pat-s Thank you for the review and approval. ?

@pat-s Thank you for the review and approval. ?
justusbunsi commented 2023-02-21 17:49:45 +00:00 (Migrated from gitea.com)
Copy Link

@justusbunsi What are your thoughts on this?

I am fine with it. ?

> @justusbunsi What are your thoughts on this? I am fine with it. ?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
has/backport
in progress
invalid
kind/breaking
kind/bug
kind/build
kind/dependency
kind/deployment
kind/docs
kind/enhancement
kind/feature
kind/lint
kind/proposal
kind/question
kind/refactor
kind/security
kind/testing
kind/translation
kind/ui
need/backport
priority/critical
priority/low
priority/maybe
priority/medium
reviewed/duplicate
reviewed/invalid
reviewed/wontfix
skip-changelog
status/blocked
status/needs-feedback
status/needs-reviews
status/wip
upstream/gitea
upstream/other
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: lunny/helm-chart#400
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?