Tutorials
  • Welcome to Ozone
  • Quick Onboarding
    • Creating a New Project
    • Creating Environments
    • Adding a Registry
    • Adding a Repository
    • Attaching Clusters
    • Creating a Microservice
    • Using out-of-the-box Pipeline Templates
    • Creating a new pipeline on the Ozone Pipeline Studio
    • Configuring Triggers for Automated Deployments
    • Adding a CD Provider
      • Jenkins Pipeline
  • Documentation
    • Dashboard
      • Ozone Dashboard
      • Analyze Metrics & Logs for Kubernetes Clusters
    • CI/CD
      • Create Microservice
        • Link a Git Repo
        • Map a Registry
        • Map to Environments
        • Build Config (Specify where the Docker file exists)
      • Link Pipelines to your Microservice
        • Default Pipelines that are linked
        • What are Input Sets?
        • Execute a linked pipeline
      • Catalog
        • External Pipelines
          • Supported Integrations
          • How to Link an External CI Integration
          • Conversion Of external pipelines to Tekton Pipelines
        • Tasks
          • Create a Custom task
        • Releases (Templates and Runs)
          • What are releases composed of (Pipelines & Approvals)
          • Create a Release Template
          • Run a Release Template
        • Running Your First Pipeline
        • Pipelines (Templates & Runs)
          • Adding Nodes to Canvas
          • Configuring Rollbacks at Pipeline Template
          • Secret Injection + Secrets
          • Input-result mapping between tasks
        • Initiating Pipeline run
          • Manually
      • Triggers
        • Scheduling a pipeline and/or a release run
        • Triggering a pipeline and/or a release run
          • From Github events
          • From GitLab events
          • From Jira events
          • Custom Webhook
          • From Harbor events
          • From Azure DevOps events
          • From Bitbucket events
          • From Dockerhub events
      • Observe your Microservice
      • Verify Your Microservice With AI
    • Helm
      • Create a Helm Channel
      • Create a Helm Release
      • Edit a Helm Release
    • DevSecOps
      • Security Dashboard
      • Scans
      • Supported Integrations
      • Run Your First Security Pipeline
      • Shift Left Policy Management
        • Policies
    • Backups
      • Pre-requisites
      • How do I schedule a backup to create snapshots?
      • How to take snapshots and how do I know the status of backups?
      • How do I restore snapshots to clusters?
    • Setup
      • Manage Cluster
        • Public Cluster
        • Reattach Cluster
      • Setting up Environments
      • Manage Secret
      • Manage Repos
      • Manage Registries
      • Integrations
        • Managing Cloud Integrations
          • AWS
          • Azure
          • GCP
        • Managing Source Code Integrations
          • GitHub
          • GitLab
          • Bit bucket
          • Azure DevOps Repos
          • Git Repo
          • Bitbucket Datacenter
        • Managing Container Registry
          • Docker
          • GCR
          • Harbor
          • Quay
          • Azure ACR
          • Adhoc Registry
        • Managing Container Orchestration
          • AWS EKS
          • GKE
          • Azure AKS
        • Managing Issue Trackers
        • Managing Continuous Deployment
          • Argo CD
          • Azure DevOps
          • Ansible Tower
        • Managing SSO
        • Managing Private Catalogs
        • Managing Notifications
        • Managing Security
          • Snyk
          • Prisma Cloud
        • Managing APM
          • NewRelic
        • Managing Cloud Storage
          • Minio
          • AWS S3 Bucket
          • Google Cloud Storage
          • Azure Blob Storage
        • Managing Network Tunnels
        • Manage Testing
          • K6
        • Managing Secret Store
          • Azure Key Vault
          • Google Secret Manager
          • AWS Secrets Manager
          • Hashicorp Vault
    • Settings
      • Role Based Access Control
        • Create a new role
        • Clone an Existing Role
        • Apply a role to a member
      • Ozone Identity Management
      • Audit Trails
      • Private Cluster Management
      • SSO
        • Pre-Requisites
        • Azure AD
      • Projects
        • Create a new Project
        • Archive a Project
        • Import and remove resources into the project
        • Add Members to a Project
      • Setup Alerts and Notifications
  • Release Notes
    • August - 2024
    • July - 2024
    • June - 2024
    • April - 2024
    • February - 2024
    • November - 2023
    • October - 2023
    • September - 2023
    • August - 2023
    • July - 2023
    • June - 2023
    • May - 2023
    • April - 2023
    • September - 2022
    • August - 2022
    • July - 2022
    • May - 2022
    • April - 2022
    • Mar - 2022
    • Jan - 2022
    • Nov - 2021
  • FAQ
    • In House Applications
    • COTS Applications
    • Tasks
    • Pipelines
    • Releases
    • Projects
    • Members
    • Environments
    • Variables
    • Roles
  • Use Cases
    • For Platform Engineers
      • Standardized Application Delivery Workflows
      • Unified Observability and Alerting
      • On Demand Workload Recovery
    • For Software Developers
      • On Demand Delivery
      • Scalable and Re-usable Workflows
