vania-janet/multiturn-rag-retrieval-data huggingface dataset:
You can also refer to the image name by using a combination of the content of the Repository column (repository) and one of the tags in the Tags column (tag) separated by a colon (:) to create the image name in the format repository:tag.

From version 1.0.0 of the container-registry plug-in, you can choose whether to run the ibmcloud cr vulnerability-assessment command in either version 3 (the default) or version 4 of Vulnerability Advisor. If you want to run Vulnerability Advisor in a different version, see [Setting the Vulnerability Advisor version](https://cloud.ibm.com/docs/Registry?topic=Registry-va_index&interface=uiva_set_version). For more information about the versions of Vulnerability Advisor, see [About Vulnerability Advisor](https://cloud.ibm.com/docs/Registry?topic=Registry-va_index&interface=uiabout).

ibmcloud cr image-digests [--format FORMAT | --quiet | -q | --json] [--restrict RESTRICTION] [--include-ibm] [--no-va] [--va]



 Prerequisites 

To find out about the required permissions, see [Access roles for using Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-iamaccess_roles_using).





 Command options 

--format FORMAT
: (Optional) Format the output elements by using a Go template. For more information, see [Formatting and filtering the Container Registry CLI output](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_cli_list).

--quiet, -q
: (Optional) Each image is listed in the format: repository@digest

--json
: (Optional) Outputs the list in JSON format.

--restrict RESTRICTION
: (Optional) Limit the output to display only images in the specified namespace or repository.

--include-ibm
: (Optional) Includes IBM-provided public images in the output. By default only private images are listed. You can view IBM-provided images in the global registry only.
For more information, see [IAM access policies are required from 5 July 2022](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_notices_iam_policy).

ibmcloud cr iam-policies-status





 ibmcloud cr image-digests (ibmcloud cr digests) 

Lists all images, including [untagged](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_untagged) images, in your IBM Cloud account. This command returns the [digest](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_digest) in its long format. When you're using the digest to identify an image, always use the long format.

If you want to list tagged images only, run the [ibmcloud cr image-list](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_list) command.

You can refer to an image by using a combination of the Repository column (repository) and the Digest column (digest) separated by an at (@) symbol to create the image name in the format repository@digest. You can also refer to the image name by using a combination of the content of the Repository column (repository) and one of the tags in the Tags column (tag) separated by a colon (:) to create the image name in the format repository:tag.

From version 1.0.0 of the container-registry plug-in, you can choose whether to run the ibmcloud cr vulnerability-assessment command in either version 3 (the default) or version 4 of Vulnerability Advisor. If you want to run Vulnerability Advisor in a different version, see [Setting the Vulnerability Advisor version](https://cloud.ibm.com/docs/Registry?topic=Registry-va_index&interface=uiva_set_version). For more information about the versions of Vulnerability Advisor, see [About Vulnerability Advisor](https://cloud.ibm.com/docs/Registry?topic=Registry-va_index&interface=uiabout).
By default, the ibmcloud cr image-list command returns the [digest](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_digest) for the images in a truncated format. The ibmcloud cr image-digests command returns the long format of the digest.

When you're using the digest to identify an image, always use the long format.

The image name is the combination of the content of the Repository and Tag columns in the format: repository:tag

From version 1.0.0 of the container-registry plug-in, you can choose whether to run the ibmcloud cr vulnerability-assessment command in either version 3 (the default) or version 4 of Vulnerability Advisor. If you want to run Vulnerability Advisor in a different version, see [Setting the Vulnerability Advisor version](https://cloud.ibm.com/docs/Registry?topic=Registry-va_index&interface=uiva_set_version). For more information about the versions of Vulnerability Advisor, see [About Vulnerability Advisor](https://cloud.ibm.com/docs/Registry?topic=Registry-va_index&interface=uiabout).

If the command to list images times out, see [Why is it timing out when I list images?](https://cloud.ibm.com/docs/Registry?topic=Registry-troubleshoot-image-timeout) for assistance.

ibmcloud cr image-list [--format FORMAT] [--quiet | -q ] [--restrict RESTRICTION] [--include-ibm] [--no-trunc] [--show-type] [--no-va] [--va]



 Prerequisites 

To find out about the required permissions, see [Access roles for using Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-iamaccess_roles_using).





 Command options 

--format FORMAT
: (Optional) Format the output elements by using a Go template.
By default is set to true. For more information, see [Working with captures](https://cloud.ibm.com/docs/monitoring?topic=monitoring-capturescaptures).
* Add --imageanalyzer --analysismanager https://<COLLECTOR ENDPOINT>/internal/scanning/scanning-analysis-collector to install the image analyzer component. Configure this component when you have images that are hosted in the Container Registry.
* Add --nodeanalyzer --analysismanager https://<COLLECTOR ENDPOINT>/internal/scanning/scanning-analysis-collector --api_endpoint <API-ENDPOINT>to install image-analyzer, host-analyzer, and benchmark runner. The API_ENDPOINT is needed by the benchmark runner. The COLLECTOR_ENDPOINT is needed by the image analyzer.
* Add the option that defines the type of agent that you want to deploy:



* -as to deploy a slim agent. This is the default option. Use this option to reduce the surface area of attack for potential vulnerabilities. When you deploy the agent, you install the agent package as two containers, one running the agent-kmodule and the other running the agent-slim.
* -af to deploy the full agent. When you deploy the agent, the agent runs as a single container or a service.





To deploy the agent by using a public endpoint, run the following command:

curl -sL https://ibm.biz/install-sysdig-k8s-agent | bash -s -- -a ACCESS_KEY -c ingest.<REGION>.monitoring.cloud.ibm.com -t TAG_DATA -ac 'sysdig_capture_enabled: false' --nodeanalyzer --analysismanager https://ingest.<REGION>.monitoring.cloud.ibm.com/internal/scanning/scanning-analysis-collector --collector_port 6443 --api_endpoint <REGION>.monitoring.cloud.ibm.com [-as] [-af]

{: codeblock}api

To deploy the agent by using a private endpoint, run the following command:
To use Vulnerability Advisor to check the security of your image, see [Managing image security with Vulnerability Advisor](https://cloud.ibm.com/docs/Registry?topic=Registry-va_index&interface=ui).





 Pushing images by using an API key 

Create a service ID that uses an

API keyto push images to IBM Cloud Container Registry.

Complete the following steps:



1. Create a service ID, see [Creating and working with service IDs](https://cloud.ibm.com/docs/account?topic=account-serviceidsserviceids).
2. Create a policy that gives the service ID permission to access the registry, for example, Administrator and Manager roles, see [Managing IAM access for Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-iam).
3. Create an API key, see [Creating an API key for a service ID](https://cloud.ibm.com/docs/account?topic=account-serviceidapikeyscreate_service_key).
4. Use the API key to log in to registry so that you can push images to the registry, see [Automating access to IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_access).
5. Push your images, see [Pushing Docker images to your namespace](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_images_registry_images_pushing_namespace).



You can now use clusters to pull the images, see [Building containers from images](https://cloud.ibm.com/docs/containers?topic=containers-images).





 Removing tags from images in your private repository
: V2.4.5 is supported which fixes an issue when using --verbose with --format json resulting in corrupted JSON output.





 28 July 2021 

Secure support for Inline Scanner
: V2.4.4 is supported including the following updates:



* Security fixes.
* Adding a retry mechanism when pulling images from registries.
* Adding the ability to write a JSON log to a file.
* Fixed a malware scan issue.
* Fixed issue when getting images for registries not supporting tag listing.







 27 July 2021 

Secure support for Kubernetes Audit functionality
: General available support of Kubernetes Audit functionality as part of the Admission Controller.





 2 July 2021 

Secure support for Inline Scanner
: V2.4.3 is supported including security fixes and a problem with incorrect version detection for Apache Struts 2.





 1 July 2021 

Secure support for Node Image Analyzer
: V0.1.13 is available.





 14 June 2021 

Secure support for RedHat OpenShift Container Platform v4 benchmark
: You can now scan and validate compliance with the controls included in the CIS benchmark requirements.





 9 June 2021 

Secure change improvements to navigation and activity audit
: Updates include:



* Moving Network from under Policies in the menu.
* Grouping Activity Audit and Captures into the Investigation menu item.
* Runtime scope moved in Activity Audit to allow more space for activity data.
* Activity types can be filtered directly from the graph.
* Displayed element attributes can be filtered from the list.







 4 June 2021 

Secure changes to Kubernetes network security configuration and user experience
: Changes include:



* New configuration panel allowing you to include or exclude a set of labels for a cluster or namespace.
* Adding the ability to label IPs not mapped to Kubernetes or OpenShift entities.
* Adding the ability to to configure internal subnets for clusters.
* Adding additional information when hovering over a network connection or network node.
* Adding unresolved IP filtering.
* Adding Network as an item in the navigation.







 1 June 2021 

PromQL library
It contains the source code from which the image was built as well as the build log. You can download the manifest file from the Secure Build Server, and, for example, use it for audit purposes or pass it to an auditor. The manifest file is signed by signing keys that are kept inside the secure enclave.
* Secure Build Server creates an encrypted registration file, which can be used to provision an instance of the application on Hyper Protect Virtual Servers by using Bring Your Own Image (BYOI).



Zoom

![The Secure Build Server](https://cloud.ibm.com/docs-content/v1/content/29e0ddc9fd7149f916889ba6a4d131cc3528c9bc/hp-virtual-servers/image/secure-build.png)

Figure 1. The Secure Build Server

The registration file specifies the container registry, the application image, and the credentials that are required to access the container registry. The registration file is encrypted and can be decrypted by Hyper Protect Virtual Servers only.

You can download and use the encrypted registration file yourself, or you can pass it to a cloud administrator who uses the registration file and the Hyper Protect Virtual Servers CLI to provision a Hyper Protect Virtual Servers server instance with your image. The cloud administrator cannot access the information that is included in the registration file, namely the container registry credentials because the registration file is encrypted. In consequence – given access control is correctly set up for the container registry and the credentials are not exposed, the cloud administration cannot download or access the application image and any secrets that are contained in the image.





 Digital wallets 

As digital wallets are targeted by hackers, it is important that the digital assets be protected in an environment that is also easily accessible by the user (known as a "hot wallet"). A protected environment is an environment where both privileged admins and external threats cannot compromise the data, thru encryption and other mechanisms. In addition, the application must be built in a secure environment that uses a Secure Build process that prevents malicious actors from tampering the application code and application image.
5 January 2021 

Improved alerts
: The alert interface has been improved for faster browsing and easier management.





 23 December 2020 

Secure support for Jenkins
: Plug-in V2.1 is available with the following changes:



* Improved scanning performance and execution.
* Proxy support for master and worker nodes.







 16 December 2020 

Secure support for Node Image Analyzer
: V0.1.7 is available. This release fixes image analysis errors for OpenShift clusters configured in FIPS mode.





 14 December 2020 

Secure support to scan images as a GitHub action
: Support to do image analysis on locally built container images.





 11 December 2020 

Secure support runtime policy events JSON format
: A new JSON format for runtime policy events including full scope information, rule labels, and a single-line representation for event field keys and values.





 7 December 2020 

Secure support for Node Image Analyzer
: V0.1.6 is available with the following changes:



* Proxy configuration support to run the analyzer behind a proxy.
* Support to scan images without a Repo tag.







 2 December 2020 

Secure support for inline scanner
: V2.2 is available with the following changes:



* Vulnerability report added to the container output.
* Scanned images using the digest pullstring is stored using the truncated digest as a tag.
* Users running other than as root have a permission issue resolved.







 23 November 2020 

Secure support for inline scanner
: V2.1 is available with the following changes:



* The ability to analyze scratch-based images.
* Fixes for retrieved PDF output for previously scanned images.
* Fixes for container vulnerabilities.







 20 November 2020 

Secure support
: In architectures that are focused on container and microservices, you can use Secure to protect, monitor, and enhance forensic analysis of your pipeline and runtime components. [Learn more](https://cloud.ibm.com/docs/monitoring?topic=monitoring-getting-started-secure)





 19 November 2020 

Enhancements to Explore
: A new grouping editor helps you create and manage infrastructure groupings.

Dashboard ownership
* com.ibm.code_bom_check
* com.ibm.code_cis_check
* com.ibm.cloud.image_vulnerability_scan
* com.ibm.cloud.image_signing
* com.ibm.dynamic_scan
* com.ibm.acceptance_tests
* com.ibm.prod_change_request
* com.ibm.close_change_reques





 Asset requirements 

Evidence that is collected with this tool is part of the V2 evidence collection work and the related evidence locker updates.

This new method focuses on asset-based evidence, meaning that evidence is connected to the artifact and repo through the scans and tests that run on those artifacts or repos, and produced results for evidence. For example:



* A repo with a certain commit becomes a commit asset, which is scanned, creating evidence for the commit asset.
* Using the same repo and commit, an image is built. The image becomes an asset that is related to the source asset, the repo and commit.
* The image is scanned, and evidence is created. All scan results are connected through the evidence, its asset, and the related assets.



To make all this work together, the assets that are provided with the parameters --asset-type and --asset-key must comply with some requirements:



 repo assets added by using the save_repo command 

Check the [command reference](https://cloud.ibm.com/docs/devsecops?topic=devsecops-devsecops-pipelinectlsave_repo) for exact usage information.

Required fields:



* url
The repository URL.
* commit
The commit SHA.







 artifact assets added by using the save_artifact command 

Check the [command reference](https://cloud.ibm.com/docs/devsecops?topic=devsecops-devsecops-pipelinectlsave_artifact) for exact usage information.

Required fields:



* name
The artifact name. For example, for an image include registry, namespace, and image (example: us.icr.io/team-images/service).
* digest
For information about supported Docker base images, see [Vulnerable packages](https://cloud.ibm.com/docs/Registry?topic=Registry-va_index&interface=uipackages).

For more information, see [Managing image security with Vulnerability Advisor](https://cloud.ibm.com/docs/Registry?topic=Registry-va_index&interface=ui).

--extended, -e
: (Optional) The command output shows additional information about fixes for vulnerable packages.

--vulnerabilities, -v
: (Optional) The command output is restricted to show vulnerabilities only.

--configuration-issues, -c
: (Optional) The command output is restricted to show configuration issues only.

--output FORMAT, -o FORMAT
: (Optional) The command output is returned in the chosen format. The default format is text.

The following formats are supported:



* text
* json







 Examples 

View a standard vulnerability assessment report for your image.

ibmcloud cr vulnerability-assessment us.icr.io/birds/bluebird:1

View a vulnerability assessment report for your image us.icr.io/birds/bluebird:1 in JSON format, showing vulnerabilities only.

ibmcloud cr vulnerability-assessment --vulnerabilities --output json us.icr.io/birds/bluebird:1
Code Risk Analyzer can also perform auto-remediation on vulnerable packages for Node.js based applications only. You can also generate this report in the standard format or in CycloneDX's Vulnerability Exploitability Exchange (VEX) format.

ibmcloud cra vulnerability-scan



 Vulnerability scan command options 

The following table lists the options for using the vulnerability-scan command.



Table 3. Command options for performing a vulnerability scan

 Command options Required or optional Description 

 -b, --bom Required The file path of the BOM file that was generated by using the bom-generate command. This BOM file must be in standard format. 
 -a, --autofix Optional Fixes specific types of app vulnerabilities. This option is available only for Node.js apps. 
 -f, --commentfile Optional Specifies the file where the markdown report is created. This command is available only with autofix. 
 -c, --cveignore Optional The file path of the CVE Ignore file that contains the list of CVEs to ignore. 
 -e, --excludedev Optional Specifies that you do not want the command to report CVEs for development dependencies. 
 --force Optional Forces an update for top-level node packages, even when the major version is different. This command is available only with autofix. 
 --include-nofix Optional Include or exclude the reporting of CVEs that do not have known remediations. By default, this option is set to app. The app option is used to include only app package CVEs with no fixes. The os option is used to include only OS package CVEs with no fixes. The all option is used to include both app and OS package CVEs with no fixes. The none option is used to exclude both app and OS package CVEs with no fixes. 
 --path Required if --autofix enabled The project directory path to scan. This command is available only with autofix. 
 --region Optional The ibmcloud region for the toolchain. 
 -r, --report Optional The path to the generated report.
[Encrypting images for content confidentiality](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_encrypt)Encrypting images for content confidentiality

You can protect the confidentiality of your IBM Cloud® Container Registry images, and ensure that hosts that aren't trusted can't run the images.

Key Protect Container Registry



* 2 hours
* 2023-01-25



[Creating an IBM Cloud Kubernetes Service cluster on VPC infrastructure](https://cloud.ibm.com/docs/schematics?topic=schematics-provisioning-terraform-template)Creating an IBM Cloud Kubernetes Service cluster on VPC infrastructure

Use one of the IBM® provided templates to create an IBM Cloud® Kubernetes Service cluster in a Virtual Private Cloud (VPC). Then, you bind the cluster to an IBM Cloud® Object Storage service instance.

Schematics Kubernetes service

+1

Key Protect



* 60 minutes
* 2023-05-26



[Process big data logs with SQL](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-big-data-log-analytics)Process big data logs with SQL

In this tutorial, you will build a log analysis pipeline designed to collect, store and analyze log records to support regulatory requirements or aid information discovery. This solution leverages several services available in IBM Cloud: Event Streams, Object Storage, Data Engine (previously SQL Query), Key Protect, and IBM Analytics Engine. A script and tool will assist you to simulate the transmission of web server log messages from a static file to Event Streams.

Object Storage Event Streams

+3

Analytics Engine,Data Engine,Key Protect



* 3 hours
* 2023-05-05



[Getting started with Secrets Manager](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-getting-started)Getting started with Secrets Manager

This tutorial focuses on storing and managing a username and password in IBM Cloud® Secrets Manager.
Find a person or team in your organization who is responsible for monitoring and removing vulnerabilities. Depending on your organizational structure, this person might be part of a security, operations, or deployment team. Enable [content trust](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_trustedcontentregistry_trustedcontent) so that images must be approved by a trusted signer before they can be pushed to the container registry. Then, [install the open source Portieris project](https://github.com/IBM/portieris) admission controller to block container deployments from unsigned images.
3. Regularly scan running containers:. Even if you deployed a container from an image that passes the vulnerability check, the operating system or binaries that run in the container might get vulnerable over time. To protect your app, you must ensure that running containers are regularly scanned so that you can detect and remediate vulnerabilities. Depending on the app, to add extra security, you can establish a job that takes down vulnerable containers after they are detected.



Zoom

![Deploying containers with trusted content](https://cloud.ibm.com/docs-content/v1/content/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/containers/images/cs_image_security.png)

Figure 1. Deploying containers with trusted content

)



Security for images and deployments

 Security feature Description 

 Secured Docker private image repository in IBM Cloud Container Registry Set up your own Docker [image repository](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-startedgetting-started) in a multi-tenant, highly available, and scalable private image registry that is hosted and managed by IBM. By using the registry, you can build, securely store, and share Docker images across cluster users. /n Learn more about [securing your personal information](https://cloud.ibm.com/docs/containers?topic=containers-securitypi) when you work with container images.