Add ansible CI workflow, move variables to vars*

[pat-s]

• Rename host for a clean name
• Move variables out of playbook
• Add apply workflow for main branch
• Add check workflow for PRs

[anbraten]

The pipelines to check the ansible configs looks really nice. Could you check it again, so we could merge it. Auto-deploying on main could be a bit too much for the beginning, maybe a manual pipeline would be better

[pat-s]

@anbraten The workflow waits for a secret called ansible_vault_password. To connect to the instance, you also need to add an SSH key.

Overall, storing secrets as WP secrets is fine if they are imported as env vars, see e.g. https://codeberg.org/Codeberg-Infrastructure/configuration-as-code/src/commit/9b8cd385f277c403edf49ed14504957c9303fded/environments/production/group_vars/ci.yml#L5. This way, secrets are masked in WP log output automatically.

[anbraten]

@pat-s Sorry. Just added the secret now.

[pat-s]

vault-pass.secret does not exist in the repo. You probably don't want to add it.

If remote execution is the goal, using WP secrets would also be fine. Or an external secret manager which allows easier/safer CI integration.

[anbraten]

In vault-pass.secret is just the secret which I've added to ansible_vault_password. Not sure what vault-password of the plugin expects. We could simply run echo "$${ansible_vault_password}" > vault-pass.secret before the plugin is executed if that helps.

[pat-s]

It is likely due to drone-plugins/drone-ansible#31

See https://docs.ansible.com/ansible/latest/vault_guide/vault_managing_passwords.html#managing-multiple-passwords-with-vault-ids for using a file with ansible vault which holds all secrets.
To decrypt it, it seems one needs to use vault-id and vault-password-file. I am referring to group_vars/all/vault.yaml.

I haven't worked with ansible-vault before. Do you want to continue trying to get this working?

[anbraten]

The ansible plugin restructuring introduced a bug. Fixed it in here: https://codeberg.org/woodpecker-plugins/ansible/pulls/10

[pat-s]

Still the same error with the PR image.

[anbraten]

That fixed it. Now we need to get the ssh key to work.

[anbraten]

Works now. I changed the project to require approvals now, so no-one is stealing our credentials / changing sth.

[pat-s]

Works now.

Great!

I changed the project to require approvals now, so no-one is stealing our credentials / changing sth.

Is this really needed? I thought long about this for Codebergs repo and came to the conclusion that stealing secrets is not really (easily) possible. Even when adding a custom shell command and cat'ing secrets, these are masked in the output if they are formatted as env vars. And the ansible diff doesn't expose them either. The only hacky way I could think about is sending a file to a remote storage and viewing the secrets there.

Maybe there is another (easy) way to forcefully expose secrets and work around that but I haven't found one yet. And even if, this would require triggering PRs against this repo first and nobody would attempt this / it can't be done hidden. Let me know if I overlook a possibility :)

[anbraten]

Is this really needed? I thought long about this for Codebergs repo and came to the conclusion that stealing secrets is not really (easily) possible. Even when adding a custom shell command and cat'ing secrets, these are masked in the output if they are formatted as env vars. And the ansible diff doesn't expose them either. The only hacky way I could think about is sending a file to a remote storage and viewing the secrets there.

You can adjust the ansible config to do some action as root and you can adjust step in the woodpecker-ci config to not only check, but apply the config, so it would be basically free root access if I don't miss anything.

I think requiring approval for forks only would be really helpful, but my attempt to implement this for the most common "security modes" in woodpecker-ci/woodpecker#3348 wasn't liked too much 😕.

[pat-s]

Oh dear! I was so focused on secrets all the time that I overlooked the most obvious exploit 🤦
Yes, one could just change check: false and become: true to apply commands as root 👀

Requiring approval for fork PRs adds a good protection layer yes as then only people with write access to the repo could open PRs which do not originate from forks.
That being said, I'll also protect the Codeberg pipelines now...thanks 🙄

[pat-s]

Ready to merge?