Documentation on OCP supported versions for InstantOn

[tjwatson]

Not sure if we should put this directly in the InstantOn documentation or into the general Liberty documentation for OCP support.

[tjwatson]

@tam512 could you provide the instructions you use to setup the necessary Linux capabilities with OCP 4.14 so we can add that to the InstantOn documentation?

[tam512]

First I use the following steps provided by @anjumfatima90 to create service account and security context constraints

1. Create a service account from command line by running following command.  Note that  you can use any serviceaccount name instead of instanton-sa, but you need to refer to that name in the later steps.
    a. oc create serviceaccount instanton-sa

2. Add the security constraints to the service account.
    a. Create a file scc-cap-cr.yaml. Add the following in the file

allowHostDirVolumePlugin: true
allowHostIPC: false
allowHostNetwork: false
allowHostPID: false
allowHostPorts: false
allowPrivilegeEscalation: true
allowPrivilegedContainer: false
allowedCapabilities: null
apiVersion: security.openshift.io/v1
defaultAddCapabilities:
- CHECKPOINT_RESTORE
- SETPCAP
fsGroup:
  type: MustRunAs
groups:
- system:authenticated
kind: SecurityContextConstraints
metadata:
  annotations:
    kubernetes.io/description: criu-scc is based on the restricted SCC but removes any restrictions
      that prevent the restore image from running successfully.
  generation: 1
  name: cap-cr-scc
priority: null
readOnlyRootFilesystem: false
requiredDropCapabilities:
- KILL
- MKNOD
- SETUID
- SETGID
runAsUser:
  type: RunAsAny
  #uid: 1001
seLinuxContext:
  type: MustRunAs
supplementalGroups:
  type: RunAsAny
users: []
volumes:
- configMap
- downwardAPI
- emptyDir
- persistentVolumeClaim
- projected
- secret


3. Apply the scc to the service account by running following commands
    a. oc apply -f scc-cap-cr.yaml
    b. oc adm policy add-scc-to-user cap-cr-scc -z instanton-sa
    Note: In the above command the name of the yaml file doesn't matter, it's the name specified inside the file.

Then deploy the OpenLibertyApplication or WebSphereLibertyApplication using Open Liberty operator or WebSphere Liberty operator as normal with the addition of the service account and securityContext in the yaml as following:

• Note that my_checkpoint_app_image was created on a Linux VM that has kernel level greater than or equal to 5.9 to perform checkpoint then pushed to a registry that can be pulled from OCP

• For OpenLibertyApplication

apiVersion: apps.openliberty.io/v1
kind: OpenLibertyApplication
metadata:
  name: myapp
spec:
  applicationImage: some_registry/my_checkpoint_app_image
  ...........................
  serviceAccountName: instanton-sa
  securityContext:
    allowPrivilegeEscalation: true
    privileged: false
    runAsNonRoot: true
    capabilities:
      add:
      - CHECKPOINT_RESTORE
      - SETPCAP
      drop:
      -  ALL

• For WebSphereLibertyApplication

apiVersion: liberty.websphere.ibm.com/v1
kind: WebSphereLibertyApplication
metadata:
  name: myapp
spec:
  license:
    accept: true
  applicationImage: some_registry/my_checkpoint_app_image
  ..........................
  serviceAccountName: instanton-sa
  securityContext:
    allowPrivilegeEscalation: true
    privileged: false
    runAsNonRoot: true
    capabilities:
      add:
      - CHECKPOINT_RESTORE
      - SETPCAP
      drop:
      - ALL

[tjwatson]

runAsUser:
  type: MustRunAs
  uid: 1001

We should not need to run with 1001 anymore. @tam512 are you still testing with that?

[tam512]

yes I still have the run with 1001 in scc-cap-cr.yaml. I will take it out in the next test.

[dmuelle]

Hi @tjwatson - as discussed, I added a bullet for OCP 4.14+ here:

https://docs-draft-openlibertyio.mqj6zf7jocq.us-south.codeengine.appdomain.cloud/docs/latest/instanton.html#_deploying_an_instanton_application_to_kubernetes_services

For the OCP Linux Capabilities- should we include the full procedure @tam512 posted? Or are those internal instructions? Would the content belong in a new subsection of "Running and deploying an InstantOn application image" ?

[tjwatson]

It is probably not a good idea to spell out the YAML like that in the documentation.

Instead we can refer to the OCP documentation for managing SCCs (https://docs.openshift.com/container-platform/4.14/authentication/managing-security-context-constraints.html) and state that InstantOn requires an SCC that at a minimum grants the additional capabilities to the defaults needed for InstantOn.
Then put a for example, by using an SCC with:

defaultAddCapabilities:
- CHECKPOINT_RESTORE
- SETPCAP

Then state that applications deployed must be associated with the named SCC. For example, by using the serviceAccountName setting and allows escalation of the required capabilities when deploying the application with the following:

  serviceAccountName: <SCC name>
  securityContext:
    allowPrivilegeEscalation: true
    privileged: false
    runAsNonRoot: true
    capabilities:
      add:
      - CHECKPOINT_RESTORE
      - SETPCAP
      drop:
      - ALL

Where <SCC name> is the name of the SCC they deployed that grants the necessary capabilities for InstantOn.

[dmuelle]

Hi Thomas- the draft is now updated

https://docs-draft-openlibertyio.mqj6zf7jocq.us-south.codeengine.appdomain.cloud/docs/latest/instanton.html#_deploying_an_instanton_application_to_kubernetes_services

if any further edits are needed, just let me know. Otherwise, you can add the technical reviewed label to this issue to sign off. Thanks!

[dmuelle]

@ramkumar-k-9286 - this is ready for peer review

• https://docs-draft-openlibertyio.mqj6zf7jocq.us-south.codeengine.appdomain.cloud/docs/latest/instanton.html#_deploying_an_instanton_application_to_kubernetes_services

[ramkumar-k-9286]

Peer Review

Red Hat OpenShift (version 4.14 and later)
->
Red Hat OpenShift (version 4.14 and later)

---

To deploy applications to Red Hat OpenShift with InstantOn, you must specify a security context constraint (SCC) that at a minimum specifies a list of additional capabilities that are added to any pod.
->
To deploy applications to Red Hat OpenShift with InstantOn, you must specify a security context constraint (SCC) that, at a minimum, specifies a list of additional capabilities that are added to any pod.
Also -> Acrolinx has an issue with additional

The following SSC yaml file example defines an SCC with the required capabilities by using the defaultAddCapabilities parameter :
->
The following SSC yaml file example defines an SCC with the required capabilities by using the defaultAddCapabilities parameter:

---

The applications you deploy must be associated with an SCC that adds the required capabilities.
->
The applications that you deploy must be associated with an SCC that adds the required capabilities.
Also -> Acrolinx has an issue with required -> can we use needed

---

The following deployment yaml file example specifies the serviceAccountName parameter to set the SCC name to liberty-instanton-scc:
->
In the following example, the deployment yaml file specifies the serviceAccountName parameter to set the SCC name to liberty-instanton-scc:

---

[dmuelle]

thanks Ram, changes implemented