Skip to content

Container Product Policies

ClairAI Observability Platform — AWS Marketplace Container Product Policies

Field Value
Version internal-testing-v1.1.1
Publisher Info Services
Delivery Type Helm-based container product for Amazon EKS
Target Platform Amazon EKS
Chart Version 0.1.0

Topics

1. Purpose and Scope

This document defines the security, operational, support, licensing, architecture, Helm, and buyer responsibility policies for the ClairAI AWS Marketplace container product.

AWS Marketplace policy area ClairAI policy coverage
Customer information requirements Documents that customer data collection/export must be known, consented, secure, and consistent with AWS Marketplace agreements.
Product usage requirements Documents self-service deployment, all required images in Marketplace ECR, no external image dependency, and no extra payment method outside AWS Marketplace.
Architecture requirements Documents Linux containers, Amazon EKS target, ARM64/x86_64 support, Marketplace ECR artifacts, and image regionalization.
Helm chart structure requirements Documents image variables in values.yaml, standard Helm template image references, no hardcoded image refs, and values.yaml-only configuration.
Usage instructions Points buyers to the usage instructions document for end-to-end deployment and monitoring steps.

2. Deployment Model

ClairAI is distributed as a Helm-based container product for Amazon EKS. Buyers deploy ClairAI using reusable Helm charts and component-specific values files.

  • Backend
  • Frontend
  • Agent
  • YACE monitoring services

Buyers deploy ClairAI in their own AWS accounts and Kubernetes clusters. Product deployment must be self-service and must not require seller approval after the AWS Marketplace subscription is active.

3. Supported Environment

Category Supported value
Platform Amazon EKS
Operating system base Linux-based containers
Architectures ARM64 and x86_64
Minimum recommended Kubernetes version 1.29 or later
Delivery mechanism Helm chart and images stored in AWS Marketplace managed Amazon ECR

4. Security Policies

4.1 Container image security

  • Container images must not contain known critical or high vulnerabilities, malware, unsupported end-of-life operating systems, or end-of-life software packages at release time.
  • Container images must not contain hardcoded passwords, hashed passwords, API keys, access keys, private keys, certificates, tokens, or other secrets.
  • Container images must not include unsupported architecture layers or unrelated attestation layers that cause Marketplace validation issues.
  • Images should run with non-root privileges by default where the application component supports it.
  • All required runtime images, including open-source dependencies, must be published to AWS Marketplace managed Amazon ECR repositories for the listing.

4.2 AWS credential policy

  • ClairAI containers must not ask buyers to pass long-lived AWS access keys or secret keys into containers.
  • When a component requires AWS API access on Amazon EKS, use IAM Roles for Service Accounts (IRSA) or an AWS-supported pod identity mechanism where applicable.
  • Runtime permissions must follow least privilege. Setup/admin permissions must be separate from pod runtime permissions.

4.3 Authentication policy

  • Services running inside containers must not rely on password-based container authentication as the default Marketplace deployment model.
  • Blank, null, default, or generated passwords embedded into images are not allowed.
  • External identity integrations such as Cognito or Azure AD should be configured explicitly by the buyer when enabled.

4.4 Secrets policy

  • Sensitive values must not be stored directly in values.yaml.
  • Configuration schemas must not collect raw passwords, API keys, private keys, certificates, license keys, or other secrets.
  • Use Kubernetes Secret names, AWS Secrets Manager references, or Secrets Store CSI Driver references instead of raw secret values.
  • Buyers are responsible for secret rotation according to their security policy.

5. Customer Information and Data Handling Requirements

  • ClairAI must not collect or export buyer customer data without the buyer knowledge and express consent. Any data collection or export must be disclosed in the Marketplace description or usage instructions and must be automated, secure, and self-service.
  • Payment information must not be collected by the ClairAI application.
  • Any telemetry sent outside the buyer account must be disclosed and must not require an additional payment method outside AWS Marketplace.
  • If a buyer disables optional external integrations, ClairAI should not depend on those integrations to complete the core deployment.
  • Customer data handling must remain consistent with applicable AWS Marketplace terms, AWS service terms, AWS privacy requirements, and the buyer agreement.

6. Product Usage Requirements

  • The Marketplace release must be a fully functioning product release, not a beta-only, prerelease-only, or evaluation-only artifact.
  • Usage instructions must include all commands and resources needed to deploy ClairAI from AWS Marketplace artifacts.
  • The product must not require buyers to build images, push images, clone source repositories, or use CI/CD pipelines to deploy the Marketplace version.
  • The product must not require buyers to launch containers from Docker Hub, ECR Public, Quay, GitHub Container Registry, or any image repository outside AWS Marketplace for required runtime components.
  • External dependencies, if any, must be disclosed in the listing description or usage instructions and must not require an additional payment method outside AWS Marketplace.
  • Product documentation and metadata must not redirect buyers to unrelated cloud platforms, unavailable products, or upsell services outside AWS Marketplace.

