3:43 a.m.
I managed to play a bit with Ingress on my Minikube installation. A good
place to start is the latest Kubernetes Demo, which was implemented by
Stian [1].
Just a couple of observations:
- As Виталий mentioned, PROXY_ADDRESS_FORWARDING variable on the deployment
must be set to true. Otherwise you will get nasty invalid redirect messages
[2].
- Ingress Controller usually pick class A addresses. Therefore I recommend
setting "Require SSL" parameter on the realm to "external requests".
This
shouldn't be mandatory but it expresses your intentions very well.
- Note that the Ingress points to a Service on port 8080. TLS termination
in handled by an Ingress here. That's why we are targeting port 8080 on the
service (http not https).
- The browser (or a client app) needs to trust the certificate used by the
Ingress. A side note - if you're using Java, perhaps you need to use a
Truststore or add a certificate to jre/lib/security/cacerts.
Thanks,
Sebastian
[1] https://github.com/stianst/demo-kubernetes
[2]
https://github.com/stianst/demo-kubernetes/blob/master/keycloak/keycloak....
On Tue, Jun 26, 2018 at 3:26 PM Meissa M'baye Sakho <msakho(a)redhat.com>
wrote:
I have some additionnal input that could help;
when I change my ingress configuration by switching from https service
(exposed to port 8443) to https (https), it works.
The certificate is beeing presented.
I'm getting a 502 bad gateway from the nginx otherwise.
Maybe this will speaks to you.
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
namespace: opengie-proto
name: keycloak-opengie-proto-ssl
labels:
app: keycloak-opengie-proto
annotations:
nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
nginx.ingress.kubernetes.io/auth-tls-secret: "opengie-tls-secret"
nginx.ingress.kubernetes.io/auth-tls-verify-depth: "3"
nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream:
"true"
spec:
rules:
- host: keycloak-opengie-ssl.proto.paas.eclair.local
http:
paths:
- path: /
backend:
serviceName: keycloak-opengie-proto
*servicePort: http <------- this value works*
tls:
- hosts:
- keycloak-opengie-ssl.proto.paas.eclair.local
2018-06-26 13:53 GMT+02:00 Sebastian Laskawiec <slaskawi(a)redhat.com>:
> Hey Meissa,
>
> The more I think about this issue, the more I'm convinced that disabling
> SSL is the easiest approach. In most of the scenarios you're operating
> within your own Namespace so you can trust it.
>
> Please give me some time to experiment with different options and
> hopefully I will be able to give you some better guidance.
>
> Thanks,
> Sebastian
>
> On Mon, Jun 25, 2018 at 5:04 PM Meissa M'baye Sakho <msakho(a)redhat.com>
> wrote:
>
>> Sebastien,
>> I'm trying to use Kubernetes TLS Client side authentication with
>> keycloak ona cloud environment called Apprenda (based on kubernetes and
>> docker).
>>
>> I can't manage to make it work and I don't know if the problem is from
>> my ingress configuration or from the nginx configuration.
>> In regard to the bug described below:
>> https://github.com/kubernetes/ingress-nginx/issues/2287
>> I seems like it's from the nginx configuration. But I'm not sure.
>>
>> My ingress configuration is the following:
>>
>> apiVersion: extensions/v1beta1
>> kind: Ingress
>> metadata:
>> namespace: opengie-proto
>> name: keycloak-opengie-proto-ssl
>> labels:
>> app: keycloak-opengie-proto
>> annotations:
>> nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
>> nginx.ingress.kubernetes.io/auth-tls-secret: "opengie-tls-secret"
>> nginx.ingress.kubernetes.io/auth-tls-verify-depth: "3"
>> nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream:
>> "true"
>> spec:
>> rules:
>> - host: keycloak-opengie-ssl.proto.paas.eclair.local
>> http:
>> paths:
>> - path: /
>> backend:
>> serviceName: keycloak-opengie-proto
>> servicePort: https
>> tls:
>> - hosts:
>> - keycloak-opengie-ssl.proto.paas.eclair.local
>>
>> Is there something strange that you're seeing in my configuration?
>> Could you give me some hints in the nginx configuration that I have to
>> pay attention?
>> thanks,
>> Meissa
>>
>>
>> 2018-06-21 13:18 GMT+02:00 Sebastian Laskawiec <slaskawi(a)redhat.com>:
>>
>>> I'm an expert on Ingress (I usually work with Routes on OCP) but it
>>> probably depends on the Ingress configuration.
>>>
>>> If I'm not mistaken, the default Ingress configuration terminates TLS
>>> and
>>> sends unencrypted traffic to the Pod. However, Keycloak expects TLS, not
>>> unencrypted HTTP request.
>>>
>>> I think you have a couple of options how to solve it:
>>> - Use Pass-through TLS termination (this simply forwards encrypted
>>> (HTTPS)
>>> traffic to the Pod, without termination). A similar configuration to
>>> this
>>> one:
>>> https://github.com/kubernetes/ingress-nginx/issues/1947#issue-290639351
>>> - Use a Load Balancer Service to access Keycloak (the final result will
>>> be
>>> the same as in the previous solution - a Pod will get HTTPS traffic)
>>> - Turn "Require SLL" option in the "Realm Settings". But
please
>>> remember to
>>> always use properly configured ingress in front of Keycloak. Otherwise
>>> you
>>> might compromise it!!!
>>>
>>> Thanks,
>>> Sebastian
>>>
>>> On Wed, Jun 20, 2018 at 4:53 PM Pavlov, Yordan <yordan.pavlov(a)sap.com>
>>> wrote:
>>>
>>> > Hi all,
>>> >
>>> > I’m evaluating Keycloak as IAM for one open source project [1], so
>>> far,
>>> > I’ve tested it successfully on a minikube (local) Kubernetes cluster
>>> and I
>>> > want to run it in on a real cluster.
>>> >
>>> > The real cluster (created by Gardener [2]) is running on AWS and the
>>> > access to the Keycloak is exposed through an Ingress controller [3].
>>> > We’ve also installed “cert-manager” for automated certificates
>>> management
>>> > of Let’s Encrypt issued certificates.
>>> >
>>> > So far so good, but when I try to login to the “Admin Console” I get
>>> the
>>> > following error:
>>> > “We're sorry... HTTPS required”
>>> >
>>> > In the logs of the pod, there is the following warning:
>>> > “WARN [org.keycloak.events] (default task-12) type=LOGIN_ERROR,
>>> > realmId=master, clientId=null, userId=null, ipAddress=100.96.0.6,
>>> > error=ssl_required”
>>> >
>>> > As far as I understand, the Let’s Encrypt certificated is trusted by
>>> the
>>> > browsers and it appears to be trusted by the OpenJDK also [4].
>>> > Then what should be done in order to access the Admin Console?
>>> >
>>> > Last but not least, we are using jboss/keycloak:latest image (I know
>>> that
>>> > we should be using some stable version like 4.0.0, but it appears
>>> that the
>>> > issue is not related to the image version).
>>> >
>>> > Regards,
>>> > Yordan Pavlov
>>> >
>>> > [1] ProMART: https://github.com/promart-io | https://www.promart.io/
>>> > [2] Gardener: https://github.com/gardener
>>> > [3] Keycloak:
>>> >
>>> https://kkk.ingress.promart.promart.shoot.canary.k8s-hana.ondemand.com
>>> > [4] DST Root CA X3: https://bugs.openjdk.java.net/browse/JDK-8154757
>>> >
>>> > _______________________________________________
>>> > keycloak-user mailing list
>>> > keycloak-user(a)lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>>