Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restore of a pod with volume fails on OpenShift 4 since Velero release 1.15.1 due to seccomp annotation #8616

Closed
berendiwema opened this issue Jan 14, 2025 · 2 comments
Labels
env/openshift Needs triage We need discussion to understand problem and decide the priority

Comments

@berendiwema
Copy link

berendiwema commented Jan 14, 2025

What steps did you take and what happened:
A simple restore of a pod fails using Velero 1.15.1 due to incompatibility with OpenShift's SCC policies. Using Velero 1.15.0, restores are successful.
It looks like 1.15.1 adds the seccompProfile to the velero-restore-helper initContainer which restores the pods' volume(s).

What did you expect to happen:
The restore succeeds.

The following information will help us better understand what's going on:
The log shows:

time="2025-01-13T15:03:29Z" level=error msg="Namespace test-46f27e1e, resource restore error: error restoring pods/test-46f27e1e/pod-94ed0996: pods \"pod-94ed0996\" is forbidden: unable to validate against any security context constraint: pod.metadata.annotations[container.seccomp.security.alpha.kubernetes.io/restore-wait]: Forbidden: seccomp may not be set" logSource="pkg/controller/restore_controller.go:600" 

Anything else you would like to add:
OpenShift does not admit the pod annotated with a seccompProfile, running with the default anyuid SCC. This is expected behaviour.

The anyuid Security Context is not configured with the seccompProfiles as other, for example restricted-v2 SCC.
The SCC was not designed to have the required configuration and currently the default SCC will not work if the deployment has the Seccomp Profiles configured.
The Pod Admission controller will prevent admitting the pod in the cluster.

The annotation was added this commit I believe.

Environment:

  • Velero version 1.15.1
  • OpenShift 4.16

Vote on this issue!

This is an invitation to the Velero community to vote on issues, you can see the project's top voted issues listed here.
Use the "reaction smiley face" up to the right of this comment to vote.

  • 👍 for "I would like to see this bug fixed as soon as possible"
  • 👎 for "There are more important bugs to focus on right now"
@berendiwema berendiwema changed the title Restore of a pod fails on OpenShift 4 since Velero release 1.15.1 due to seccomp annotation Restore of a pod with volume fails on OpenShift 4 since Velero release 1.15.1 due to seccomp annotation Jan 14, 2025
@reasonerjt
Copy link
Contributor

@berendiwema
To workaround this issue you may create a configmap to customize the securityContext of the initcontainer:

https://github.com/vmware-tanzu/velero/blob/main/pkg/restore/actions/pod_volume_restore_action.go#L114

https://velero.io/docs/v1.15/custom-plugins/#plugin-configuration

@reasonerjt reasonerjt added the Needs triage We need discussion to understand problem and decide the priority label Jan 15, 2025
@berendiwema
Copy link
Author

Hello @reasonerjt,

Thank you for your quick reply. I can confirm pod volume restore works using the following configuration:

apiVersion: v1
kind: ConfigMap
metadata:
  name: velero-restore-helper-config
  namespace: velero
  labels:
    velero.io/plugin-config: ""
    velero.io/pod-volume-restore: RestoreItemAction
data:
  secCtxRunAsUser: '1000'
  secCtxAllowPrivilegeEscalation: 'false'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
env/openshift Needs triage We need discussion to understand problem and decide the priority
Projects
None yet
Development

No branches or pull requests

2 participants