FAQs

IBM Hyper Protect Virtual Servers provides a secure virtualized infrastructure for private cloud deployments - protecting the entire lifecycle of critical Linux workloads during their build, deployment and management.

Application developers and ISVs can securely build applications with integrity.

Cloud administrators or system administrators can help manage their layer of the IT infrastructure without having access to the higher level applications and sensitive data.

Solution end-users can ensure the provenance of the applications being deployed by validating that applications originate from a trusted source.

Secure Service Container framework provides the base infrastructure for an integration of operating system, middleware, and software components into an appliance with extra security. In addition to extra security based on the runq container environment, the host operating system itself is also extremely secure. The Secure Service Container framework works autonomously and provides core services and infrastructure focusing on consumability and security.

A hosting appliance is a software appliance built with the Secure Service Container Framework, and adds the capability to securely run containerized workloads.

A software appliance is an integrated software containing an operating system, libraries, and so on to fulfill a single purpose, which can be installed as an appliance image on IBM Z or LinuxONE servers.

As long as your applications are developed based on Open Container Initiative (OCI) specification, you can use them in IBM Hyper Protect Virtual Servers.

Yes. You can either use the docker trust key generate command to generate the signing key pair, or use the docker trust key load command to load an existing key for signing. However, passing in an existing key pair would invalidate the Secure Build concept as the private trust key exists(existed) outside of the Secure Build, and therefore someone else could use that key to push a bad image to the same docker repo.

The docker push command establishes trust at the time the first push to the docker repo is done. The command uses DOCKER_CONTENT_TRUST environment variables to determine where to establish the trust with.

The Secure Build container is created on the hosting appliance when you run the securebuild create command.

The docker repo key pair is generated on the first build when the docker push command is executed.

The manifest signing keys are generated inside the Secure Build server container on first creation of a manifest by a Secure Build instance. It then uses gpg to sign the manifest tar file and will optionally push that signed tar to an external Cloud Object Store. The manifest and public key to validate the signature can also be retrieved from the Secure Build using the cli.

Yes. The newly built image must have a new name so that DCT can be established by the Secure Build server container.