IBM Security Verify

  • 1.  Forbidden Issue

    IBM Select
    Posted Wed October 13, 2021 06:17 AM
    We are doing quick POC for the ISVA on open sfhit V4 , as per below page we are creating secrete by using setup-security.sh but having below error. but when we have cheked inernally with our open shift team they have confirmed they will not provide access to create service account for our id as per internal process.  so do we have any work around for this?

    ************** DEV $ oc create serviceaccount verifyaccess-config
    Error from server (Forbidden): serviceaccounts is forbidden: User "*****" cannot create resource "serviceaccounts" in API group "" in the namespace "***"

    GitHub - iamexploring/container-deployment: Assets for exploring deployment of IBM Security Verify Access in containers.
    GitHub remove preview
    GitHub - iamexploring/container-deployment: Assets for exploring deployment of IBM Security Verify Access in containers.
    These assets are for IBM Security Verify Access v10.0.2.0. Assets for v10.0.0.0 (which will also work with v10.0.1.0) are available as a release. Checkout tag v10.0.0.0-1. Assets for IBM Security Access Manager are available at https://ibm.biz/isamdocker This cookbook describes deployment with Native Docker and Docker Compose.
    View this on GitHub >


    ------------------------------
    Mayur Wattamwar
    ------------------------------


  • 2.  RE: Forbidden Issue

    Posted Wed October 13, 2021 01:47 PM
    Edited by Jon Harry Wed October 13, 2021 01:51 PM
    Hi Mayur,

    The service accounts are created by these scripts as a way to link to extended security constraints required by some Verify Access components.

    The "worker" containers (Reverse Proxy, Runtime, DSC) do not require special permissions.  They can run with default OpenShift permissions.
    The configuration container requires some extended permissions (you can see them in the security-constraints.yaml file in the repo.
    The OpenLDAP container (provided for testing) requires run-as-root
    The PostgreSQL container (provided for testing) requires run-as-user

    If your cluster admin team can create the required constraints and map them to service accounts in your project that is the best way forward.
    If they won't grant these permissions to your project then you can't run those components under OpenShift.

    For OpenLDAP and PostgreSQL, if you can't run these under OpenShift, maybe you'll have to run LDAP and DB components elsewhere.  This is quite a common pattern for production deployment where IBM Directory Server and IBM DB2 are used for these items.  These products are included as "supporting programmes" in the Verify Access licence.  Other vendor database and LDAP are supported too but, obviously, you'd have to licence them separately.

    For the configuration container, you might consider running it under a local docker environment and building configurations there which you then publish and push into the "worker" containers running under OpenShift.  More complex than you really want for a POC though.  A "snapshot manager" container can be used which can host the snapshots in OpenShift.  The configuration container can publish to it.

    Jon.

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



  • 3.  RE: Forbidden Issue

    IBM Select
    Posted Mon October 25, 2021 08:45 AM
    Thanks Jon, i was able to manage create required constraints. we will go openldap for POC purpose only but our openshift admin will not provide root access as its restricted for use.

    do you see or suggest any other user or work arround for this?

    ------------------------------
    Mayur Wattamwar
    ------------------------------



  • 4.  RE: Forbidden Issue

    IBM Select
    Posted 15 days ago
    Hi Jon,

    post creating security constraint we have faced issue with complete open shift cluster.

    SCC was applied as suggested with priority 10 in security-constraint.yaml, due to its priority it gets picked up by the authentication pods, these are the pods that provide authentication for all users and admin access across the clusters means they are preventing all access to the cluster and also impacting the recovery of the issue (as admins could not get on to rectify).

    when we have checked, this issue was explained at this redhat link and suggest to prioroty should be less than 10. (https://access.redhat.com/solutions/4727461)

    so we have deleted this SCC now. can we make priority less than 10, will it work?

    ------------------------------
    Mayur Wattamwar
    ------------------------------



  • 5.  RE: Forbidden Issue

    Posted 14 days ago
    Hi Mayur,

    I had previously heard that setting SCC priority less than 10 would mean it wouldn't be allocated correctly to pods.  However, I'm no longer sure this is true.  I created the SCC with a priority of 5 and it is still allocated to my config pod.

    Based on this output:
    oc get pod -o 'custom-columns=NAME:metadata.name,APPLIED SCC:metadata.annotations.openshift\.io/scc'
    NAME                                   APPLIED SCC
    verifyaccess-config-7ccc64fdb8-767lt   verifyaccess
    

    I also confirm that oauth-authentication pods are still using anyuid as they should:
    oc -n openshift-authentication get pod -o 'custom-columns=NAME:metadata.name,APPLIED SCC:metadata.annotations.openshift\.io/scc'
    NAME                               APPLIED SCC
    oauth-openshift-544fb649f4-5cnsl   anyuid
    oauth-openshift-544fb649f4-97k5n   anyuid
    oauth-openshift-544fb649f4-zbz98   anyuid
    

    I would suggest you recreate the SCC with priority 5 and re-test.  I am hopeful that it will work.  If you confirm, I will update my scripts.

    Thanks... Jon.

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