Container-based product requirements - AWS Marketplace
Security requirementsAccess requirementsCustomer information requirementsProduct usage requirementsArchitecture requirementsContainer product usage instructionsRequirements for Amazon EKS add-on products

Container-based product requirements

AWS Marketplace maintains the following requirements for all container-based products and offerings on AWS Marketplace. These requirements help to promote a safe, secure, and trustworthy catalog for our customers. We also encourage sellers to review implementation of additional controls and protocols as applicable to meet the needs of their specific products.

All products and their related metadata are reviewed when submitted to ensure that they meet or exceed current AWS Marketplace requirements. We review and adjust these policies to meet our evolving security and other usage requirements. AWS Marketplace continuously verifies that existing products continue to meet any changes to these requirements. If products fall out of compliance, AWS Marketplace will contact you to update your product. In some cases, your product might temporarily be unavailable to new subscribers until issues are resolved.

Security requirements

All container-based products must adhere to the following security requirements:

  • Docker container images must be free from any known malware, viruses, or vulnerabilities. When you add a new version to your container product, the container images included in the version are scanned.

  • If your container-based products requires access to manage AWS resources, access must be achieved through IAM roles for service accounts (if run through Amazon Elastic Kubernetes Service (Amazon EKS)) or IAM roles for tasks (if run through Amazon Elastic Container Service (Amazon ECS)) instead of requesting an access key from users.

  • Container-based products must only require least privileges to run. For more information, see ECS security and EKS security.

  • Container images should be configured to run with non-root privileges by default.

Access requirements

All container-based products must adhere to the following access requirements:

  • Container-based products must use an initial randomized password. Container-based products must not use initial fixed or blank passwords for external administrative access (for example, to log in to the application via a web interface). The buyer must be prompted for this randomized password before being permitted to set or change their own credentials.

  • Any outside access to the application must be explicitly agreed to and enabled by customers.

Customer information requirements

All container-based products must adhere to the following customer information requirements:

  • Software must not collect or export customer data without the customer's knowledge and express consent except as required by BYOL (Bring Your Own License). Applications that collect or export customer data must follow these guidelines:

    • The collection of the customer data must be self-service, automated, and secure. Buyers must not need to wait for sellers to approve to deploy the software.

    • The requirements for customer data must be clearly stated in the description or the usage instructions of the listing. This includes what is collected, the location of where the customer data will be stored, and how it will be used. For example, This product collects your name and email address. This information is sent to and stored by the <company name>. This information will only be used to contact the buyer in regards to the <product name>.

    • Payment information must not be collected.

Product usage requirements

All container-based products must adhere to the following product usage requirements:

  • Sellers can only list fully functioning products. Beta or prerelease products for trial or evaluation purposes are not allowed. Developer, community, and BYOL editions of commercial software are supported if the seller provides an equivalent paid version on AWS Marketplace within 90 days of providing the free edition.

  • All of a container-based product's usage instructions must include all steps to deploy container-based products. Usage instructions must provide commands and deployment resources pointing to the corresponding container images on AWS Marketplace.

  • Container-based products must include all container images that a subscriber needs to use the software. In addition, container-based products must not require a user to launch the product using any images from outside AWS Marketplace (for example, container images from third-party repositories).

  • Containers and their software must be deployable in a self-service manner and must not require additional payment methods or costs. Applications that require external dependencies on deployment must follow these guidelines:

    • The requirement must be disclosed in the description or the usage instructions of the listing. For example, This product requires an internet connection to deploy properly. The following packages are downloaded on deployment: <list of package>.

    • Sellers are responsible for the use of and ensuring the availability and security of all external dependencies.

    • If the external dependencies are no longer available, the product must be removed from AWS Marketplace as well.

    • The external dependencies must not require additional payment methods or costs.

  • Containers that require an ongoing connection to external resources not under the direct control of the buyer—for example, external APIs or AWS services managed by the seller or a third party—must follow these guidelines:

    • The requirement must be disclosed in the description or the usage instructions of the listing. For example, This product requires an ongoing internet connection. The following ongoing external services are required to properly function: <list of resources>.

    • Sellers are responsible for the use of and ensuring the availability and security of all external resources.

    • If the external resources are no longer available, the product must be removed from AWS Marketplace as well.

    • The external resources must not require additional payment methods or costs and the setup of the connection must be automated.

  • Product software and metadata must not contain language that redirects users to other cloud platforms, additional products, or upsell services that aren't available on AWS Marketplace.

  • If your product is an add-on to another product or another ISV’s product, your product description must indicate that it extends the functionality of the other product and that without it, your product has very limited utility. For example, This product extends the functionality of <product name> and without it, this product has very limited utility. Please note that <product name> might require its own license for full functionality with this listing.