7. Architecture Requirements

  • Source container images must be stored in AWS Marketplace managed Amazon ECR repositories for the product listing.
  • The Helm chart must deploy to Amazon EKS and create Kubernetes Deployments or DaemonSets that can be traced by Kubernetes and Marketplace validation tooling.
  • The container images must be Linux-based.
  • The release must support both AMD64/x86_64 and ARM64 architectures when submitted as an Amazon EKS add-on or when buyer node architecture support is advertised.
  • If any AMI is required in the future, it must be AWS-managed or separately published in AWS Marketplace and documented as a dependency. The current ClairAI Helm deployment does not require a ClairAI AMI.

8. Helm Chart Structure and Regionalization Policies

8.1 Image reference policy

All container image references must be defined in values.yaml and referenced in templates through Helm variables. Image references must not be hardcoded directly in Deployment, DaemonSet, Job, or helper templates.

# Recommended values.yaml structure
image:
  registry: "709825985650.dkr.ecr.us-east-1.amazonaws.com"
  repository: "info-services/clairai"
  tag: "internal-testing-v1.1.1-backend"

# Recommended template reference
image: "{{ .Values.image.registry }}/{{ .Values.image.repository }}:{{ .Values.image.tag }}"

8.2 Configuration policy

  • Document all configurable values.yaml parameters, including image.registry, image.repository, image.tag, serviceAccount, service, ingress, resources, nodeSelector, tolerations, affinity, and secretProviderClass settings.
  • Buyer-facing instructions should use values.yaml files for configuration. Do not instruct buyers to modify Helm templates or use --set parameters as the primary configuration method.
  • Changing image.registry and related image values must correctly update all deployed image references for regional Marketplace deployment.
  • Avoid conditional template logic that bypasses values.yaml image references.

8.3 Helm validation policy

helm lint <helm-chart-directory>
helm template clairai <helm-chart-directory> \
  --namespace <NAMESPACE> \
  --kube-version <KUBERNETES_VERSION> \
  --include-crds \
  --no-hooks \
  -f values.yaml
  • Helm lint and Helm template must complete without errors before Marketplace submission.
  • All dependent charts must be packaged within the parent chart directory or otherwise included as Marketplace-approved artifacts.
  • All rendered manifests must reference Marketplace ECR images only for required product containers.
  • For EKS add-on delivery, avoid unsupported Helm features such as hooks and lookup where the add-on framework disallows them.

9. IAM and Permissions Policy

IRSA is recommended for any ClairAI workload that needs AWS API access. The service account should be created by the Helm chart by default when the component requires AWS access.

Component Policy expectation
Backend Use a component-specific service account. Attach only required runtime permissions if AWS APIs are used.
Frontend No AWS API permissions should be required for static UI serving unless explicitly configured.
Agent Use a component-specific service account and least-privilege permissions for configured discovery or telemetry operations.
YACE Use a component-specific service account with CloudWatch read permissions only for the required namespaces/services.
  • Do not rely on broad node instance profile permissions as the preferred runtime access model.
  • Do not ask buyers to mount AWS credential files into pods.
  • Document every required IAM action and why it is needed.

10. Networking and Ingress Policy

  • When ingress is enabled, buyers may need AWS Load Balancer Controller, DNS configuration, TLS certificates, ingress annotations, security groups, and subnet tags.
  • TLS termination should be configured for public endpoints according to buyer security requirements.
  • Expose only required ports. Use ClusterIP services for internal-only communication where possible.
  • Network policies, security groups, and firewall rules are the buyer responsibility unless explicitly deployed by the ClairAI chart.

11. Monitoring and Logging Policy

  • ClairAI supports integration with CloudWatch, Grafana, Prometheus-compatible metrics systems, Loki, and Tempo. Some integrations may require additional infrastructure, IAM permissions, and AWS service cost.
  • Usage instructions must include commands to assess pod health, service status, ingress status, logs, events, and component health endpoints.
  • Monitoring integrations should be optional unless explicitly required by the selected deployment configuration.
  • Metric and log ingestion should be tunable to help buyers manage AWS costs and service quotas.

