IBM Security Verify

 View Only
  • 1.  IBM IAG: Best way of health check in Kubernetes

    Posted Mon August 23, 2021 08:31 AM
    Hello,

    I am using IBM IAG as Relying Party in Kubernetes, but I am getting errors when I create the service as NodePort and use it through GCE Ingress. Health check is failing and I don't know why. 

    I created a local page in config.yaml using a zip file with a folder and a index.html file. The health check points to this index.html using HTTPS and towards the node port.

    Do you know how to solve it? Do you know any other way to verify the health status?

    Regards

    ------------------------------
    Javier Garcia Pazos
    ------------------------------


  • 2.  RE: IBM IAG: Best way of health check in Kubernetes

    Posted Fri August 27, 2021 07:10 AM
    Hi Javier,

    What kind of healthcheck is this?  If it's the healthcheck performed at the pod level, I wouldn't expect this to connect via the NodePort... usually it would be a direct communication to the pod listening port to check for active TCP connection or for a specific HTTP request.

    Maybe you're talking about a healthcheck at the Ingress?  I'm not so familiar with that.  One guess might be that the healthcheck expects to get back a 200 response code and maybe the (unauthenticated) request for index.html is returning a 302 to your identity provider for authentication?  If this is the case then you'll either need to make the page that you check for health available to unauthenticated connections or you'll need to change the healthcheck definition so that 302 is an acceptable response.

    Do you see the healthcheck request in the request log of the IAG?  That would let you know that the request is reaching IAG and what response is being returned.

    Jon.

    ------------------------------
    Jon Harry
    Consulting IT Security Specialist
    IBM
    ------------------------------



  • 3.  RE: IBM IAG: Best way of health check in Kubernetes

    Posted Mon August 30, 2021 10:58 AM
    Hello Jon

    it is a healthcheck at ingress. I saw logs as you told me and I could see that a 302 was the response to the healthcheck. But I allow any user to the healthcheck url (it is a local page I uploaded) but it is giving 400 now. I connected to the pod and when I try https://localhost:8443/credview (for example) that it is allowed for everyone, I receive a "DPWWA1218E Unknown junction server host".

    Do you know what is happening?

    Regards

    ------------------------------
    Javier Garcia Pazos
    ------------------------------



  • 4.  RE: IBM IAG: Best way of health check in Kubernetes

    Posted Mon August 30, 2021 03:40 PM
    Javier,
     
    You will get the 'DPWWA1218E Unknown junction server host' error when the host name configured for the junctioned server is not resolving to an IP address.  SO, I would check the definition of the credview junction and ensure that the server name included in the junction definition can resolve to an IP address.
     
    Scott A. Exton
    Senior Software Engineer
    Chief Programmer - IBM Security Verify Access

    IBM Master Inventor

     
     
     





  • 5.  RE: IBM IAG: Best way of health check in Kubernetes

    Posted Tue August 31, 2021 02:37 AM
    Thank you Scott,

    I think I didn't explain myself but credview is a local application so the configuration is:

    server:
      local_applications:
        cred_viewer:
          path_segment: credview
          enable_html: true
          attributes:
            - "-AUTHENTICATION_LEVEL"​


    and then

    policies:
            authorization:
            - name: policyA
              paths:
              - /credview
              rule: anyuser
              action: permit​

    And when I request https://localhost:8443/credview from inside the container, I get:
    curl -vk https://localhost:8443/credview
    *   Trying 127.0.0.1...
    * TCP_NODELAY set
    * Connected to localhost (127.0.0.1) port 8443 (#0)
    * ALPN, offering h2
    * ALPN, offering http/1.1
    * successfully set certificate verify locations:
    *   CAfile: /etc/pki/tls/certs/ca-bundle.crt
      CApath: none
    * TLSv1.3 (OUT), TLS handshake, Client hello (1):
    * TLSv1.3 (IN), TLS handshake, Server hello (2):
    * TLSv1.2 (IN), TLS handshake, Certificate (11):
    * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
    * TLSv1.2 (IN), TLS handshake, Server finished (14):
    * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
    * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
    * TLSv1.2 (OUT), TLS handshake, Finished (20):
    * TLSv1.2 (IN), TLS handshake, Finished (20):
    * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-SHA256
    * ALPN, server did not agree to a protocol
    * Server certificate:
    *  subject: CN=iag-crpr-b96b65597-mwm4f
    *  start date: Aug 29 23:51:51 2021 GMT
    *  expire date: Dec  2 23:51:51 2023 GMT
    *  issuer: CN=iag-crpr-b96b65597-mwm4f
    *  SSL certificate verify result: self signed certificate (18), continuing anyway.
    > GET /credview HTTP/1.1
    > Host: localhost:8443
    > User-Agent: curl/7.61.1
    > Accept: */*
    >
    < HTTP/1.1 400 Bad Request
    < content-length: 3469
    < content-type: text/html
    < date: Tue, 31 Aug 2021 06:35:11 GMT
    < p3p: CP="NON CUR OTPi OUR NOR UNI"
    < x-frame-options: DENY
    < x-content-type-options: nosniff
    < cache-control: no-store
    < x-xss-protection: 1
    < content-security-policy: frame-ancestors 'none'
    < strict-transport-security: max-age=31536000; includeSubDomains
    < pragma: no-cache
    <
    <!DOCTYPE html>
    <html>
    <head>
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <meta name="viewport" content="width=device-width, initial-scale=1">
      <title>Application Gateway</title>
      <style>
    *{font-family:'IBM Plex Sans','Helvetica Neue',Arial,sans-serif;letter-spacing:normal;text-rendering:optimizelegibility;user-select:none;-webkit-font-smoothing:antialiased -moz-font-smoothing:antialiased;-ms-font-smoothing:antialiased;-o-font-smoothing:antialiased;}
    em{font-style:inherit;font-weight:700;}
    body{margin:0;padding:0;}
    html{height:100%;min-height:400px;background-color:#f3f3f3;}
    a{color:inherit;text-decoration:inherit;}
    h2{font-size:20px;margin-left:176px;}
    h4{clear:both;padding-top:32px;}
    p{font-size:14px;font-weight:400;margin-left:176px;}
    .container{background-color:#fff;width:50%;max-width:720px;position:absolute;top:50%;left:50%;transform:translate(-50%,-50%);padding:48px 48px 0px 48px;min-height:300px;}
    .container-short{min-height:240px;}
    .message-box{font-size:1rem;color:#000000;padding:16px;}
    .header{background-color:#161616;border-bottom:1px solid #393939;z-index:10000;height:3rem;color:#fff;padding:0 1rem;font-size:1rem;vertical-align:baseline;line-height:48px;font-weight:600;font-size:16px;}
    .button{line-height:64px;width:50%;height:64px;color:#FFF;background-color:rgb(80,80,80);margin-bottom:-16px;text-align:left;border-style:none;padding-left:12px;font-size:14px;background-color:#4c4c4c;position:absolute;}
    .button-other{left:0;}
    .button-primary{background-color:rgb(15,98,254);position:absolute;right:0;}
    .button-primary:hover{background-color:#0353e9;}
    table{border-collapse:collapse;width:100%;margin-bottom:64px;}
    th{background-color:rgb(224,224,224);width:30%;font-weight:600;}
    td{width:70%;font-weight:400;background-color:rgb(244,244,244);font-weight:400;}
    th,td{border-top:1px solid #f4f4f4;border-bottom:1px solid #e0e0e0;font-size:12px;padding-bottom:0px;padding-right:12px;padding-top:12px;padding-bottom:12px;padding-left:16px;text-align:left;word-break:break-word;}
    .button-container{width:100%;height:64px;background-color:#c6c6c6;margin-left:-48px;margin-right:-48px;border-style:none;position:absolute;bottom:-32px;}
    svg{height:128px;width:128px;float:left;padding-right:48px;}
      </style>
    </head>
    <body>
      <div class="header">
        <span>Application Gateway</span>
      </div>
      <div class="container">
        <div class="message-box">
    <svg focusable="false" preserveAspectRatio="xMidYMid meet" xmlns="http://www.w3.org/2000/svg" width="35%" height="35%" viewBox="0 0 48 48" aria-hidden="true" style="will-change: transform;"><path fill="none" stroke="#000" stroke-linejoin="round" stroke-miterlimit="10" stroke-width=".72" d="M39,37H9l15-26L39,37z M24,28V18"></path><circle cx="24" cy="32" r="1"></circle></svg>      <h2>Error</h2>
          <p>The Application Gateway could not complete your request due to an unexpected error.</p>
          <H4>Diagnostic Information</H4>
          <table>
            <tr>
              <th>Method</th>
              <td>GET</td>
            </tr>
            <tr>
              <th>URL</th>
              <td>/credview</td>
            </tr>
            <tr>
              <th>Error Code</th>
              <td>0x38cf04c2</td>
            </tr>
            <tr>
              <th>Error Text</th>
              <td>DPWWA1218E   Unknown junction server host</td>
            </tr>
          </table>
        </div>
        <div class="button-container">
          <a class="button button-primary" href="/">Go Back</a>
        </div>
      </div>
    </body>
    * Connection #0 to host localhost left intact​

    Thank you for your help.
    Regards

    ------------------------------
    Javier Garcia Pazos
    ------------------------------



  • 6.  RE: IBM IAG: Best way of health check in Kubernetes

    Posted Tue August 31, 2021 05:12 PM
    Javier,
     
    Unfortunately I cannot reproduce the issue which you are seeing - I believe that you have an issue in your IAG configuration which is causing this problem.
     
    Here is the simplistic IAG configuration file which I used in my testing:
     
    ---
    version: 21.06
    server:
      local_applications:
        cred_viewer:
          path_segment: credview
          enable_html: true
    policies:
      authorization:
        # Allow unauthenticated access to /public
        - name: unauth
          paths: 
            - /credview
          method:
            - GET
          rule: anyuser
          action: permit
     
    When I run IAG with this configuration I am able to successfully access the '/credview' resource just fine.  I would suggest that you examine your configuration, perhaps commenting out additional lines until you can isolate the cause of the problem.  I suspect that there will be an application/junction definition (perhaps a virtual host junction) which is clashing with the '/credview' resource.
     
     
    I hope that this helps.
     
     
    Scott A. Exton
    Senior Software Engineer
    Chief Programmer - IBM Security Verify Access

    IBM Master Inventor

     
     
     





  • 7.  RE: IBM IAG: Best way of health check in Kubernetes

    Posted Wed September 01, 2021 05:29 AM
    Scott, you were right, I didn't realize that I had a resource server with the path "/". I removed it and then it worked.

      - path: "/"
        connection_type: "tcp"
        servers:
          - host: "service"
            port: 80
        transparent_path: true​


    Now I am going to try the healthcheck again. 

    I will let you know the results.

    Regards



    ------------------------------
    Javier Garcia Pazos
    ------------------------------



  • 8.  RE: IBM IAG: Best way of health check in Kubernetes

    Posted Thu September 02, 2021 02:44 AM
    It worked.

    I added a local page in /healthz/index.html. Then I allow unauthenticated connections to that path and it worked.

    Thank you to both of you and best regards

    ------------------------------
    Javier Garcia Pazos
    ------------------------------