Architecture requirements

All container-based products must adhere to the following architecture requirements:

  • Source container images for AWS Marketplace must be pushed to the Amazon Elastic Container Registry (Amazon ECR) repository owned by AWS Marketplace. You can create these repositories in the AWS Marketplace Management Portal under server products for each of your container product listings.

  • Container images must be based on Linux.

  • Paid container-based products must be able to be deployed on Amazon ECS, Amazon EKS, or AWS Fargate.

  • Paid container-based products with contract pricing and an integration with AWS License Manager should deploy on Amazon EKS, Amazon ECS, AWS Fargate, Amazon EKS Anywhere, Amazon ECS Anywhere, Red Hat OpenShift Service on AWS (ROSA), self-managed Kubernetes clusters on-premises, or on Amazon Elastic Compute Cloud.

Container product usage instructions

When creating usage instructions for your container product, follow the steps and guidance in AMI and container product usage instructions.

Requirements for Amazon EKS add-on products

An Amazon EKS add-on is software that provides operational capabilities to Kubernetes applications but isn't specific to the application. For example, an Amazon EKS add-on includes observability agents or Kubernetes drivers that allow the cluster to interact with underlying AWS resources for networking, compute, and storage.

As a seller of container products, you can choose among several deployment options including Amazon EKS. You can publish a version of your product as an AWS Marketplace add-on into the Amazon EKS add-on catalog. Your add-on appears in the Amazon EKS console next to add-ons maintained by AWS and other vendors. Your buyers can deploy your software as an add-on just as easily as they do the other add-ons.

For more information, see Amazon EKS add-ons in the Amazon EKS User Guide.

Preparing your container product as an AWS Marketplace add-on

