Skip to main content

​
Networking

Yes. You must provide an IP for the NAT gateway to access the Astronomer and Airflow user interfaces, and also to interact with the platform with the astro-cli tool. Reviewing our Terraform scripts and installation guides are helpful to better understand this requirement.
Yes. Inbound traffic routes through the NAT gateway. TLS is utilized throughout, and is configured automatically with our setup scripts.
Yes. The commander component would require a special build if operating in an air-gapped environment.
Yes. Connecting to your data and data systems require networking outside of the Kubernetes cluster that Airflow is running within. These connections can be made either through the public internet or through private networking that you have configured.
Yes. Airflow deployments check for updates and security fixes to updates.astronomer.io. This feature is effectively disabled in air-gapped deployments.Beyond that, the platform does not need to connect to outside domains for routine execution of the platform. External connections are only required by Airflow in the execution of specific workflows.

​
Docker

You can find a list of all components used by the platform in the Astronomer Platform - Docker images Google Sheet.

​
System-level access requirements

No. Astronomer makes use of Kubernetes cluster-level features (including K8s RBAC) by design. These features include creating / deleting namespaces, daemonsets, roles, cluster-roles, service-accounts, resource-quotas, limit-ranges, etc. Additionally, Astronomer dynamically creates new airflow instances in separate namespaces, which protects data engineer users from noisy neighbors.
Astronomer defines the required Roles or ClusterRoles. The default mode requires a ClusterRole that has access to create namespaces and other objects for new Airflow deployments.
No. Review the Astronomer Helm chart repo to learn more about Astronomer Software default configurations.

​
Deployment

The default method for installing and upgrading Astronomer Software is using the Astronomer Helm chart located at https://helm.astronomer.io. See the Astronomer Software installation guides (AWS, GCP, and Azure) and Upgrade Astronomer.

​
Authentication

Astronomer provides an authentication front end with pre-built integrations for Google Auth, Okta, Auth0, and others.

​
Continuous vulnerability assessment and remediation

No. Astronomer continuously scans all code and Docker images with vulnerability assessment software. Issues can occur when your software blocks critical pods from launching.

​
Malware defenses

The Astronomer and Airflow UIs sanitize and verify inputs according to modern standards.

​
User sessions

Yes. The Transport Layer Security (TLS) encryption protocol is configured automatically with Astronomer setup scripts.
Yes. Sessions are terminated after 24 hours of inactivity for both Astronomer Software and CLI by default.
Astronomer Software uses the Secure Sockets Layer (SSL) encryption protocol by default. During installation, you must provide either a wildcard certificate or a certificate for the following domains:
  • BASEDOMAIN
  • app.BASEDOMAIN
  • deployments.BASEDOMAIN
  • registry.BASEDOMAIN
  • houston.BASEDOMAIN
  • grafana.BASEDOMAIN
  • kibana.BASEDOMAIN
  • install.BASEDOMAIN
  • alertmanager.BASEDOMAIN
  • prometheus.BASEDOMAIN

​
External monitoring

Yes. All logs are sent to ElasticSearch through FluentD by default. You can customize the FluentD configuration to send logs to other destinations, or route logs from Elasticsearch to your monitoring systems.
Yes. Airflow supports email alerting features for DAG failures, and Astronomer supports email alerting for infrastructure issues.

​
Restricting access

The platform API and web UI are served over a single highly available AWS load balancer. By using an internal load balancer, the entire platform will only be accessible in a private network.

​
Auditing

Logs from each Astronomer service are accessible to you through your cloud provider. Astronomer does not generate audit logs for the Astronomer platform.
All platform components and Airflow deployment logs are retained within the platform’s logging stack for 15 days. This is useful for searching recent logs using the Kibana interface to ElasticSearch. For log backup to comply with policy, container stdout and stderr logs may also be collected in AWS CloudWatch and can be persisted according to your CloudWatch logs retention policy. For AWS API security and auditing, Astronomer recommends enabling AWS CloudTrail.
Astronomer’s Software offering has a robust logging structure sitting atop Airflow. See Kibana logging on Astronomer Software.

​
Updating

You can upgrade your Airflow Deployments separately from your platform upgrades. Astronomer recommends updating your Deployment’s Airflow versions and the platform frequently so that your organization is always using a supported version. See Astronomer Software and lifecycle policy.
Kubernetes and node upgrades are typically managed by your organization. Platform version upgrades are performed with Helm and with the assistance of Astronomer support when required. See Upgrade Astronomer.