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
andRelease.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-versionKubernetes-version
—namespaceaddon-namespace
—include-crds —no-hooks —fany-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
orgcr
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 validapplication/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 createsserviceAccount
by default. If theserviceAccount
creation is handled by a parameter in avalues.yaml
file, set the parameter value totrue
. 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 theserviceAccount
, then the permissions can't be tied to theserviceAccount
. -
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 schemaaws_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 |