Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optional Blobstore agent creds #2327

Merged
merged 8 commits into from
Oct 28, 2021
Merged

Conversation

bgandon
Copy link
Contributor

@bgandon bgandon commented Sep 30, 2021

What is this change about?

Here we have the agent credentials for local Blobstore become optional, because implementing signed URLs means they are not required anymore.

Please provide contextual information.

When operators opt for signed URLs, they should not be forced to specify any username and password for the agent to access the blobstore.

Maybe worth to note, Pivotal/VMware has had a similar related story, left unfinished though: https://www.pivotaltracker.com/n/projects/956238/stories/169966865

Related PRs

What tests have you run against this PR?

Unit tests for the BOSH Release templates are passing, as executed with (cd src && bundle exec rspec ../spec).

How should this change be described in bosh release notes?

  • When using signed URLs, the credentials for the agent to access the local Blobstore are not required anymore.

Does this PR introduce a breaking change?

No breaking change is introduced here, but missing agent credentials with a blobstore.enable_signed_urls of false is a new potential pitfall.

Tag your pair, your PM, and/or team!

Co-Authored-By: @OliverMautschke

Comment on lines 6 to 12
if_p('blobstore.agent.user') do
all_users[p('blobstore.agent.user')] = p('blobstore.agent.password')
end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought that we want to make these properties depend on blobstore.enable_signed_urls?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If blobstore.agent.user is not set and blobstore.enable_signed_urls is false it should raise an error. In order to shorten the operator feedback loop in the case of a misconfiguration.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we shouldn't configure the blobstore.agent.user if blobstore.enable_signed_urls is set to true.
The agent doesn't need this credential anymore in this case. And from a security perspective, it's better to not configure it so that you don't need to rotate it.

We currently have the issue that some CPIs still reference the blobstore.agent.user, blobstore.agent.password even though they don't use it if blobstore.enable_signed_urls is set to true.

Till these CPIs have been updated, we could set blobstore.agent.user, blobstore.agent.password in the manifest and still wouldn't need to rotate the password, since it is not configured in the blobstore.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@beyhan, we need both types of access because during the time window when switching from agent user/password to signed URLs, there is a need for the blobstore to accept both, until all agents have received their new configuration.

Yes @rkoster this misconfiguration must be caught indeed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is a need for the blobstore to accept both, until all agents have received their new configuration.

Is this really the case?
I thought the agent only downloads blobs from the blobstore, when the director sends a request and doesn't store or reuse previous blobstore URLs.

I assume that after the blobstore.enable_signed_urls config is set to true on the director side, the agents only use signed blobstore URLs.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When mixing old and new stemcells it could in theory be that both signed URLs and non agent blobstore credentials are used at the same time: https://github.com/cloudfoundry/bosh/blob/master/src/bosh-director/lib/bosh/blobstore_client/base.rb#L122-L125

Apparently the ubuntu-xenial/456.x line (which is still supported for VMware customers) does not support singed URLs (API version 2).
Stemcell builder was bumped to API version 3 in this commit: cloudfoundry/bosh-linux-stemcell-builder@f4de1ec

@bgandon bgandon force-pushed the optional-blobstore-agent-creds branch from 911daaa to 2edea39 Compare October 8, 2021 10:15
@bgandon
Copy link
Contributor Author

bgandon commented Oct 8, 2021

I've just pushed these improvements:

  • Implement error raising in case of misconfiguration, with proper unit test scenario
  • Refactor ERB test to use the latest recommended usage of the bosh-template Gem
  • Add documentation to explain how to run ERB unit tests

@@ -34,9 +34,9 @@ properties:
description: Password director must use to access blobstore via HTTP Basic

blobstore.agent.user:
description: Username agents must use to access blobstore via HTTP Basic
description: Username agents must use to access blobstore via HTTP Basic (optional, if provided the password is mandatory)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we say hier something like "optional if blobstore.enable_signed_urls is used, ..."

Copy link
Contributor Author

@bgandon bgandon Oct 8, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, sure. I suddenly realise how ambiguous is the “if provided the password is mandatory” sentence… and it's unnecessary to tell there anyway. So, I've changed that.

@beyhan
Copy link
Member

beyhan commented Oct 8, 2021

@bgandon having something about the ERB test is really good. We could even add a script for this into https://github.com/cloudfoundry/bosh/tree/master/scripts to make it more easier reference that in the docs.

@bgandon
Copy link
Contributor Author

bgandon commented Oct 8, 2021

Good idea. I've added a dedicated script for running the ERB unit tests.

@bgandon bgandon requested a review from beyhan October 8, 2021 16:38
scripts/test-brats Show resolved Hide resolved
docs/running_tests.md Outdated Show resolved Hide resolved

Install the Gem dependencies.
```
(cd src && bundle install)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why these commands are in parenthesis?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In order for them to run in a sub-shell, so that on return the current shell remains in the same current working directory.

Copy link
Member

@beyhan beyhan Oct 19, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about using bundle install --gemfile=./src/Gemfile, which is more intuitive and it is closer to what we want to achieve here? I didn't know the effect of the parenthesis and I just executed the command without them. My confusion comes from there :-)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, why not.

@bgandon
Copy link
Contributor Author

bgandon commented Oct 20, 2021

I've pushed some changes to take your remarks into account @beyhan
This work is ready for final review.

Copy link
Member

@beyhan beyhan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks good to me. @rkoster any objection from your side to merge this?

Thank you @bgandon

@rkoster
Copy link
Contributor

rkoster commented Oct 28, 2021

LGTM, Thanks @bgandon

@rkoster rkoster merged commit 49d0466 into master Oct 28, 2021
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.

None yet

5 participants