Skip to content

Simplify cloud access profile setup#972

Draft
ideaship wants to merge 1 commit intomainfrom
rl_configure_cloud_access_profile
Draft

Simplify cloud access profile setup#972
ideaship wants to merge 1 commit intomainfrom
rl_configure_cloud_access_profile

Conversation

@ideaship
Copy link
Copy Markdown
Contributor

@ideaship ideaship commented Apr 8, 2026

Rewrite step 3 ("Configure your cloud access profile") of the testbed deployment guide to provide a single fast path using application credentials downloaded from Horizon.

The old version had several problems (see issue #960): clouds-public.yaml was mentioned without context, there was no guidance on application credential settings, no fast path for cloud access configuration, and it was unclear what credentials a provider actually supplies. The section tried to cover different cases (app credentials vs username/password, secure.yaml, profiles, cloud naming constraints) without offering a simple straight path.

Investigation showed that the downloaded clouds.yaml from Horizon already contains auth_url, region_name, and identity_api_version — all the information that
clouds-public.yaml provides via the profile parameter. The only extra field in clouds-public.yaml is image_format (for 4 providers), but Terraform does not use it. Default app credential settings (empty roles, Unrestricted=false) are sufficient, confirmed by a successful deployment.

The rewrite removes the username/password alternative (no clouds.yaml download available from Horizon, requiring manual YAML construction), the clouds-public.yaml/profile explanation, and the secure.yaml option. What remains is a linear set of concrete steps: create app credential in Horizon, download clouds.yaml, rename the cloud entry, and copy the file.

Closes: #960

AI-assisted: Claude Code

@github-actions
Copy link
Copy Markdown

github-actions bot commented Apr 8, 2026

MegaLinter analysis: Error

Descriptor Linter Files Fixed Errors Warnings Elapsed time
✅ ACTION actionlint 3 0 0 0.03s
✅ JSON jsonlint 4 0 0 0.13s
✅ JSON prettier 4 0 0 0.39s
✅ JSON v8r 4 0 0 5.73s
✅ MARKDOWN markdownlint 156 0 0 2.33s
✅ MARKDOWN markdown-table-formatter 156 0 0 0.41s
✅ REPOSITORY checkov yes no no 17.71s
✅ REPOSITORY git_diff yes no no 0.04s
✅ REPOSITORY secretlint yes no no 1.97s
✅ REPOSITORY trufflehog yes no no 4.38s
✅ SPELL codespell 164 0 0 0.47s
❌ SPELL lychee 164 1 0 20.1s
✅ YAML prettier 4 0 0 0.35s
✅ YAML v8r 4 0 0 5.66s
✅ YAML yamllint 4 0 0 0.51s

Detailed Issues

❌ SPELL / lychee - 1 error
[TIMEOUT] https://bugs.launchpad.net/keystonemiddleware/+bug/2129018 | Timeout
📝 Summary
---------------------
🔍 Total..........790
✅ Successful.....732
⏳ Timeouts.........1
🔀 Redirected.......0
👻 Excluded........57
❓ Unknown..........0
🚫 Errors...........0

Errors in docs/appendix/security/ossa-2026-001.md
[TIMEOUT] https://bugs.launchpad.net/keystonemiddleware/+bug/2129018 | Timeout

See detailed reports in MegaLinter artifacts

Your project could benefit from a custom flavor, which would allow you to run only the linters you need, and thus improve runtime performances. (Skip this info by defining FLAVOR_SUGGESTIONS: false)

  • Documentation: Custom Flavors
  • Command: npx mega-linter-runner@9.4.0 --custom-flavor-setup --custom-flavor-linters ACTION_ACTIONLINT,JSON_JSONLINT,JSON_V8R,JSON_PRETTIER,MARKDOWN_MARKDOWNLINT,MARKDOWN_MARKDOWN_TABLE_FORMATTER,REPOSITORY_CHECKOV,REPOSITORY_GIT_DIFF,REPOSITORY_SECRETLINT,REPOSITORY_TRUFFLEHOG,SPELL_LYCHEE,SPELL_CODESPELL,YAML_PRETTIER,YAML_YAMLLINT,YAML_V8R

MegaLinter is graciously provided by OX Security
Show us your support by starring ⭐ the repository

@ideaship ideaship marked this pull request as draft April 8, 2026 13:38
ideaship added a commit to osism/testbed that referenced this pull request Apr 8, 2026
The deployment guide now exclusively recommends application
credentials (osism/osism.github.io#972), where the secret is
already contained in clouds.yaml. The secure.yaml file was only
needed for username/password auth to separate the password from
clouds.yaml.

Remove the secure.yaml existence check from setup-testbed.py
and delete terraform/secure.yaml.sample. The check was already
non-fatal (warning + sleep, no exit) — a compromise from PR
#1879 where it was noted that secure.yaml is optional for app
credentials. A TODO to add smarter detection was left but never
followed up on.

For production deployments, a more fine-grained check that
validates credentials based on auth type (app credentials vs.
username/password) would still be valuable.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
ideaship added a commit to osism/testbed that referenced this pull request Apr 8, 2026
Users following the deployment guide see the warning "There is
no file terraform/secure.yaml, create one by using
terraform/secure.yaml.sample as template" in their log output.
This is confusing because the guide recommends application
credentials, where the secret is already in clouds.yaml and no
secure.yaml is needed.

Remove the secure.yaml existence check from setup-testbed.py
and delete terraform/secure.yaml.sample. The check was already
non-fatal (warning + sleep, no exit) — a compromise from PR
#1879 where it was noted that secure.yaml is optional for app
credentials. A TODO to add smarter detection was left but never
followed up on.

The deployment guide now exclusively recommends application
credentials (osism/osism.github.io#972). For production
deployments, a more fine-grained check that validates
credentials based on auth type would still be valuable.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
ideaship added a commit to osism/testbed that referenced this pull request Apr 8, 2026
Users following the deployment guide see the warning "There is
no file terraform/secure.yaml, create one by using
terraform/secure.yaml.sample as template" in their log output.
This is confusing because the guide recommends application
credentials, where the secret is already in clouds.yaml and no
secure.yaml is needed.

Remove the secure.yaml existence check from setup-testbed.py
and delete terraform/secure.yaml.sample. The check was already
non-fatal (warning + sleep, no exit) — a compromise from PR
#1879 where it was noted that secure.yaml is optional for app
credentials. A TODO to add smarter detection was left but never
followed up on.

The deployment guide now exclusively recommends application
credentials (osism/osism.github.io#972). For production
deployments, a more fine-grained check that validates
credentials based on auth type would still be valuable.

AI-assisted: Claude Code
Signed-off-by: Roger Luethi <luethi@osism.tech>
Rewrite step 3 ("Configure your cloud access profile") of the
testbed deployment guide to provide a single fast path using
application credentials downloaded from Horizon.

The old version had several problems (see issue #960):
clouds-public.yaml was mentioned without context, there was no
guidance on application credential settings, no fast path for
cloud access configuration, and it was unclear what credentials
a provider actually supplies. The section tried to cover
different cases (app credentials vs username/password,
secure.yaml, profiles, cloud naming constraints) without
offering a simple straight path.

Investigation showed that the downloaded clouds.yaml from
Horizon already contains auth_url, region_name, and
identity_api_version — all the information that
clouds-public.yaml provides via the profile parameter. The
only extra field in clouds-public.yaml is image_format (for
4 providers), but Terraform does not use it. Default app
credential settings (empty roles, Unrestricted=false) are
sufficient, confirmed by a successful deployment.

The rewrite removes the username/password alternative (no
clouds.yaml download available from Horizon, requiring manual
YAML construction), the clouds-public.yaml/profile explanation,
and the secure.yaml option. What remains is a linear set of
concrete steps: create app credential in Horizon, download
clouds.yaml, rename the cloud entry, and copy the file.

Closes: #960

AI-assisted: Claude Code
Signed-off-by: Roger Luethi <luethi@osism.tech>
@ideaship ideaship force-pushed the rl_configure_cloud_access_profile branch from a82e59f to 6ee5aad Compare April 8, 2026 17:23
ideaship added a commit to osism/testbed that referenced this pull request Apr 9, 2026
Users following the deployment guide see the warning "There is
no file terraform/secure.yaml, create one by using
terraform/secure.yaml.sample as template" in their log output.
This is confusing because the guide recommends application
credentials, where the secret is already in clouds.yaml and no
secure.yaml is needed.

Remove the secure.yaml existence check from setup-testbed.py
and delete terraform/secure.yaml.sample. The check was already
non-fatal (warning + sleep, no exit) — a compromise from PR
#1879 where it was noted that secure.yaml is optional for app
credentials. A TODO to add smarter detection was left but never
followed up on.

The deployment guide now exclusively recommends application
credentials (osism/osism.github.io#972). For production
deployments, a more fine-grained check that validates
credentials based on auth type would still be valuable.

AI-assisted: Claude Code
Signed-off-by: Roger Luethi <luethi@osism.tech>
@ideaship ideaship marked this pull request as ready for review April 10, 2026 11:13
ideaship added a commit to osism/testbed that referenced this pull request Apr 10, 2026
Users following the deployment guide see the warning "There is
no file terraform/secure.yaml, create one by using
terraform/secure.yaml.sample as template" in their log output.
This is confusing because the guide recommends application
credentials, where the secret is already in clouds.yaml and no
secure.yaml is needed.

Remove the secure.yaml existence check from setup-testbed.py
and delete terraform/secure.yaml.sample. The check was already
non-fatal (warning + sleep, no exit) — a compromise from PR
#1879 where it was noted that secure.yaml is optional for app
credentials. A TODO to add smarter detection was left but never
followed up on.

The deployment guide now exclusively recommends application
credentials (osism/osism.github.io#972). For production
deployments, a more fine-grained check that validates
credentials based on auth type would still be valuable.

AI-assisted: Claude Code
Signed-off-by: Roger Luethi <luethi@osism.tech>
@ideaship ideaship marked this pull request as draft April 13, 2026 10:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Simplify testbed/deployment.mdx "Configure your cloud access profile"

1 participant