IBM Security Verify

 View Only
  • 1.  timezone when deploying Helm charts

    Posted Thu September 10, 2020 05:44 AM
    How do we set the correct ("Europe/Stockholm" in our case) timezone for "config/runtime/admin/reverse proxy" pods, when deploying from the IBM Chart github repo?

    The Kubernetes cluster runs with timezone "UTC".

    Rgds

    ------------------------------
    Anders Domeij
    CGI Sweden AB
    ------------------------------


  • 2.  RE: timezone when deploying Helm charts

    Posted Thu September 10, 2020 06:29 AM
    Hi Anders,

    The timezone for a Verify Access container (used when writing time into logs etc.) is set based on environment variable CONTAINER_TIMEZONE.

    Looking at the internals of the Verify Access charts, it doesn't look like this is being set and so some default will be used (I hope that's UTC).  I think this is an oversight - the charts will have to be updated to have timezone as an optional input parameter to be passed into all deployment definitions.  Something we can look at in the future.

    Feel free to open an ISSUE on GitHub or happy to get a PULL request from you if you want to add it into the charts yourself :)

    Is the a blocker for your deployment?

    Jon.

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



  • 3.  RE: timezone when deploying Helm charts

    Posted Thu September 10, 2020 07:14 AM
    Yes (at least we think it is)
    If the timezone in the reverse proxy is in UTC and the reverse proxy sets a cookie that is handled by our backend servers, we feel that the time difference between UTC and Stockholm (+2 hrs) leads to errors -- for instance when cookies are checked for validity (expiry and or validty time time for instance) and security token timestamps are probably affected too.

    Unfortunately (for us) Rancher will only install helm chats from a github repo, so pulling to local disk doesn't help as we haven't set up a local github repo server :-(

    Rgds

    ------------------------------
    Anders Domeij
    CGI Sweden AB
    ------------------------------



  • 4.  RE: timezone when deploying Helm charts

    Posted Thu September 10, 2020 07:20 AM
    >Looking at the internals of the Verify Access charts, it doesn't look like this is being set and so some default will be used (I hope that's UTC).


    Actually I think it will be the timezone of the Kubernets Cluster that is used if no overide is done in the pod deployment.

    Again unfortunately (for us), the documentation for setting up Kubernetes clusters doesn't emphasize the need to consider s not very clear so pods deployed to our cluster are running UTC.

    The remedy to that problem would be to scrap the cluster restart it with our local timezone and redeploy all charts (from scratch).

    Not an exciting venue.

    Rgds


    ------------------------------
    Anders Domeij
    CGI Sweden AB
    ------------------------------



  • 5.  RE: timezone when deploying Helm charts

    Posted Thu September 10, 2020 08:08 AM
    Hi Anders,

    The timezone setting should not impact the times associated with cookies or tokens created by Verify Access.  These should all be set based on UTC regardless of the timezone.

    If you find that things are going wrong, and you suspect time differences are the issue, it's more likely that the source and destination systems have different
    absolute times set.  Make sure that the time is correct for the timezone that is set.  Using network time to keep all times correct is recommended.

    If you have logs for a specific failure then please share something.

    Jon.

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



  • 6.  RE: timezone when deploying Helm charts

    Posted Thu September 10, 2020 10:28 AM
    Short version...


    Our suspicion is based on:
    In the test Web reverse proxy : Docker compose -- the time in the container matches that of the Host.
    From test web reverse proxy:  ltpa-login to backend (also local time) works. :-)
    Note: ISAM v 9.0.7

    In the ISVA reverse proxy: Kubernetes -- the time in the pod (-2h) <> Host time
    From ISVA reverse proxy: ltpa-login to backend (same as above) error seen in log "Invalid Security token" :-(
    Note: ISVA 10.0.0.0

    Sorry for the short version (out of time for now)

    Rgds

    ------------------------------
    Anders Domeij
    CGI Sweden AB
    ------------------------------



  • 7.  RE: timezone when deploying Helm charts

    Posted Thu September 10, 2020 12:02 PM
    That UTC time is possibly coming from the image.  If you want the timezone of the host, you need to perform.  In your pod or deployment definition you can add a volume mount :

    volumeMounts:
    - name: tz-config
      mountPath: /etc/localtime
    volumes:
    - name: tz-config
      hostPath:
        path: /usr/share/zoneinfo/Europe/Stockholm

    Regards,
    Serge Vereecke


    ------------------------------
    Serge Vereecke
    ------------------------------



  • 8.  RE: timezone when deploying Helm charts

    Posted Thu September 10, 2020 04:46 PM
    Anders,
     
    The LTPA token does contain an expiry, however it is written as the number of seconds since epoch - which means it is timezone agnostic (epoch time is in UTC).  So, Jon is correct and the different timezones should not impact the expiry time of the LTPA token.
     
    The timeout of the token itself is calculated as either twice the configured lifetime of a session, or twice the configured ltpa-cache-entry-lifetime value.
     
    Have you checked to ensure that the clocks are synchronised between the two containers?  Even though they might be configured in different timezones the clocks should still be synchronized (i.e. represent the same absolute time).  I would suggest that you try increasing ltpa-cache-entry-lifetime to some hideously long value to see if the issue is actually due to the LTPA token expiry, and is not due to something else.

    I hope that this helps,

    Scott.


    ------------------------------
    Scott Exton
    IBM
    Gold Coast
    ------------------------------