3 min read
In modern software development, different environments often have different compliance requirements. Your development environment might allow more flexibility, while production demands strict controls around security scans, testing, and code review. Environment Policy helps you codify these requirements and enforce them consistently.
That’s why we’re excited to announce the release of Environment Policy, a new feature that gives you fine-grained control over artifact requirements across your different environments. Environment Policy lets you define, enforce, and audit compliance requirements for artifacts being deployed to specific environments like development, staging, and production.
How It Works
Environment Policy introduces a simple YAML-based policy definition that specifies what makes an artifact compliant for deployment to a specific environment. Here’s a basic example:
_schema: https://kosli.com/schemas/policy/environment/v1
artifacts:
provenance:
required: true
attestations:
- name: dependency-scan
type: '*'
- name: acceptance-test
type: junit
This policy ensures that:
- All artifacts have verifiable provenance (they were created as part of a tracked Kosli Flow)
- Each artifact has a dependency scan reported, the attestation type is unspecified
- Each artifact has acceptance test results, reported using the JUnit attestation
Flow Templates vs Environment Policies: What’s the Difference?
One of the first questions we received during early testing was about the relationship between Flow Templates and Environment Policies. Here’s the key distinction:
Flow Templates provide the rules for evaluating compliance for a Trail
Environment Policies provide the rules for evaluating environment changes
This separation allows teams to maintain their unique build and test processes while ensuring all artifacts meet baseline requirements for specific environments. For example:
- Team A might use Snyk for dependency scans, while Team B uses Sonar
- Your environment policy could simply require “acceptance test results”, even though some teams might also have unit and integration tests
- Both teams can follow their preferred practices while meeting the environment’s compliance requirements
Key Features
-
Immutable Versioning: Policies are versioned and immutable, providing a clear audit trail of requirement changes
-
Multiple Environment Support: Attach a single policy to multiple environments to enforce consistent standards
-
Policy Layering: Combine multiple policies on a single environment to mix organization-wide requirements with environment-specific ones
-
Flexible Requirements: Define requirements around:
• Artifact provenance
• Trail compliance
• Specific attestations
-
Expression-Based Rules: Use conditions to create dynamic requirements based on artifact or flow properties
Getting Started
Try Environment Policy in your organization:
# Create a new policy
kosli create policy prod-requirements prod-policy.yaml
# Attach it to an environment
kosli attach-policy prod-requirements --environment=aws-production
# Verify artifact compliance against an environments policies (coming sooon)
kosli assert artifact --fingerprint=$SHA256 --environment=aws-production
# Verify artifact compliance against a specific policy (coming sooon)
kosli assert artifact --fingerprint=$SHA256 --policy=prod-requirements
Feedback Loop
We’re actively gathering feedback from early users to refine and enhance Environment Policy. We’re particularly interested in:
- How you’re structuring policies across different environments
- Additional attestation matching patterns you need
- Integration patterns with your CI/CD pipelines
Do you have different compliance requirements for development, staging, and production? Are you looking to standardize what checks and controls must be in place before deployment to each environment? We’d love to hear how you’re handling these challenges today. Contact our team
