Skip to content

Further edits to ingress object section #8337

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Mar 29, 2018
Merged

Further edits to ingress object section #8337

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 23 additions & 4 deletions admin_guide/managing_networking.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -155,15 +155,26 @@ the same rules apply for claiming a domain for a namespace based on the creation
time of the object. For example, the oldest route winning against any other
claimants wanting to use the same namespace.

For example, ownership of routes is based on the claims made for that host name with the same namespace. The oldest route wins against any other claims.
For example, ownership of routes is based on the claims made for that host name
with the same namespace. The oldest route wins against any other claims.

[NOTE]
====
Routes and ingress objects have the same data structure internally on the
router, with ingress objects having the capability to turn into multiple route
objects. The claim rules above apply for each of these objects. However, because
an ingress object can have two hostnames, one hostname can be claimed by the
ingress object and be active, while the second cannot claim, and remains
inactive.
====

While this makes the router compatible with Kubernetes ingress
objects, some caveats exist:

* Ingress objects store the keys and certificates in secrets, so the router needs permission to read all secrets in the system.
* Ingress objects only support edge termination for *https* routes.

To configure an existing router to have Ingress support (assuming the default
To configure an existing router to have ingress support (assuming the default
name of `router` for the deployment configuration and the service-account):

. Set the `ROUTER_ENABLE_INGRESS` environment variable to `true`:
Expand All @@ -172,10 +183,18 @@ name of `router` for the deployment configuration and the service-account):
$ oc env dc router ROUTER_ENABLE_INGRESS=true`
----

. Add the cluster-admin role to the router:
. Add the `cluster-reader` role to the router, where `-z` is the service
account:
+
----
$ oc adm policy add-cluster-role-to-user cluster-reader -z router
----

. Give the router the authorization to manage ingress objects:
+
----
$ oc adm policy add-role-to-user cluster-admin router`
$ oc adm policy add-cluster-role-to-user \
system:openshift:controller:service-serving-cert-controller -z router
----

[[admin-guide-controlling-egress-traffic]]
Expand Down