[GH-ISSUE #205] Deploying The Bastion with modern tools #52

New issue

Closed

opened 2026-05-07 00:18:10 +02:00 by BreizhHardware · 2 comments

BreizhHardware commented

2026-05-07 00:18:10 +02:00

Owner

Originally created by @jacen05 on GitHub (Jun 21, 2021).
Original GitHub issue: https://github.com/ovh/the-bastion/issues/205

Hello,

I'm trying to find out how to integrate The Bastion with our stack based on Ansible/Packer/Terraform.
The installation part seems easy as your installation scripts are working very well.
However I see 2 problems:

How can I provision users (bastion admin and regular ssh users) to the bastion with a script (or with another Ansible provider)? Running /opt/bastion/bin/plugin/restricted/accountCreate --account tester (with all other needed parameters) results in Invalid IP address (tester)
How can I define myself the egress keys for the users? The goal is to provision the public key to the target servers when deploying them. It would preferable to be able to define the key instead of only fetching the generated public key, so there is no temporal dependency when building/deploying the bastion and target servers.

Thanks!

Originally created by @jacen05 on GitHub (Jun 21, 2021). Original GitHub issue: https://github.com/ovh/the-bastion/issues/205 Hello, I'm trying to find out how to integrate The Bastion with our stack based on Ansible/Packer/Terraform. The installation part seems easy as your installation scripts are working very well. However I see 2 problems: - How can I provision users (bastion admin and regular ssh users) to the bastion with a script (or with another Ansible provider)? Running `/opt/bastion/bin/plugin/restricted/accountCreate --account tester` (with all other needed parameters) results in `Invalid IP address (tester)` - How can I define myself the egress keys for the users? The goal is to provision the public key to the target servers when deploying them. It would preferable to be able to define the key instead of only fetching the generated public key, so there is no temporal dependency when building/deploying the bastion and target servers. Thanks!

BreizhHardware closed this issue

2026-05-07 00:18:11 +02:00

BreizhHardware commented

2026-05-07 00:18:11 +02:00

Author

Owner

@speed47 commented on GitHub (Jun 24, 2021):

Hello,

Yes, this is important for the project to ensure that it's easy to deploy with these standard tools! About your remarks:

To create admin accounts, you have the setup-first-admin-account.sh script. When #203 is tagged in a release (it's already merged, so it should be in a few days), the script will also be able to create more than one admin account
For regular accounts, the nominal use case is to create them using the restricted accountCreate command. This command can be given to any preexisting account on the server. That's how we do it: we have a "robot" account that can only use the accountCreate and accountDelete commands. This account doesn't have access to any server behind the bastion (it has the "osh-only" flag set, so it can't use SSH), and this robot account is linked to our HRIS so create/delete accounts accordingly. This way, installation of a new bastion and provisioning are decoupled. However, if you still want to manually create those regular accounts during your installation, because you have a hard-coded list somewhere, you should be able to manually call the plugin as you tried, but you need to insert 4 empty parameters between the command and the actual parameters (these parameters contain plumbing information that you don't need in that case): HOME=/root USER=root /opt/bastion/bin/plugin/restricted/accountCreate '' '' '' '' --account tester. This is not a really supported way of doing it but it should work. The proper way would be to create an account that can use accountCreate, and use this account to create all the accounts.
About the egress keys, what you need is probably using group accesses. When you create a group on the bastion, you have a public key, and then you can set this public key in your automation to deploy the remote infrastructure of the target servers. You don't need to have accounts on the bastion to do that. Then, when accounts are created, you may grant them to this/these groups.

@speed47 commented on GitHub (Jun 24, 2021): Hello, Yes, this is important for the project to ensure that it's easy to deploy with these standard tools! About your remarks: - To create admin accounts, you have the `setup-first-admin-account.sh` script. When #203 is tagged in a release (it's already merged, so it should be in a few days), the script will also be able to create more than one admin account - For regular accounts, the nominal use case is to create them using the restricted **accountCreate** command. This command can be given to any preexisting account on the server. That's how we do it: we have a "robot" account that can only use the accountCreate and accountDelete commands. This account doesn't have access to any server behind the bastion (it has the "osh-only" flag set, so it can't use SSH), and this robot account is linked to our HRIS so create/delete accounts accordingly. This way, installation of a new bastion and provisioning are decoupled. However, if you still want to manually create those regular accounts during your installation, because you have a hard-coded list somewhere, you should be able to manually call the plugin as you tried, but you need to insert 4 empty parameters between the command and the actual parameters (these parameters contain plumbing information that you don't need in that case): `HOME=/root USER=root /opt/bastion/bin/plugin/restricted/accountCreate '' '' '' '' --account tester`. This is not a really supported way of doing it but it should work. The proper way would be to create an account that can use accountCreate, and use this account to create all the accounts. - About the egress keys, what you need is probably using group accesses. When you create a group on the bastion, you have a public key, and then you can set this public key in your automation to deploy the remote infrastructure of the target servers. You don't need to have accounts on the bastion to do that. Then, when accounts are created, you may grant them to this/these groups.

BreizhHardware commented

2026-05-07 00:18:12 +02:00

Author

Owner

@speed47 commented on GitHub (Sep 18, 2025):

An ansible role has been developed by the community, https://github.com/adfinis/ansible-role-the_bastion for reference (also linked in the README)

@speed47 commented on GitHub (Sep 18, 2025): An ansible role has been developed by the community, https://github.com/adfinis/ansible-role-the_bastion for reference (also linked in the README)

BreizhHardware referenced this issue

2026-05-07 00:19:46 +02:00

[PR #52] [MERGED] enh: install: freebsd: check whether acls are enabled #195