12. Backup, Recovery, and Data Persistence Policy

  • Buyers are responsible for backing up values.yaml files, Kubernetes manifests, Kubernetes Secrets, AWS Secrets Manager values, ingress configuration, monitoring dashboards, and alert rules.
  • If buyer-configured persistent volumes or external data stores are used, buyers are responsible for backup, restore, encryption, and retention policies for those stores.
  • The current ClairAI Marketplace deployment instructions do not require a proprietary ClairAI data store by default. If a proprietary data store is introduced, step-by-step configuration, backup, and recovery instructions must be added before submission.

13. Upgrade and Version Policy

  • Upgrades must be performed using Helm upgrade with the appropriate component values.yaml file.
  • Buyers should validate upgrades in non-production environments before production rollout.
  • Release notes must clearly describe changes and mark updates as Critical, Important, or Optional where applicable.
  • Before upgrade, buyers should back up values.yaml files, secrets, and any external monitoring configuration.
  • If there is no supported upgrade path for a future version, the release notes and usage instructions must explicitly state that.

14. Licensing, Metering, and Payment Policy

  • The product should work based on the AWS Marketplace subscription, entitlement, licensing, or metering model configured for the listing.
  • The product must not require an additional payment method outside AWS Marketplace for core deployment or runtime operation.
  • For paid container products that use PAYG or contract pricing, integrate with the applicable AWS Marketplace metering or licensing APIs as required by the selected pricing model.
  • BYOL restrictions must be reviewed before EKS add-on delivery because BYOL is not supported for AWS Marketplace EKS add-on delivery.

15. External Dependency Policy

  • Required runtime images and artifacts must come from AWS Marketplace managed ECR repositories.
  • The Helm chart should be self-contained and must not require cloning files from GitHub or downloading runtime images from external public registries.
  • If a non-image external dependency is required, disclose it in the product description and usage instructions, ensure it is secure and available, and confirm it does not require extra payment outside AWS Marketplace.
  • If an ongoing connection to an external seller-managed or third-party resource is required, disclose it in the listing and automate the setup. The dependency must not require additional payment outside AWS Marketplace.

16. Operational Boundaries and Buyer Responsibilities

Area Buyer responsibility
AWS account and EKS cluster Provision, secure, patch, and operate the cluster and worker nodes.
IAM Create and approve required roles, policies, and service account annotations.
Secrets Create, store, encrypt, rotate, and remove secrets.
Networking Configure ingress, DNS, TLS, subnets, route tables, security groups, and network policies.
Monitoring cost Control log, metric, trace, and alerting volume.
Backups Back up values files, secrets, manifests, and external data stores.

17. Troubleshooting Policy

Issue Policy-compliant guidance
ImagePullBackOff Verify Marketplace subscription, Helm registry login, and Marketplace ECR image references.
Pods pending Review resource requests, node capacity, nodeSelector, tolerations, affinity, and cluster autoscaler behavior.
Ingress not provisioned Verify AWS Load Balancer Controller, subnet tags, ingress annotations, and security group permissions.
YACE metrics unavailable Verify service account, IRSA role trust, CloudWatch read IAM policy, and AWS_REGION configuration.
Secret not mounted Verify Kubernetes Secret or SecretProviderClass exists in the same namespace and has the expected key names.

18. Support Policy

Support is available through the AWS Marketplace support channel. Buyers should remove or redact secrets before sharing any configuration or logs.

When opening a support case, include:

  • AWS Region
  • Kubernetes version
  • Helm chart version
  • Namespace
  • Helm release name
  • Pod status
  • Relevant pod logs
  • values.yaml with secrets removed
  • Ingress status
  • Recent configuration or upgrade changes

19. Pre-Submission Compliance Checklist

  • [ ] All images required for ClairAI runtime are in AWS Marketplace managed ECR.
  • [ ] No required runtime image points to Docker Hub, ECR Public, Quay, GitHub Container Registry, or another external registry.
  • [ ] Images are Linux-based and support the advertised architectures.
  • [ ] Images contain no hardcoded secrets or static AWS credentials.
  • [ ] Images have been scanned and remediated for known vulnerabilities according to release policy.
  • [ ] Containers run non-root where component functionality allows.
  • [ ] Helm values.yaml contains image registry, repository, and tag variables.
  • [ ] Helm templates use values.yaml image variables and do not hardcode image references.
  • [ ] Usage instructions document all buyer deployment steps and monitoring checks.
  • [ ] Sensitive configuration is represented by secret names or secret references, not raw secret values.
  • [ ] IAM permissions are documented and least-privilege.
  • [ ] Cost and quota impacts are disclosed.
  • [ ] Upgrade, rollback, backup, uninstall, and support instructions are included.

20. References

  • AWS Marketplace Seller Guide: Container-based product requirements for AWS Marketplace
  • AWS Marketplace Seller Guide: Creating AMI and container product usage instructions