[junon]

If you place any sort of security assumptions on AWS account IDs into your threat model, you're effectively directly introducing a security vulnerability. If you're not then why include it into your security threat model to begin with? I believe that is their point.

Since AWS does not, and has never, treated that information as secret, then there is absolutely no reason to consider it sensitive because there is no security guarantees with how AWS handles those IDs (as this article demonstrates).

Thus, either you're including them into your threat model as sensitive and thus immediately opening up yourself to vulnerabilities (bad security), or you're not including them at all (and thus not treating them as sensitive/secret/whatever). The argument the parent had (and that I agree with) is that you should do the latter unless AWS provides a means to work with those IDs securely (it won't because they're not secrets).

[kube-system]

This is a false dichotomy. There is a deep chasm between "publish everything", and "this is a secret", called operational security.

Any time a topic like this comes up, there are people on this forum that try to apply the "security by obscurity does not work" principle to every security topic under the sun, when in reality, that principle really only applies to the world of cryptography. In meat space, where humans operate on plaintext, keeping a secret is a very valid approach to some topics. This is why things like NDAs exist.

[evandale]

How is it possible for a user of AWS to keep the account ID secret if Amazon doesn't even consider it secret? If Amazon leaked your account ID they could point to their docs and say the account ID was never meant to be a secret, sensitive, or confidential.

[kube-system]

You can walk over to the user's desk and ask them not to share it. Whether or not Amazon leaks it is unrelated to my employees' ability to follow instructions.

There is a lot of data that exists in a space somewhere between "100% secret" and "100% public". This is one of those situations, for many organizations.

[abadpoli]

You’re wasting your employees time by asking them to keep it secret, when you gain absolutely no benefit from keeping it secret (and in fact are introducing an easy failure point by pretending it’s secret) and you have no guarantees that others are keeping it secret.

> This is one of those situations, for many organizations.

And those organizations are wrong.

[kube-system]

Many organizations just have a blanket policy that you shouldn't be exposing data about an organization's infrastructure unless you need to do it. This is a good policy.

> by pretending it’s secret

No, nobody needs to pretend it is secret. You're missing my above point. There is not a dichotomy between secret and public. It is possible for something to be neither secret nor public.

[junon]

And what OpSec benefit is there?

[kube-system]

Well, as a very relevant example, if you tell others what your AWS account ID is, they can figure out if you own any particular bucket. The metadata association between the content of that bucket and the owner might give away information that the contents of the bucket doesn't indicate on its own. It also might not be a technical vulnerability, but that association itself could imply some proprietary business information. Or it could give clues to any would-be attacker as to other resources to target. In business, there are lots of types of information that are not secret, but are also not public.