AWX Security Insights and Best Practices for a Resilient Deployment
Imagine having a reliable assistant that can streamline and automate your everyday tasks, from managing servers to deploying applications, all while ensuring the utmost security of your digital assets. Meet AWX, an open-source, web-based automation platform that is a product of Red Hat Ansible Automation Platform built on Ansible. Designed to streamline complex workflows and empower organizations to efficiently handle their operations, AWX offers a centralized solution for orchestrating tasks and processes across diverse environments.
The power of automation within AWX comes together with the critical responsibility of safeguarding sensitive data and infrastructure. In an era where cyber threats appear large, safeguarding sensitive data and infrastructure from potential vulnerabilities is paramount. Therefore, understanding and implementing robust security measures within AWX deployments is crucial for maintaining the integrity and resilience of your automation platform.
Understanding AWX Security
Understanding AWX security is essential for ensuring the integrity and protection of your automation platform. Common security challenges faced by AWX deployments include vulnerabilities in software components, misconfigurations, and unauthorized access to sensitive data.
For instance, outdated software versions within AWX may contain known security vulnerabilities, leaving systems susceptible to exploitation by malicious actors. One notable security issue faced by AWX was the vulnerability tracked as CVE-2021-26855, commonly known as ProxyLogon. This vulnerability affected Microsoft Exchange Server but also had implications for AWX instances that utilized Exchange integrations. ProxyLogon allowed remote attackers to execute arbitrary code on vulnerable servers without authentication, potentially leading to data breaches, system compromise, and unauthorized access to sensitive information.
This security issue highlighted the importance of applying security patches and updates to lessen the risk of exploitation. Additionally, it underscored the need for organizations to regularly assess and secure their software dependencies, including integrations with third-party systems like Microsoft Exchange, to prevent exposure to known vulnerabilities and protect their infrastructure from potential threats.
Best Practices for AWX Security
Implementing best practices is paramount to ensure the security of AWX deployments. Following security considerations helps you keep up with emerging threats and keeps you updated.
Admin User Account Configurations
It is good practice to change the default credentials and use custom credentials instead as the default credentials are unsecure. Enable the following configurations to have a secure AWX account:
- Set custom admin username, email, and password instead of default values.
- Three variables are customizable for the admin user account creation:
- admin_user
- admin_email
- admin_password_secret
- admin_password_secret must be a Kubernetes secret and not your text-clear password.
- If admin_password_secret is not provided, the operator will look for a secret named <resourcename>-admin-password for the admin password.
- If it is not present, the operator will generate a password and create a Secret from it named <resourcename>-admin-password
- To retrieve the admin password, run: kubectl get secret <resourcename>-admin-password -o jsonpath=”{.data.password}” | base64 –decode; echo
Secret Key Configuration
This key is used to encrypt sensitive data in the database. Secrets should always be used instead of plain text when storing sensitive data.
- The variable used is secret_key_secret.
- secret_key_secret must be a Kubernetes secret, not your text’s clear secret value.
- If secret_key_secret is not provided, the operator will look for a secret named <resourcename>-secret-key for the secret key.
- If it is absent, the operator will generate a password and create a Secret named <resourcename>-secret-key.
- It is important not to delete this secret as it will be needed for upgrades and if the pods get scaled down at any point. If you are using a GitOps flow, you will want to pass a secret key secret. The secret key should be formatted as:
We would then need to define the secret key in the AWX spec file:
Service Type
If the service_type is not specified, the ClusterIP service will be used for your AWX Tower service. The service_type supported options are ClusterIP, LoadBalancer, and NodePort. The variables that are customizable for any service_type are service_labels and service_annotations
Load Balancer
The following variables are customizable only when service_type=LoadBalancer
| Name | Description | Default |
| loadbalancer_protocol | Protocol to use for Loadbalancer ingress | HTTP |
| loadbalancer_port | Port used for Loadbalancer ingress | 80 |
| loadbalancer_ip | Assign Loadbalancer IP | ” |
Node Port
The following variables are customizable only when service_type=NodePort
| Name | Description | Default |
| nodeport_port | Port used for NodePort | 30080 |
Ingress Type
By default, the AWX operator is not opinionated and won’t force a specific ingress type on you. So, when the ingress_type is not specified, it will default to none, and nothing ingress-wise will be created. The ingress_type supported options are none, ingress, and route. To toggle between these options, add the following to your AWX CRD.
Generic Ingress Controller
The following variables are customizable when ingress_type=ingress. The ingress type creates an Ingress resource as documented, which can be shared with many other Ingress Controllers as listed.
| Name | Description | Default |
| ingress_annotations | Ingress annotations | Empty string |
| ingress_tls_secret (deprecated) | Secret that contains the TLS information | Empty string |
| ingress_class_name | Define the ingress class name | Cluster default |
| hostname (deprecated) | Define the FQDN | {{ meta.name }}.example.com |
| ingress_hosts | Define one or multiple FQDN with an optional Secret that contains the TLS information. | Empty string |
| ingress_path | Define the ingress path to the service. | / |
| ingress_path_type | Define the type of the path (for LBs) | Prefix |
| ingress_api_version | Define the Ingress resource apiVersion | ‘networking.k8s.io/v1’ |
| ingress_api_version | Define the Ingress resource apiVersion | ‘networking.k8s.io/v1’ |
Route
The following variables are customizable when ingress_type=route
| Name | Description | Default |
| route_host | Common name the route answers for | <instance-name>-<namespace>-<routerCanonicalHostname> |
| route_tls_termination_mechanism | TLS Termination mechanism (Edge, Passthrough) | Edge |
| route_tls_secret | Secret that contains the TLS information | Empty string |
| route_api_version | Define the Route resource apiVersion | ‘route.openshift.io/v1’ |
Privileged Tasks
Depending on the type of tasks you’ll be running, you may need the task pod to run as privileged. This can open you up to various security concerns, so you should be aware (and verify that you have the privileges) to do this only if necessary. To toggle this feature, add the following to your custom resource. Disable privileged tasks if not needed to avoid a security concern.
Priority Classes
The AWX and Postgres pods can be assigned a custom PriorityClass to rank their importance compared to other pods in your cluster, determining which pods get evicted first if resources run low. First, create your PriorityClass if needed. Then, set the name of your priority class to the control plane and Postgres pods, as shown below.
AWX and Postgres pods should have a priority class so they get evicted the last from the node.
CSRF Cookie Secure Setting
If this is set to True, the cookie will be marked as “secure, ” meaning browsers may ensure that the cookie is only sent with an HTTPS connection.
With csrf_cookie_secure, you can pass the value for CSRF_COOKIE_SECURE to /etc/tower/settings.py
Example configuration of the csrf_cookie_secure setting:
If this is set to True, the cookie will be marked as “secure,” which means browsers may ensure that the cookie is only sent under an HTTPS connection. Leaving this setting off isn’t a good idea because an attacker could capture an unencrypted session cookie with a packet sniffer and use the cookie to hijack the user’s session.
With session_cookie_secure, you can pass the value for SESSION_COOKIE_SECURE to /etc/tower/settings.py
Example configuration of the session_cookie_secure setting:
Conclusion
In conclusion, maintaining AWX deployments is crucial in today’s cybersecurity landscape, where threats continue to evolve and multiply. As a security engineer working against advanced attacks and threats, I urge fellow IT professionals to prioritize security measures and implement recommended best practices without delay. By adopting robust authentication mechanisms, regularly updating and patching software components, and leveraging encryption and monitoring tools, we can fortify our AWX deployments against potential threats and vulnerabilities. Let us not wait for a security breach to occur. Instead, let’s strengthen our defenses and ensure the resilience of our automation platform. Together, we can create a safer and more secure digital environment. For more insightful blogs, visit auxin.io
