SVT: Application failed to Deploy on WLO but Deployed successfully on OLO in a zLinux cluster #691
Assignees
Labels
Comments
abdulmateen-1
changed the title
abdulmateen-1
changed the title
|
@abdulmateen-1 It was mentioned in Slack that OLO version was 1.3.3 while WLO is 1.4.0. Is that correct? Please share the following configurations that were being used during the testing of Instant-On application:
|
|
Yes that is correct. The WLO version is 1.4.0 and the OLO version is 1.3.3. Security Context Constraint yaml file Service Account Configuration details We then add the security context constraint to the service account using this command. Security Context Config in WLO Custom Resource. |
|
@abdulmateen-1 Thank you for the resource details. Deployment is using the default service account that WLO created. It's not using the custom service account Did you configure service account in WebSphereLibertyApplication using FYI, more details on service account configuration with WLO: |
|
I tried the two ways to configure the service account. The first try is described above using .spec.serviceAccountName. When I tried .spec.serviceAccount.name the service account gets configured to instanton-sa but the pods never deployed. |
|
@abdulmateen-1 Thanks for providing the service account details in the Deployment. Could you please also provide the WebSphereLibertyApplication yaml ((including status) for this particular application? |
|
@halim-lee Could you please investigate? I wonder if this is somehow related to the recent seccomp change to set RuntimeDefault. That didn't cause any errors with the restricted-v2 SCC though. The custom SCC |
|
This is the WebSphereLibertyApplication yaml file for this application |
|
@tjwatson saw similar errors when deploying an InstantOn checkpoint image to x86 OCP 4.17.0 using OLO 1.4.0 |
|
From OCP 4.11, the default restricted-v2 SCC sets seccompProfile to runtime/default by default and throws a warning if seccompProfile is not set. We delivered setting RuntimeDefault as the default value for seccompProfile for 1.4.0 release. Now one of below is an available option:
|
|
I tried to add the Here is my deploy yaml: kind: OpenLibertyApplication
apiVersion: apps.openliberty.io/v1
metadata:
name: guide-security
labels:
app: guide-security
spec:
applicationImage: 'docker-na-public.artifactory.swg-devops.com/hyc-wassvt-team-image-registry-docker-local/tjwatson/guide-security-inston'
expose: true
replicas: 1
serviceAccount:
mountToken: true
statefulSet: {}
pullPolicy: Always
pullSecret: artifactory-secret
env:
- name: WLP_LOGGING_CONSOLE_FORMAT
value: simple
serviceAccountName: liberty-instanton-scc
securityContext:
seccompProfile:
type: Unconfined
allowPrivilegeEscalation: true
privileged: false
runAsNonRoot: true
capabilities:
add:
- CHECKPOINT_RESTORE
- SETPCAP
drop:
- ALLAnd here is the yaml used to create the scc: 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: scc-cap-cr
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: RunAsAny
groups:
- system:authenticated
priority: null
readOnlyRootFilesystem: false
requiredDropCapabilities:
- KILL
- MKNOD
- SETUID
- SETGID
runAsUser:
type: RunAsAny
seLinuxContext:
type: RunAsAny
supplementalGroups:
type: RunAsAny
users: []
volumes:
- configMap
- downwardAPI
- emptyDir
- persistentVolumeClaim
- projected
- secretWhere I added the scc and named |
|
@tjwatson Security best practices recommend using the If seccomp must be disabled for InstantOn, then |
|
Should we convert this defect into doc issue to have this documented in the Operator docs? |
|
No I still get |
|
@tjwatson, @Jonathan-Maciel just let me know about another change in operator that
Try to update your app deploy yaml to have the following to see if it helps resolve the problem |
|
@tjwatson Are you still encountering the error/problem after configuring the service account, SCC and security context as per the above suggestions? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We use Websphere Liberty Operator to test new release of Instant-On.
We use the WebSphere Liberty Operator (WLO) to test new releases of Instant-On. While testing Instant-On 24.0.0.10, I encountered an issue where the application pods were not being created.
I was able to deploy the same image successfully using the Open Liberty Operators.
The text was updated successfully, but these errors were encountered: