If something happens during the build process, or if a vulnerability is discovered after an image has been deployed, you can use tooling for automated, policy-based deployment. You can use triggers to rebuild and replace images instead of patching running containers, which is not recommended.
For example, you build an application using three container image layers: core, middleware, and applications. An issue is discovered in the core image and that image is rebuilt. After the build is complete, the image is pushed to the OpenShift Container Registry. OKD detects that the image has changed and automatically rebuilds and deploys the application image, based on the defined triggers. This change incorporates the fixed libraries and ensures that the production code is identical to the most current image.
oc set triggers command can be used to set a deployment trigger for a
deployment configuration. For example, to set an
ImageChangeTrigger in a
deployment configuration called
$ oc set triggers dc/frontend \ --from-image=myproject/origin-ruby-sample:latest \ -c helloworld
Secret object type provides a mechanism to hold sensitive information such
as passwords, OKD client configuration files, dockercfg files,
and private source repository credentials. Secrets decouple sensitive content
from pods. You can mount secrets into containers using a volume plug-in or the
system can use secrets to perform actions on behalf of a pod.
For example, to add a secret to your deployment configuration using the web console so that it can access a private image repository:
Create a new project.
Navigate to Resources → Secrets and create a new secret. Set Secret Type to Image Secret and Authentication Type to Image Registry Credentials to enter credentials for accessing a private image repository.
When creating a deployment configuration (for example, from the Add to Project → Deploy Image page), set the Pull Secret to your new secret.
ConfigMaps are similar to secrets, but are designed to support working with
strings that do not contain sensitive information. The
ConfigMap object holds
key-value pairs of configuration data that can be consumed in pods or used to
store configuration data for system components such as controllers.
You can use security context constraints (SCCs) to define a set of conditions that a pod (a collection of containers) must run with in order to be accepted into the system.
Some aspects that can be managed by SCCs include:
Running of privileged containers.
Capabilities a container can request to be added.
Use of host directories as volumes.
SELinux context of the container.
Container user ID.
If you have the required permissions, you can adjust the default SCC policies to be more permissive.