Feature Request
Is your feature request related to a problem? Please describe.
I have an issue when I need to store sensitive data within the confines of the Ansible operator. At present, there isn't a means to do so using native Ansible features like ansible-vault.
Describe the solution you'd like
We use ansible-vault to encrypt secrets within the confines of an ansible playbook. This is simply done using the ansible-vault command, pasting in a string to encrypt, and it returns a hash. In order to access the secrets, the --ask-vault-pass option must be supplied to the ansible-playbook command. A prompt is given asking for the vault password, and the password used to create it is used to reveal/decrypt the value.
There's also an option to have a file on the ansible host that contains the password, and this can be fed into the ansible-playbook command in lieu of the ask-vault-pass option.
With the current operator, there's not way, as far as I know, to have ansible run with an option to read a password file, or otherwise. Even so, some mechanism to store the password on the image securely is needed. One option perhaps would be to store the vault password as a k8s secret and looking it up with the ansible k8s module to create the password file, or build a way within the operator binary to look up the k8s secret.
One drawback with this approach is getting the vault password created in the first place. Maybe something like bitnami-labs/sealed-secrets can be used here. Overall perhaps use of sealed secrets addresses some of these challenges, however having a one-stop-shop of native ansible functionality within the confines of the operator makes things a bit more fluid.
My current use case is around storing usernames and passwords in a configuration file for an application, specifically Jetty. The passwords differ across our data center environments, so having the power of group_vars or the like (without having to rely on an inventory) within ansible could be useful within an operator use case. Therefore, this config file needs to be an Ansible template. "The like" would be doing something like this to get namespace specific values, for example, our namespaces may be named solr-dev, solr-tst, solr-prd:
└── roles
└── solr.provisioning
├── defaults
│ └── main.yml
├── meta
│ └── main.yml
├── tasks
│ └── main.yml
├── templates
│ ├── solr.yaml.j2
│ └── zookeeper.yaml.j2
└── vars
├── main.yml
└── solr-dev.yml
- name: Include environment specific jetty variables
include_vars: "{{ namespace }}.yml
Now, with all of that said, one of the challenges in my environment is the k8s admin not allowing a service account to create secrets. If I could do that, then I could just set a bunch of facts and use those as vars to supply the credentials to a k8s secret that's simply stringData. Our service accounts, at present, are allowed to perform verbs against any CRDs we've created within the platform. Native CRs are more of less off limits since our service accounts are cluster scoped (service account lives in the namespace of the operator and our operators are cluster scoped).
Regardless, having the ability to use native ansible-vault as opposed to having to rely on k8s secrets (or in some cases in conjunction with k8s secrets) may make things a bit more flexible.
Feature Request
Is your feature request related to a problem? Please describe.
I have an issue when I need to store sensitive data within the confines of the Ansible operator. At present, there isn't a means to do so using native Ansible features like ansible-vault.
Describe the solution you'd like
We use ansible-vault to encrypt secrets within the confines of an ansible playbook. This is simply done using the
ansible-vaultcommand, pasting in a string to encrypt, and it returns a hash. In order to access the secrets, the--ask-vault-passoption must be supplied to theansible-playbookcommand. A prompt is given asking for the vault password, and the password used to create it is used to reveal/decrypt the value.There's also an option to have a file on the ansible host that contains the password, and this can be fed into the
ansible-playbookcommand in lieu of theask-vault-passoption.With the current operator, there's not way, as far as I know, to have ansible run with an option to read a password file, or otherwise. Even so, some mechanism to store the password on the image securely is needed. One option perhaps would be to store the vault password as a k8s secret and looking it up with the ansible k8s module to create the password file, or build a way within the operator binary to look up the k8s secret.
One drawback with this approach is getting the vault password created in the first place. Maybe something like bitnami-labs/sealed-secrets can be used here. Overall perhaps use of sealed secrets addresses some of these challenges, however having a one-stop-shop of native ansible functionality within the confines of the operator makes things a bit more fluid.
My current use case is around storing usernames and passwords in a configuration file for an application, specifically Jetty. The passwords differ across our data center environments, so having the power of group_vars or the like (without having to rely on an inventory) within ansible could be useful within an operator use case. Therefore, this config file needs to be an Ansible template. "The like" would be doing something like this to get namespace specific values, for example, our namespaces may be named
solr-dev,solr-tst,solr-prd:Now, with all of that said, one of the challenges in my environment is the k8s admin not allowing a service account to create secrets. If I could do that, then I could just set a bunch of facts and use those as vars to supply the credentials to a k8s secret that's simply stringData. Our service accounts, at present, are allowed to perform verbs against any CRDs we've created within the platform. Native CRs are more of less off limits since our service accounts are cluster scoped (service account lives in the namespace of the operator and our operators are cluster scoped).
Regardless, having the ability to use native ansible-vault as opposed to having to rely on k8s secrets (or in some cases in conjunction with k8s secrets) may make things a bit more flexible.