hqdncw / vault-autopilot Goto Github PK

As a user of Vault-Autopilot, I would like to request that the schema for the manifest files used for defining the desired state for resources like Password, SSHKey, Issuer, and others be published to SchemaStore.org. This would provide a centralized location for users to access and validate their manifest files, ensuring consistency and correctness in the defined desired states.

See Also

https://www.jetbrains.com/help/pycharm/json.html#ws_json_using_schemas

It would be useful to have a dry-run mode that allows users to see what changes would be made without actually applying them. This could be achieved with a flag like --dry-run.

Currently, vault-autopilot does not properly handle KeyboardInterrupt or other termination signals. This issue aims to address this limitation by implementing support for these signals, allowing users to quickly and cleanly exit vault-autopilot when needed.

See Also

https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html

Absolute paths are clearer and unambiguous, but less practical for frequent usage due to length and difficulty in typing. In most cases, our CLI is used with a fixed workdirectory that doesn't change, so we can take advantage of relative paths for better readability and efficiency.

Currently, the vault-autopilot CLI does not offer user-friendly error messages when it encounters problems with configuration or manifest files. Specifically, the error messages do not provide enough information about the location of the problem within the files, making it challenging for users to quickly diagnose and address the root cause of the problem.

For example, consider the following manifest file:

kind: "Issuer"
spec:
  name: "root-2024"
  secretEngine: "pki"
  certificate:
    commonName: "example.com Root Authority"

When applying this manifest file using the vault-autopilot apply, the error message displayed is not intuitive for users:

$ vault-autopilot -c config.yaml apply -f manifest.yaml
Error: Invalid manifest file: Failed to validate '../local/test.yaml': [{'type': 'missing', 'loc': ('spec', 'certificate', 'type'), 'msg': 'Field is required', 'input': {'com
monName': 'example.com Root Authority'}}]

Proposed improvement

For instance, if there's an issue with a manifest file, the CLI could display a detailed error message listing the specific fields that are missing or incorrect, along with the exact lines in the file where the problems are located.

With the proposed improvements, the output of the command could look something like this:

$ vault-autopilot -c config.yaml apply -f manifest.yaml
Error: Invalid manifest file: Failed to validate 'manifest.yaml':
  * 'type' is a required field in 'csrParams' (at line 5, column 3)

Please correct the highlighted fields in your manifest file and try again.

In order to ensure that vault-autopilot apply functions correctly when receiving input from STDIN, we need to implement test cases that cover this scenario.

The TODO comment in the provided code suggests implementing a custom file-based queue to prevent memory overflow when handling large datasets. However, since Docker containers can utilize disk space as a fallback when memory is exhausted via the --memory-swap flag, this concern is mitigated.

Given that the Vault-Autopilot CLI is intended for use in CI/CD pipelines, which are typically based on Docker containers, we can rely on Docker's built-in memory management features to handle large datasets. Therefore, implementing a custom file-based queue is no longer necessary, and we can avoid "reinventing the wheel" (see Wikipedia article).

When applying the manifest, it would be helpful to provide feedback to the user about the progress of the operation. Consider adding a progress bar or outputting a message for each resource that's being applied.

See Also

rust-lang/cargo#5721

Currently, Vault Autopilot CLI lacks the ability to offer auto-completion of commands and their associated options when users are interacting with the command line. This can lead to a slower and more cumbersome experience, especially for users who frequently use our tool or have to remember complex commands.

See Also

https://kubernetes.io/docs/reference/kubectl/generated/kubectl_completion/

Feature Request

As a Vault user, I want to easily set up and maintain my Public Key Infrastructure (PKI) by using YAML manifests to define and manage my Vault issuers. This would streamline the process, minimize errors, and speed up deployment.

Currently, setting up an intermediate certificate authority involves manually creating a Certificate Signing Request (CSR), signing it with the root issuer, and importing a signed CSR as an issuer. This process is time-consuming and prone to errors, especially when ensuring consistency across multiple environments.

With YAML manifests, we can solve these problems by declaring the issuer's configuration in a simple, human-readable format. Users can create a YAML file that specifies the issuer's settings, then use that file to automatically provision and configure the Vault issuer. This eliminates manual setup, reduces errors, and makes maintenance easier across different environments.

Here are some examples of what the YAML manifests might look like for different types of issuers:

Example 1: Declaring a root issuer

kind: "Issuer"
spec:
  name: "root-2023"
  secretEngine: "pki"
  certificate:
    type: "internal"
    commonName: "example.com"

In this example, we are declaring a root issuer with the name root-2023. The secretEngine field specifies the engine that will be used to generate the certificates, and the certificate field contains the parameters for generating the Certificate Signing Request (CSR).

Example 2: Declaring an intermediate issuer

kind: "Issuer"
spec:
  name: "example-dot-com-intermediate"
  secretEngine: "pki_int"
  certificate:
    type: "internal"
    commonName: "example.com Intermediate Authority"
  chaining:
    # Provide the reference to the root issuer that this issuer will chain to
    upstreamIssuerRef: "pki/root-2023"

In this example, we're creating an intermediate issuer with the name example-dot-com-intermediate. We provide the reference to the root issuer that this issuer will chain to using the upstreamIssuerRef field. This tells Vault Autopilot that this intermediate issuer should chain to the root issuer when issuing certificates.

As a user of Vault Autopilot, I would like to have comprehensive documentation that is easy to navigate and understand. Currently, the project lacks detailed documentation, which makes it difficult for new users to get started and for experienced users to find answers to their questions.

For example:

kind: "SecretsEngine"
spec:
  path: "secret"
  engine:
    type: "kv-v2"
    description: ""
    config:  # combines '/v1/secret/config' and '/sys/mounts/secret/tune'
      defaultLeaseTtl: ""
      ...  # https://developer.hashicorp.com/vault/api-docs/system/mounts#config
      maxVersions: 5  # https://developer.hashicorp.com/vault/api-docs/secret/kv/kv-v2#parameters
      casRequired: false
      deleteVersionAfter: "3h25m19s"
    local: false
    sealWrap: false
    externalEntropyAccess: false
---
kind: "SecretsEngine"
spec:
  path: "pki"
  engine:
    type: "pki"
    config:
      ...