Powered by GitBook
On this page
  1. Documentation
  2. DevSecOps
  3. Shift Left Policy Management

Policies

PreviousShift Left Policy ManagementNextBackups

Last updated 10 months ago

Users can create policies using Ozone's Security Policies functionality according to the Critical, High, Medium, and Low vulnerability severity categories. You have the flexibility to stop pipelines from further executing once a vulnerability is found which violates the policy With this feature, users can specify their desired actions for each severity level. For example, they can choose to block any container image with Critical and High vulnerabilities, while allowing container images with Medium and Low vulnerabilities to be deployed.

Examples of Defining a Policy:

  • Users can block all vulnerabilities

  • Users can block Critical and High vulnerabilities and allow medium and low vulnerabilities

  • Users can block all vulnerabilities for one application and can block only critical vulnerabilities for other applications

  • Users can block those vulnerabilities for which a fix is already available

However, if you define policies at more than one level, the order of precedence would be as follows:

  • Microservices (highest priority)

  • Cluster

  • Environments

  • Global

Configure Global Security Policy: Within The Global Security Policies ,there are two options available:

Option
Description

Block

Allow

If critical vulnerabilities are blocked in the Global Security Policy, the same blocking will be applied to the Cluster Security Policy. Likewise, allowing critical levels in the global policy automatically allows them in Cluster Security Policies.

Users have the flexibility to explicitly modify these policies as desired.

Configure Cluster Security Policy:

With Cluster security policy we can block critical vulnerabilities globally but allow them in specific clusters:

  1. Select the desired cluster.

  1. Change the critical setting to allow. This change only affects the policy of the selected cluster without impacting others or the global policy

Cluster Security Policies offer the same two options as Global Security Policies for handling vulnerabilities. However, an extra option called Inherit is available too. When Inherit is selected, the policy adopts settings from higher-level options. For example, if critical severity levels are blocked globally, they will also be blocked in Cluster Security Policies. Changing the global policy to allow critical levels will also allow them in Cluster Security Policies. Configure Environment Security Policy: Select the environment where you want to execute the policy, it automatically adopts the policy of the associated cluster.

For example, if critical-level vulnerabilities are blocked globally but allowed in the Cluster Security Policy, the Environment Security Policy will inherit this allowance. Consequently, critical-level vulnerabilities will also be allowed in the Environment Security Policy.

However, this policy empowers you to customize the policy to align with specific requirements or preferences.

Any changes made to the environment policy settings will be reflected uniformly in all of the environment's corresponding applications. Configure Microservice Security Policy: Choose the specific microservice to implement the Microservice Security policy

You can either allow, block or inherit the vulnerabilities just by selecting from the drop-down

Allow or Block Vulnerability Policies: To block or allow specific Common Vulnerabilities and Exposures (CVE) policies, simply click on Add Vulnerability Policy.

A screen will appear where you can enter the CVE ID, GHSA, and CWE ID. Then Select whether to allow or block it.

This action will check for vulnerabilities matching specific IDs to determine whether to block or allow image deployment.

Images with security flaws won't be allowed to be deployed.

Images with vulnerabilities will be permitted to be deployed.