ADDF secure setup and operation
Autonomous Driving Data Framework (ADDF) should be treated as a custom piece of software that requires ongoing maintenance and care by a dedicated DevOps and security team in your organization. This section describes security-related common tasks that help you set up and operate ADDF throughout its lifecycle.
This section includes the following tasks:
Defining your ADDF architecture
An ADDF instance is only as secure as the AWS account environment it's deployed in. This AWS account environment must be designed to meet the security and operational needs of your specific use case. For example, the security and operations-related tasks and considerations for setting up an ADDF instance in a proof-of-concept (PoC) environment are different than those for setting up ADDF in a production environment.
Running ADDF in a PoC environment
If you intend to use ADDF in a PoC environment, we recommend that you create a dedicated AWS account for ADDF that doesn't contain any other workloads. This helps keep your account secure while you explore ADDF and its features. The following are the benefits of this approach:
-
In case of a severe ADDF misconfiguration, no other workloads would be adversely affected.
-
There is no risk of any other workload misconfiguration that could adversely affect the setup of ADDF.
Even for a PoC environment, we still recommend that you follow as many of the best practices listed in Running ADDF in a production environment as possible.
Running ADDF in a production environment
If you intend to use ADDF in an enterprise production environment, we highly recommend that you consider your organization's security best practices and implement ADDF accordingly. In addition to your organization's security best practices, we recommend that you implement the following:
-
Create a long-term, committed ADDF DevOps team – ADDF needs to be treated as a custom piece of software. It requires ongoing maintenance and care by a dedicated DevOps team. Before starting to run ADDF in a production environment, a DevOps team of sufficient size and capabilities should be defined with a full resource commitment, until the end-of-life of the ADDF deployment.
-
Use a multi-account architecture – Each ADDF instance should be deployed in its own dedicated AWS multi-account environment, without any other unrelated workloads. As defined in the AWS account management and separation (AWS Well-Architected Framework), it is considered best practice to separate resources and workloads into multiple AWS accounts, based on your organization's requirements. This is because an AWS account acts as an isolation boundary. A properly designed AWS multi-account architecture provides workload categorization and reduces the scope of impact in the event of a security breach, as compared to a single-account architecture. Using a multi-account architecture also helps your accounts remain within their AWS service quotas. Distribute your ADDF modules across as many AWS accounts as needed to meet your organization's security and separation-of-duties requirements.
-
Deploy multiple ADDF instances – Set up as many separate ADDF instances as you need in order to properly develop, test, and deploy ADDF modules according to your organization's software development processes. When setting up multiple ADDF instances, you can use one of the following approaches:
-
Multiple ADDF instances in different AWS multi-account environments – You can use separate AWS accounts to isolate different ADDF instances. For example, if your organization has dedicated development, testing, and production stages, you can create separate ADDF instances and dedicated accounts for each stage. This provides many benefits, such as reducing the risk of any error propagating across stages, helping you implement an approval process, and restricting user access to only certain environments. The following image shows two ADDF instances deployed in separate, multi-account environments.
-
Multiple ADDF instances in the same AWS multi-account environment – You can create multiple ADDF instances that share the same AWS multi-account environment. This effectively creates isolated branches in the same AWS accounts. For example, if different developers are working in parallel, a developer can create a dedicated ADDF instance in the same AWS accounts. This helps developers work in isolated branches for development and testing purposes. If you use this approach, for each ADDF instance, your ADDF resources must have unique resource names. This is supported in ADDF pre-supplied modules by default. You can use this approach as long as you do not exceed the AWS service quotas. The following image shows two ADDF instances deployed in a shared, multi-account environment.
-
Multiple ADDF instances in the same AWS single-account environment – This architecture is very similar to the previous example. The difference is that the multiple ADDF instances are deployed in a single-account environment instead of a multi-account environment. This architecture can fit very simple ADDF use cases that have a very limited scope and multiple developers working on different branches at the same time.
Because SeedFarmer is the single tool that controls deployments for an ADDF instance, you can build any environment and account architecture that fits your organization's deployment strategy and CI/CD processes.
-
-
Customize the AWS Cloud Development Kit (AWS CDK) bootstrap process according to your organization's security requirements – By default, AWS CDK assigns the AdministratorAccess AWS managed policy during the bootstrapping process. This policy grants full administrative privileges. If this policy is too permissive for your organization's security requirements, you can customize which policies are applied. For more information, see Custom least-privilege policy for the AWS CDK deployment role.
-
Adhere to best practices when setting up access in IAM – Establish a structured AWS Identity and Access Management (IAM) access solution that allows your users to access the ADDF AWS accounts. The framework of ADDF is designed to adhere to the principle of least privilege. Your IAM access pattern should also follow the principle of least privilege, should be compliant with your organization's requirements and should adhere to the Security best practices in IAM (IAM documentation).
-
Set up networking according to your organization's best practices – ADDF includes an optional networking AWS CloudFormation stack that creates a basic public or private virtual private cloud (VPC). Depending on your organization's configuration, this VPC might expose resources directly to the internet. We recommend that you follow your organization's networking best practices and create a custom security-hardened network module.
-
Deploy security prevention, detection, and mitigation measures at the AWS account level – AWS offers various security services, such as Amazon GuardDuty, AWS Security Hub, Amazon Detective, and AWS Config. Enable those services in your ADDF AWS account and integrate your organization's security prevention, detection, mitigation, and incident-handling processes. We recommend that you follow Best Practices for Security, Identity, & Compliance
(AWS Architecture Center) and any service-specific recommendations contained in the documentation for that service. For more information, see AWS Security Documentation.
ADDF doesn't address any of these topics because the implementation and configuration details heavily depend on the requirements and processes that are specific to your organization. Instead, it's the core responsibility of your organization to address these topics. Commonly, the team that manages your AWS landing zone helps you plan and implement your ADDF environment.
Initial setup
Set up ADDF according to the ADDF Deployment Guide/manifest folder in the autonomous-driving-data-framework/manifest/example-dev folder contains a sample deployment for demo
purposes. Use this sample as a starting point for designing your own deployment. In that
directory, there is an ADDF deployment manifest file called deployment.yaml. It contains all the information for SeedFarmer to
manage, deploy, or delete ADDF and its resources in the AWS Cloud. You can create
groups of ADDF modules in dedicated files. The core-modules.yaml is an example of the core module group, and it
includes all core modules provided by ADDF. To summarize, the deployment.yaml file contains all references to the groups and modules
that will be deployed to their target accounts and specifies the deployment
order.
For a secure and compliant configuration, especially in an environment that isn't for proof of concept, we recommend that you review the source code of each module that you intend to deploy. According to security hardening best practices, you should deploy only modules that are required for your intended use case.
Note
ADDF modules in the modules/demo-only/ folder aren't security
hardened and shouldn't be deployed in production environments or in any environment
with sensitive or protected data. These modules are included to showcase system
capabilities, and you can use them as the base for creating your own customized,
security-hardened modules.
Customizing the ADDF deployment framework code
The ADDF deployment framework and its orchestration and deployment logic can be fully customized to meet any requirements. However, we suggest you either refrain from customizing or minimize your changes for the following reasons:
-
Keep upstream compatibility – Upstream compatibility makes it easier to update ADDF for the latest features and security updates. Changing the framework breaks native backwards compatibility with SeedFarmer, CodeSeeder, and any ADDF core modules.
-
Security consequences – Changing the ADDF deployment framework can be a complex task that can have unintended security consequences. In the worst-case scenario, framework changes can create security vulnerabilities.
When possible, build and customize your own module code instead of modifying the ADDF deployment framework and ADDF core module code.
Note
If you feel that specific parts of the ADDF deployment framework need improvement or further security hardening, please contribute your changes to the ADDF repository through a pull request. For more information, see Open-source security reviews and contributions.
Writing custom modules in ADDF
Creating a new ADDF module or extending an existing module is a core concept of ADDF. When creating or customizing modules, we suggest that you follow general AWS security best-practices and your organization's best practices for secure coding. Furthermore, we recommend that you conduct initial and periodic internal or external technical security reviews, based on your organization's security requirements, to further reduce the risk of security issues.
Reoccurring ADDF deployments
Deploy ADDF and its modules as described in the ADDF Deployment Guide
This approach follows the GitOps paradigm, where your source repository (the local
code base where you operate SeedFarmer) is the source of truth, and the infrastructure
declared explicitly in it is the desired outcome of your deployment. For more
information about GitOps, see What
is GitOps
Reoccurring security audits
Just like any other software in your organization, integrate ADDF and your custom ADDF module code into your security risk management, security review, and security audit cycle.
ADDF updates
ADDF receives regular updates as part of its ongoing development effort. This
includes feature updates, and security-related improvements and fixes. We recommend that
you regularly check for new framework releases and apply updates in a timely manner. For
more information, see Steps to update ADDF
Decommissioning
If ADDF is no longer needed, delete ADDF and all its related resources from your
AWS accounts. Any unattended and unused infrastructure incurs unnecessary costs and
poses a potential security risk. For more information, see Steps to destroy ADDF
