Nomad is a versatile tool for scheduling workloads, and it becomes especially useful when handling sensitive information such as secrets. In this discussion, we will delve into the concept of Nomad variables, which offer a secure and efficient method to manage secrets in Nomad, preventing them from being exposed in job files.
Understanding Nomad Variables
Nomad variables form an integral part of HashiCorp’s Nomad, a tool designed for orchestrating various types of workloads. Built on a robust configuration store, Nomad variables encrypt values by default, ensuring secure access by jobs within the variable’s scope. Essentially, a Nomad variable is a collection of key-value pairs that can be retrieved by a Nomad job to help it perform its tasks securely.
The Role of Namespaces and Scopes
Namespaces in Nomad are crucial for maintaining separation and security among jobs and users within a Nomad cluster. Each variable belongs to a specific namespace, ensuring that only authorized jobs can access it. This separation prevents unauthorized access from rogue jobs or jobs from other namespaces. Nomad Access Control Lists (ACLs) further bolster this security by providing fine-grained access control.
In scenarios where multiple jobs exist within the same namespace, access can be restricted to specific jobs. For instance, if a namespace contains both job A and job B, access to variable A can be limited to job A alone. The configuration of Nomad variables is designed to facilitate such restrictions easily. Each variable has a path-based address that specifies which tasks, task groups, or jobs can access it.
How to Create Nomad Variables
Creating Nomad variables begins with defining a namespace. This is typically done using a specification file, such as example-namespace.hcl, which outlines the namespace’s name, description, metadata, and capabilities. Here’s a snippet of how the namespace is defined:
“`hcl
Name of namespace
name = "example"
Description of namespace
description = "Example namespace for Nomad variables demo1"
Metadata for the namespace
meta {
owner = "devopsrob"
}
Namespace capabilities configuration
capabilities {
enabled_task_drivers = ["docker"]
}
<br /> <br /> Once the namespace is set up, variables can be created within it using the CLI or API. The preferred method involves using inline configuration values, which is considered a best practice. However, a specification file can also be used for a configuration-driven approach. Here’s how you can create a variable for all jobs in the example namespace:<br /> <br /> shell
nomad var put -force \
-namespace example \
nomad/jobs \
secret_author=devopsrob \
role=developer
``<br /> <br /> Alternatively, a specification file (spec.nv.hcl`) can be used to achieve the same result, although storing secrets in plaintext within files is not recommended due to security concerns.
Consuming Nomad Variables
After creating a variable, the next step is to configure a job file to consume it. A common approach is to use environment variables, adhering to the twelve-factor app principles. In a demo application, environment variables are read and output to a web UI. The relevant function in the application code is as follows:
go<br /> func updateSecrets() {<br /> mu.Lock()<br /> defer mu.Unlock()<br /> secretOne = os.Getenv("SECRET_ONE")<br /> secretTwo = os.Getenv("SECRET_TWO")<br /> }<br />
This function retrieves values from two environment variables: SECRET_ONE and SECRET_TWO. The application is packaged as a Docker image, which can be deployed using a Nomad job file. The job file specifies how the application accesses secrets from Nomad variables as environment variables.
Securing Nomad Variables
Despite the built-in encryption of Nomad variables, the Key Encryption Key (KEK) is stored in plaintext on the Nomad server, posing a potential security risk. To mitigate this, Nomad supports KEK wrapping through external Key Management Systems (KMS), such as HashiCorp Vault, Azure Key Vault, AWS KMS, and GCP Cloud KMS.
This KEK wrapping adds an extra layer of security by using specialized external systems to manage the root encryption key. It not only enhances the protection of Nomad variables but also secures other operations that depend on the keyring, such as signing JSON Web Tokens (JWTs) for Nomad workload identities and OpenID Connect (OIDC) client assertions.
Summary
Nomad variables offer a straightforward yet powerful solution for managing application configuration and secrets. By leveraging the principles of twelve-factor apps, developers can efficiently integrate these variables into their applications. In upcoming discussions, we will explore the integration of Vault into Nomad to further enhance secret management capabilities.
For more technical insights and detailed instructions, you can refer to HashiCorp’s official documentation. This resource provides comprehensive guidance on utilizing Nomad variables effectively within your projects.
For more Information, Refer to this article.
