Building images for your apps

A Docker image is the basis for every container that you create with IBM Cloud® Kubernetes Service.

An image is created from a Dockerfile, which is a file that contains instructions to build the image. A Dockerfile might reference build artifacts in its instructions that are stored separately, such as an app, the app's configuration, and its dependencies.

Deploying containers from an IBM Cloud Container Registry image to the `default` Kubernetes namespace

You can deploy containers to your cluster from an IBM-provided public image or a private image that is stored in your IBM Cloud Container Registry namespace. For more information about how your cluster accesses registry images, see Understanding how your cluster is authorized to pull images from IBM Cloud Container Registry.

Before you begin:

Set up a namespace in IBM Cloud Container Registry and push images to this namespace.
Create a cluster.
Log in to your account. If applicable, target the appropriate resource group. Set the context for your cluster.
Create a deployment configuration file that is named <deployment>.yaml.
Define the deployment and the image to use from your namespace in IBM Cloud Container Registry.
```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: <deployment>
spec:
  replicas: <number_of_replicas>
  selector:
    matchLabels:
      app: <app_name>
  template:
    metadata:
      labels:
        app: <app_name>
    spec:
      containers:
      - name: <app_name>
        image: <region>.icr.io/<namespace>/<image>:<tag>
```
<deployment>

Give your deployment a name.

<number_of_replicas>

Enter the number of replica pods that the deployment creates.

app: <app_name>

Use the name of your app as a label for the container.

name: <app_name>

Give your container a name, such as the name of your app label.

image: <region>.icr.io/namespace>/image>:tag>

Replace the image URL variables with the information for your image:

region>: The regional IBM Cloud Container Registry API endpoint for the registry domain. To list the domain for the region that you are logged in to, run ibmcloud cr api.

namespace>: The registry namespace. To get your namespace information, run ibmcloud cr namespace-list.

image>:tag>: The image and tag that you want to use for your container. To list the images that are available in your registry namespace, run ibmcloud cr images.
Create the deployment in your cluster.
```
kubectl apply -f <deployment>.yaml
```

Referring to the image pull secret in your pod deployment

If the cluster administrator did not store the image pull secret in the Kubernetes service account, all deployments that don't specify a service account can't use the image pull secret to deploy containers. Instead, you can define an image pull secret in your pod deployment. When you refer to the image pull secret in a pod deployment, the image pull secret is valid for this pod only and can't be shared across pods in the Kubernetes namespace.

Before you begin

Create an image pull secret to access images in other registries or Kubernetes namespaces other than default.
Log in to your account. If applicable, target the appropriate resource group. Set the context for your cluster.

To refer to the image pull secret in your pod deployment,

Create a pod configuration file that is named mypod.yaml.
Define the pod and the image pull secret to access images in IBM Cloud Container Registry.

To access a private image,
```
apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: <container_name>
      image: <region>.icr.io/<namespace_name>/<image_name>:<tag>
  imagePullSecrets:
    - name: <secret_name>
```
To access an IBM Cloud public image,
```
apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: <container_name>
      image: icr.io/<image_name>:<tag>
  imagePullSecrets:
    - name: <secret_name>
```
container_name>

The name of the container to deploy to your cluster. namespace_name>

The registry namespace where the image is stored. To list available namespaces, run ibmcloud cr namespace-list. image_name>

The name of the image to use. To list available images in an IBM Cloud account, run ibmcloud cr image-list. tag>

The version of the image that you want to use. If no tag is specified, the image that is tagged latest is used by default. <secret_name>

The name of the image pull secret that you created earlier.
Save your changes.
Create the deployment in your cluster.
```
kubectl apply -f mypod.yaml
```

Pushing images to IBM Cloud Container Registry

After the cluster administrator sets up an image registry with IBM Cloud Container Registry, you can securely store and share Docker images with other users by adding images to your namespace.

For example, you might pull an image from any private or public registry source, and then tag it for later use in IBM Cloud Container Registry. Or, you might push a Docker image that you work with to your namespace so that other users can access the image. To get started, see Adding images to your namespace.

Managing security of images in IBM Cloud Container Registry with Vulnerability Advisor

Vulnerability Advisor checks the security status of container images that are provided by IBM, third parties, or added to your organization's IBM Cloud Container Registry namespace.

When you add an image to a namespace, the image is automatically scanned by Vulnerability Advisor to detect security issues and potential vulnerabilities. If security issues are found, instructions are provided to help fix the reported vulnerability. To get started, see Managing image security with Vulnerability Advisor.

Setting up trusted content for container images

You can build containers from trusted images that are signed and stored in IBM Cloud Container Registry, and prevent deployments from unsigned or vulnerable images.

Sign images for trusted content. After you set up trust for your images, you can manage trusted content and signers that can push images to your registry.
To enforce a policy so that only signed images can be used to build containers in your cluster, install the open source Portieris project.
Cluster users can deploy apps that are built from trusted images.
1. Deploy to the default Kubernetes namespace.
2. Deploy to a different Kubernetes namespace, or from a different IBM Cloud region or account.

Enabling image security enforcement in your cluster

When you enable image security enforcement in your cluster, you install the open-source Portieris Kubernetes project. Then, you can create image policies to prevent pods that don't meet the policies, such as unsigned images, from running in your cluster.

For more information, see the Portieris documentation.

Mutated images: By default, Portieris uses the MutatingAdmissionWebhook admission controller to mutate your image to refer to the image by a digest instead of a tag. However, you might have some deployment technology that rejects a mutated image. If so, you can use the image mutation option and policy to change the default behavior.

Enabling or disabling image security enforcement

You can enable or disable image security enforcement for your cluster from the CLI or console. For earlier versions, see the Portieris documentation.

Enabling or disabling image security enforcement with the CLI

See the following commands.

Enabling or disabling image security enforcement from the console

From the Kubernetes clusters console, select your cluster.
From the Overview tab, in the Summary pane, find the Image security enforcement field and click Enable or Disable.

Default image policies

When you enable image security enforcement, IBM Cloud Kubernetes Service automatically creates certain image policies in your cluster. When you disable the feature, the underlying ClusterImagePolicy CRD is removed, which removes all the default image policies and any custom images policies that you created.

Image policies with the name ibm-signed-image-enforcement restrict the images that are run in the namespace to IBM Cloud Kubernetes Service images only. Do not modify these image policies. Any changes that you make are overwritten within a few minutes.
Other image policies, such as default or default-allow-all, permit images that are not restricted by another image policy. You can modify these image policies and your changes are preserved, but don't rename the image policy. If you rename the policy, more policies with the default name and settings are created.

To review the image policies in your cluster,