To publish your container product as an AWS Marketplace add-on, it must meet the following requirements:

  • Your container product must be published in AWS Marketplace.

  • Your container product must be built compatible for both AMD64 and ARM64 architectures.

  • Your container product must not use the Bring Your Own License (BYOL) pricing model.

    Note

    BYOL is not supported for Amazon EKS add-on delivery.

  • You must adhere to all container-based product requirements including pushing all container images and Helm charts into AWS Marketplace managed Amazon ECR repositories. This requirement includes open-source images, for example, nginx. Images and charts can't be hosted in other external repositories including, but not limited to, Amazon ECR Public Gallery, Docker Hub, and Quay.

  • Helm charts - Prepare your software to be deployed through a Helm chart. The Amazon EKS add-on framework converts a Helm chart into a manifest. Some Helm features are not supported within Amazon EKS systems. The following list describes the requirements that must be met before onboarding. In this list, all Helm commands use Helm version 3.8.1:

    • All Capabilities objects are supported, with an exception for .APIVersions. .APIVersions is not supported for non-built-in custom Kubernetes APIs.

    • Only the Release.Name and Release.Namespace objects are supported.

    • Helm hooks and the lookup function are not supported.

    • All dependent charts must be located within the main Helm chart (specified with repository path file://...).

    • The Helm chart must successfully pass Helm Lint and Helm Template with no errors. The commands are as follows:

      • Helm Lint – helm lint helm-chart

        Common issues include undeclared charts in the parent chart’s metadata. For example, chart metadata is missing these dependencies: chart-base Error: 1 chart(s) linted, 1 chart(s) failed

      • Helm Template – helm template chart-name chart-location —set k8version=Kubernetes-version —kube-version Kubernetes-version —namespace addon-namespace —include-crds —no-hooks —f any-overriden-values

        Pass any overridden configurations with the —f flag.

    • Store all container binaries in AWS Marketplace Amazon ECR repos. To create a manifest, use the Helm template command that's shown earlier. Search the manifest for any external image references such as busybox or gcr images. Upload all container images along with dependencies into AWS Marketplace Amazon ECR repos created by using the Add Repository option in the request dropdown.

  • Custom configuration – You can add custom variables during the deployment. For information about how to identify the end user experience, name the software aws_mp_configuration_schema.json, and package into a wrapper with the Helm chart, see Amazon EKS add-ons: Advanced configuration.

    According to The "$schema" Keyword, $schema must be a URI that points to a valid application/schema+json resource.

    This file must not accept any sensitive information such as passwords, license keys, and certificates.

    To handle secrets and certificate installations, you can provide post- or pre-Add-on installation steps to end users. The product should not rely on any external licenses. The product should work based on AWS Marketplace entitlements.

    For more information about limitations for aws_mp_configuration_schema.json, see Add-on configuration requirements and best practices for add-on providers.

  • Identify and create the namespace that the software will be deployed in – In the first release of your product, you must identify the namespace that the software will be deployed in by adding a templatized namespace.

  • Create the serviceAccount if applicable – If the software is either a paid software on AWS Marketplace or must connect with other AWS services, make sure that the Helm chart creates serviceAccount by default. If the serviceAccount creation is handled by a parameter in a values.yaml file, set the parameter value to true. For example, serviceAccount.create = true. This is required because the customer might choose to install the add-on by inheriting permissions from the underlying node instance which already has the required permissions. If the Helm chart doesn't create the serviceAccount, then the permissions can't be tied to the serviceAccount.

  • Traceable Deployments or Daemonsets – Make sure your Helm chart has a daemonset or deployment. Amazon EKS addon framework tracks deployment of your Amazon EKS resources using them. Without a traceable deployment or daemonset, your addon will face an deployment error. If your addon does not have a deployment or daemonset, for example, if your addon deploys a bunch of Custom resources or a Kubernetes job which are not traceable, add a dummy deployment or daemonset object.

  • Support for AMD and ARM architectures – Many Amazon EKS customers use ARM64 today to use AWS Graviton instances. Third-party software must support both architectures.

  • Integrate with licensing or metering APIs from AWS Marketplace – AWS Marketplace supports multiple billing models. For more information, see Container product billing, metering, and licensing integrations. If you want to sell your product through PAYG mechanisms, see Custom metering for container products with AWS Marketplace Metering Service. If you want to sell your product through an upfront or contract model, see Contract pricing for Container products with AWS License Manager.

  • Upload the software and all the artifacts and dependencies – The Helm chart must be self-contained, and it must not require dependencies from external sources, for example, GitHub. If the software requires external dependencies, then the dependencies must be pushed to AWS Marketplace private Amazon ECR repositories under the same AWS Marketplace listing.

  • Provide deployment instructions on your website – We request that you host a deployment guide for customers to identify how to deploy your software through the create-addon command.

  • IAM roles – List all the AWS Identity and Access Management (IAM) policies required for your software to function or connect with other AWS services.

  • Version updates – Amazon EKS releases new Kubernetes versions a few weeks after the upstream release. As new Amazon EKS cluster versions become generally available, vendors have 45 days to certify or update their software to be compatible with the new Amazon EKS cluster version release. If your current versions of the add-on supports the new Kubernetes version, validate and certify the same so that we can update the version compatibility matrix. If a new add-on version is needed to support the new Kubernetes version release, then please submit the new version for onboarding.

  • Partner’s software must fall into one of the following types or be an operational software that will enhance Kubernetes or Amazon EKS: Gitops | monitoring | logging | cert-management | policy-management | cost-management | autoscaling | storage | kubernetes-management | service-mesh | etcd-backup | ingress-service-type | load-balancer | local-registry| networking | Security | backup | ingress-controller | observability

  • Software cannot be Container Network Interface (CNI).

  • Software must be sold through AWS Marketplace and integrated with Licensing and metering APIs for paid products. BYOL products are not accepted.

Add-on configuration requirements and best practices for add-on providers

Amazon EKS requires configuration as a Helm JSON schema string from add-on providers. Add-ons that either need required configurations or allow optional configurations must include a aws_mp_configuration_schema.json file with the Helm Chart submitted to AWS Marketplace. Amazon EKS will use this schema to validate the configuration input from customers and reject API calls with input values that do not conform to the schema. Add-on configurations typically fall under two categories:

  • Configuration for general Kubernetes properties like labels, tolerations, nodeSelector, etc.

  • Configurations that are add-on specific like license key, feature enablement, URLs, etc.

This section is focused on the first category related to general Kubernetes properties.

Amazon EKS recommends following best practices around configuration of Amazon EKS add-ons.

Schema requirements

When defining the json schema, ensure you use a version of jsonschema that is supported by Amazon EKS add-ons.

The list of supported schemas:

  • https://json-schema.org/draft-04/schema

  • https://json-schema.org/draft-06/schema

  • https://json-schema.org/draft-07/schema

  • https://json-schema.org/draft/2019-09/schema

Using any other json schema version is incompatible with Amazon EKS add-ons and will cause the add-on to be unable to be released until this is fixed.

Example Helm schema file

{
"$schema": "http://json-schema.org/schema#",
  "type": "object",
  "properties": {
"podAnnotations": {
"description": "Pod Annotations"
"type": "object"
    },
    "podLabels": {
"description": "Pod Labels"
"type": "string"
    },
    "resources": {
"type": "object"
"description": "Resources"
    },
    "logLevel": {
"description": "Logging Level"
"type": "string",
      "enum": [
        "info",
        "debug"
      ]
    },
    "config": {
"description": "Custom Configuration"
"type": "object"
    }
  }
}
camelCase

Configuration parameters are required to be camelCase, and will be rejected if not adhering to this format.

Descriptions are required

Always include meaningful descriptions for schema properties. This description will be used to render label names in Amazon EKS console for each configuration parameter.

RBAC definition

Add-on providers need to define and supply the RBAC permissions needed to successfully install the add-on using the principle of least privilege. If RBAC permissions need to change for newer versions of add-on or any fixes to address a CVE, add-on providers will need to inform the Amazon EKS team about this change. Required permissions for each Kubernetes resource should be restricted to the resource name of the object. 

apiGroups: ["apps"]
resources: ["daemonsets"]
resourceNames: ["ebs-csi-node"]
verbs: ["create", "delete", "get", "list", "patch", "update", "watch"]
Secrets Management

This section only applies to add-ons that need customers to configure secret information like application key, API key, password, etc. Currently, Amazon EKS APIs do not support passing in secret information in plain text due to the security implications. However, customers can use configuration to pass in the name of the Kubernetes Secret that holds the keys needed by the add-on. Customers will be required to create Kubernetes Secret objects containing the keys with the same namespace as a pre-requisite step and then pass in the name of the Secret using configuration blob when creating the add-on. We recommend that add-on providers name the schema properties so that customers do not accidentally mistake it for the actual key. For example: appSecretName, connectionSecretName etc.

In summary, add-on providers can leverage the schema to allow customers to pass in the name of the secret but not the keys which will actually hold the secret itself.

Example configuration values

You can include configuration examples in your schema to help customers with configuration of add-ons. The following example is from the schema of AWS Distro for OpenTelemetry add-on.

"examples": [
      {
        "admissionWebhooks": {
          "namespaceSelector": {},
          "objectSelector": {}
        },
        "affinity": {},
        "collector": {
          "amp": {
            "enabled": true,
            "remoteWriteEndpoint": "https://aps-workspaces.us-west-2.amazonaws.com/workspaces/ws-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/api/v1/remote_write"
          },
          "cloudwatch": {
            "enabled": true
          },
          "mode": "deployment",
          "replicas": 1,
          "resources": {
            "limits": {
              "cpu": "256m",
              "memory": "512Mi"
            },
            "requests": {
              "cpu": "64m",
              "memory": "128Mi"
            }
          },
          "serviceAccount": {
            "annotations": {},
            "create": true,
            "name": "adot-collector"
          },
          "xray": {
            "enabled": true
          }
        },
        "kubeRBACProxy": {
          "enabled": true,
          "resources": {
            "limits": {
              "cpu": "500m",
              "memory": "128Mi"
            },
            "requests": {
              "cpu": "5m",
              "memory": "64Mi"
            }
          }
        },
        "manager": {
          "env": {},
          "resources": {
            "limits": {
              "cpu": "100m",
              "memory": "128Mi"
            },
            "requests": {
              "cpu": "100m",
              "memory": "64Mi"
            }
          }
        },
        "nodeSelector": {},
        "replicaCount": 1,
        "tolerations": []
      }
    ]

Common parameters that are allowed for configuration

The following are recommended parameters in a customer facing Helm schema file.

Parameter Description Should have a default?
additionalLabels Add Kubernetes labels to all Kubernetes objects managed by the add-on. No
additionalAnnotations Add Kubernetes annotations to all Kubernetes objects managed by the add-on. No
podLabels Add Kubernetes labels to pods managed by the add-on. No
podAnnotations Add Kubernetes annotations to pods managed by the add-on. No
logLevel Log level for components managed by the add-on. Yes
nodeSelector Simplest recommended form of node selection constraint. You can add the nodeSelector field to your Pod specification and specify the node labels you want the target node to have. Potentially, for example Linux nodes only
tolerations Tolerations are applied to pods. Tolerations allow the scheduler to schedule pods with matching taints. Tolerations allow scheduling but don't guarantee scheduling. Maybe, more common with daemonsets
affinity The affinity feature consists of two types of affinity: Node affinity functions like the nodeSelector field but is more expressive and allows you to specify soft rules, Inter-pod affinity/anti-affinity allows you to constrain Pods against labels on other Pods. Maybe
topologySpreadConstraints You can use topology spread constraints to control how Pods are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. This can help to achieve high availability as well as efficient resource utilization. Maybe
resource request/limits Specify how much cpu/memory each container needs. Requests are strongly recommended to be set. Limits are optional. Yes
replicas Number of replicas of the pods managed by the add-on. Not applicable for daemonsets. Yes
Note

For workload scheduling configuration parameters, you may need to separate out top level components in the Schema where necessary. Example, Amazon EBS CSI driver contains two main components, controller and node agent - customers require different node selectors/tolerations for each component.

Note

The default values defined in the JSON schema is purely for user documentation purpose only and does not replace the need to have the rightful default in the values.yaml file. If using the default property, please ensure that the default in values.yaml matches that in the schema and the two artifacts (values.schema.json and values.yaml) remain in sync whenever changes are made to the Helm Chart.

"affinity": {
            "default": {
              "affinity": {
                "nodeAffinity": {
                  "preferredDuringSchedulingIgnoredDuringExecution": [
                    {
                      "preference": {
                        "matchExpressions": [
                          {
                            "key": "eks.amazonaws.com/compute-type",
                            "operator": "NotIn",
                            "values": [
                              "fargate"
                            ]
                          }
                        ]
                      },
                      "weight": 1
                    }
                  ]
                },
                "podAntiAffinity": {
                  "preferredDuringSchedulingIgnoredDuringExecution": [
                    {
                      "podAffinityTerm": {
                        "labelSelector": {
                          "matchExpressions": [
                            {
                              "key": "app",
                              "operator": "In",
                              "values": [
                                "ebs-csi-controller"
                              ]
                            }
                          ]
                        },
                        "topologyKey": "kubernetes.io/hostname"
                      },
                      "weight": 100
                    }
                  ]
                }
              }
            },
            "description": "Affinity of the controller pod",
            "type": [
              "object",
              "null"
            ]
          }

Common parameters that aren't allowed for configuration

Cluster metadata parameters such clusterName, region, vpcId, accountId, and others may be required by various add-ons (for example, Elastic Load Balancing Controller). Any parameter similar to these that is known by the Amazon EKS service will be automatically injected by Amazon EKS add-ons, and not put on the responsibility of the user to specify as a configuration option. These parameters include:

  • AWS region

  • Amazon EKS cluster name

  • VPC ID of the cluster

  • Container registry, specifically for build-prod accounts, which is used by networking add-ons

  • DNS cluster IP, specifically for coredns add-on

  • Amazon EKS cluster API endpoint

  • IPv4 enabled on cluster

  • IPv6 enabled on cluster

  • Prefix delegation for IPv6 enabled on cluster

Add-on providers need to ensure you have templating defined for such applicable parameters. Each of the above parameters will have a pre-defined parameterType attribute defined by Amazon EKS. The release metadata will specify the mapping between the parameterType and the name/path of the parameter in the template. This way, the values can be dynamically passed-in by Amazon EKS without requiring customers to specify these through configurations and also gives flexibility to add-on providers to define their own template name/path. Parameters such as the above that Amazon EKS needs to inject dynamically should be excluded from the schema file.

Example mapping from release metadata

"defaultConfiguration": [
       {
            "key": "image.containerRegistry",
            "parameterType": "CONTAINER_REGISTRY"
       }
]

The following are parameters not recommended to be configurable in a customer facing Helm schema file. Either the parameters should have non-modifiable defaults, or not be included at all in the add-on template.

Parameter Description Should have a default?
image Container image that will be deployed on the Kubernetes cluster. No, managed through add-on definition
imagePullSecrets Configuring a pod to use a secret to pull from a private registry. N/A
livenessProbe The Kubelet process uses liveness probes to know when to restart a container. For example, liveness probes could catch a deadlock, where an application is running, but unable to make progress. Restarting a container in such a state can help to make the application more available despite bugs. Yes
readinessProbe It is important that you have a readiness probe for your containers. This way the Kubelet process running on your data plane will know when the container is ready to serve traffic. A Pod is considered ready when all of its containers are ready. One use of this signal is to control which Pods are used as backends for Services. When a Pod is not ready, it is removed from Service load balancers. Yes
startupProbe The kubelet uses startup probes to know when a container application has started. If such a probe is configured, it disables liveness and readiness checks until it succeeds, making sure those probes don't interfere with the application startup. This can be used to adopt liveness checks on slow starting containers, avoiding them getting killed by the kubelet before they are up and running. Optional
podDisruptionBudget Define a Pod Discruption Budget (PDB) to ensure a minimum number of PODS keep running during voluntary disruptions. A PDB limits the number of Pods of a replicated application that are down simultaneously from voluntary disruptions. For example, a quorum-based application would like to ensure that the number of replicas running is never brought below the number needed for a quorum. A web front end might want to ensure that the number of replicas serving load never falls below a certain percentage of the total. Yes, if defaulting to more than two replicas
serviceAccount (name) Name of the service account pods will run under. Yes
serviceAccount (annotations) Annotations applied to the service account. Typically used for IAM Roles for Service Accounts feature No, IAM service account role ARN is set in top level Amazon EKS add-ons API. An exception to this rule is if your add-on has multiple deployments/controllers (such as Flux) and requires separate IRSA role ARNs.
priorityClassName Priority indicates the importance of a Pod relative to other Pods. If a Pod cannot be scheduled, the scheduler tries to preempt (evict) lower priority Pods to make scheduling of the pending Pod possible. Yes. Most add-ons are critical to cluster functionality, and should have a priority class set by default.
podSecurityContext A security context defines privilege and access control settings for a Pod or Container. Typically used to set fsGroup - which was required for IRSA in v1.19 and lower clusters. Unlikely, given Amazon EKS no longer supports Kubernetes v1.19
securityContext A security context defines privilege and access control settings for a Pod or Container. Yes
updateStrategy Specifies the strategy used to replace old Pods by new ones. Yes
nameOverride Override name of pods. No
podSecurityPolicy

Enforce restrictions on parameters.

 No - PSPs are deprecated
extraVolumeMounts/extraVolumes

Used for IRSA in non Amazon EKS clusters.

No