IBM Security Verify

 View Only
Expand all | Collapse all

helm 2 to helm 3 migrations

  • 1.  helm 2 to helm 3 migrations

    Posted Mon July 06, 2020 07:49 AM
    Edited by Tinashe Wilbrod Chipomho Mon July 06, 2020 07:50 AM
    We are looking at doing a helm 3 migration of these charts https://hub.helm.sh/charts/ibm-charts/ibm-sam

    I wanted to know if it is not privileged information;

    • something has done already from the IBM side
    • Easy to use tutorial to avoid breaking environments
    • Any other resources to use if there is no official migration for such.


    ------------------------------
    Tinashe Wilbrod Chipomho
    ------------------------------


  • 2.  RE: helm 2 to helm 3 migrations

    Posted Mon July 06, 2020 09:36 AM
    Hello Tinashe,

    I updated the Access Manager Helm charts to work with Helm 3.0.  The updated charts are on GitHub here:
    https://github.com/ibm-security/helm-charts/
    I suggest you take a look at these charts and see if they will meet your needs.

    I'm not aware of any migration assets but these charts are very similar to the v2.0 charts so migration should not be too hard.

    Jon.

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



  • 3.  RE: helm 2 to helm 3 migrations

    Posted Tue July 07, 2020 06:51 AM
    Hi Jon,

    Will there be an update of the HELMcharts for ver 10?
    The "Whats new "documentation for ver 10 says the Helm charts have moved 'but' links to the ver 9.7 github directory updated by you in April.
    Rgds
    Anders

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



  • 4.  RE: helm 2 to helm 3 migrations

    Posted Wed July 08, 2020 04:11 PM
    Hi Anders,

    There's a branch in the GitHub repo where I'm working on an update for v10.  I haven't fully tested but I think it's probably OK if you want to try it out.

    Jon.

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



  • 5.  RE: helm 2 to helm 3 migrations

    Posted Thu July 09, 2020 09:24 AM
    Thanks, I can browse to the gihub directories, but when I try :

    helm repo add IBM-Security https://github.com/IBM-Security/helm-charts/tree/master/stable
    I get the following
    Error: looks like "https://github.com/IBM-Security/helm-charts/tree/master/stable" is not a valid chart repository or cannot be reached: failed to fetch https://github.com/IBM-Security/helm-charts/tree/master/stable/index.yaml : 404 Not Found

    And if I try
    helm repo add IBM-Security https://github.com/IBM-Security/helm-charts/tree/verifyaccessv10/repo/stable

    I get the same response:
    Error: looks like "https://github.com/IBM-Security/helm-charts/tree/verifyaccessv10/repo/stable" is not a valid chart repository or cannot be reached: error converting YAML to JSON: yaml: line 123: mapping values are not allowed in this context

    I'm using Helm Version:"v3.2.4"

    Rgds
    Anders

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



  • 6.  RE: helm 2 to helm 3 migrations

    Posted Thu July 09, 2020 09:44 AM
    Sorry pasted a bit too fast :-)
    helm repo add IBM-Security https://github.com/IBM-Security/helm-charts/tree/repo/master/stable

    also complains with the YAML to JSON conversion.

    Anders

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



  • 7.  RE: helm 2 to helm 3 migrations

    Posted Thu July 09, 2020 01:15 PM
    Hi Anders,

    You're pointing to the GitHub HTML page.  You need to point to the "raw" content.  Try this:

    helm repo add ibm-security https://raw.githubusercontent.com/IBM-Security/helm-charts/verifyaccessv10/repo/stable

    Jon.

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



  • 8.  RE: helm 2 to helm 3 migrations

    Posted Fri July 10, 2020 03:26 AM
    Thanks!
    Worked!
    Feel like a bit of fool, but beginners/newbies are allowed some leeway I hope :-)


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



  • 9.  RE: helm 2 to helm 3 migrations

    Posted Fri July 10, 2020 04:32 AM
    Hi Anders,

    I'm pleased it worked for you.  Don't worry, we all need some leeway working with all these new technologies.
    Please let me know how you get on with these v10 Helm Charts.

    One thing to note is that because the names have changed in this chart (specifically the service names), an old configuration snapshot loaded into this new environment won't work because the host names are different.  You can fix it up (by hunting around and looking for references to the old hostnames and changing) but they are in quite a few places.  Here are some I can think of right now:
    • postgreSQL hostname in runtime database configuration
    • OpenLDAP hostname (ldap.conf file under runtime)
    • References to OpenLDAP/DB in Server connections
    • Reference to LDAP in AAC Username mechanism
    • References to AAC/Fed Runtime in /mga junction (or any other junction to the runtime)
    • DSC hostname in Cluster configuration
    • References to AAC Runtime host in the Reverse Proxy configuration files
    You can also probably do something nasty in the coreDNS configuration to create hostname aliases for the old names but I've never really been happy with this.  Not sure why there isn't better support for DNS aliasing in Kubernetes - maybe I missed something.

    I also found that because of the hostname change, the LMI keystore was regenerated which removed the Database signing certificate.  I had to reload it.

    TBH, probably easier to start on a fresh configuration (if you can).

    Jon.

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



  • 10.  RE: helm 2 to helm 3 migrations

    Posted Fri July 10, 2020 04:46 AM
    Luckily (?) for us we're doing a fresh installation :-)
    For on-premise is the correct way to do it to pull the charts edit them and install from the local copy, we don't have the nice ICP interface that Scott uses in his demo.

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



  • 11.  RE: helm 2 to helm 3 migrations

    Posted Fri July 10, 2020 04:58 AM

    Hi Anders,

    In theory, you should be able to consume a chart as-is directly from a repo - using only a local values.yaml file updated for your own requirements.  However, if you need to change the logic in the charts themselves then you would need your own copy.

    If you find there are things that you need to change that can't be changed using the values.yaml file (because they are hard-coded in the charts themselves), I'd be interested to know.  That would indicate that the charts need to be improved to allow additional control via the values file.

    Jon.



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



  • 12.  RE: helm 2 to helm 3 migrations

    Posted Fri July 10, 2020 05:10 AM
    Of course we will report any issues we see with the charts.
    For instance, we don't want to install openldap or postgres, we have both the directory server and database external to our kubernetes cluster. Is that something we can control with the values.yaml file ??

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



  • 13.  RE: helm 2 to helm 3 migrations

    Posted Fri July 10, 2020 05:50 AM
    Anders,

    The default values.yaml file is here:
    https://raw.githubusercontent.com/IBM-Security/helm-charts/verifyaccessv10/stable/ibm-security-verify-access/values.yaml

    In this file you'll see sections for both Postgres and OpenLDAP like this:

    ###############################################################################
    # postgresql container variables.
    
    isvapostgresql:
    
    # Container configuration.
    container:
    enabled: false​

    You'll see that, in fact, the default is not to deploy the postgres or openldap containers.

    You probably will want to make changes to this file.  Take a local copy of this, update, and then pass into the helm install command (with -f flag).

    Jon.

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