Docs: mention ACM in Certificate Discovery

[sdarwin]

Hi,

This is both an Issue and an attempted Pull Request to solve the issue.

On the page "Certificate Discovery" https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress/cert_discovery/ , I was reading and wondered about where the discovered TLS certificates come from. Consider that the main kubernetes documentation about Ingress https://kubernetes.io/docs/concepts/services-networking/ingress/ includes a nearly identical spec:

spec:
  tls:
  - hosts:
      - https-example.foo.com

Where do those TLS certs on the official page come from?
They are k8s Secrets, which are resources in the cluster, similar to ConfigMaps.
If this controller is doing something similar to the official Ingress spec, but "discovering" tls, perhaps that also means from k8s secrets.
"ACM" "AWS Certificate Manager" is referred to 0 times on the "Certificate Discovery" page.
All of this might lead one to think about "secrets" and not "ACM". Which is it? And so, the text update in this pull request.
Let me know, if it should to be edited/modified.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: sdarwin
Once this PR has been reviewed and has the lgtm label, please assign zac-nixon for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

Hi @sdarwin. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[sdarwin]

There is another topic that could be mentioned on this page also.

1. Often, certificates are associated with multiple domains.
2. One ingress might have multiple different entries. with multiple domains.

text -

1. "If an ACM certificate has many domains and/or wildcards, it's sufficient for the discovery process to find one of those domains, and that will count as a match."
2. show an example?

[zac-nixon]

I agree with your two points, that would be helpful to mention! We can work on updating those examples, or would you prefer to work off this PR?

[sdarwin]

Hi @zac-nixon ,

If you will work on it, that's great.
For me, it doesn't matter if that's through this PR, or creating another one. This PR has "Allow edits by maintainers". But a new one is fine also.
"I agree with your two points". Yes. There is an issue I often find in documentation: let's say an --options-flag or a config setting can take multiple entries. The docs might say that "You can add multiple domains". The reader is left wondering "Would those be comma-separated, or completely separate flags, or in a formatted json array, or..." Any time something can be multiplied it's worthwhile to actually show examples. I was trying to think of such cases here. "What if a cert has multiple domains". "What if an ingress takes multiple certs". etc.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle stale
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[sdarwin]

/remove-lifecycle stale

All the discussions in this thread are extra/optional. The pull request could be merged as-is. It's a small change. Simply merge.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle stale
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[sdarwin]

/remove-lifecycle stale

The existing pull request is a small text modification, and could be merged as-is.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle stale
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle rotten
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Reopen this PR with /reopen
• Mark this PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closed this PR.

Details

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Reopen this PR with /reopen
• Mark this PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.