docs(core-concepts): write the authentication and logging pages

[whg517]

Summary

Second batch of stage 2. Two pages, both language trees, four files — both were one-line placeholders.

Independent of #38: that PR touches s3.md and the two operations/ pages, this one touches security/authentication.md and observability/logging.md. Both branch off main, no overlap, either order is fine.

As before, everything is taken from the operator source in the sibling repositories rather than written from memory.

core-concepts/security/authentication.md

From operator-go's pkg/apis/authentication/v1alpha1 (the CRD, every provider's fields and defaults) and from trino-operator (the product-side shape, and which providers are actually implemented).

Covers AuthenticationClass being cluster-scoped, the five providers, and per-provider detail: the static Secret indirection, LDAP bind credentials (user/password keys) with the ldapFieldNames defaults and a note that Active Directory needs them overridden, OIDC with its required principalClaim and providerHint, and the client credentials (CLIENT_ID/CLIENT_SECRET) that belong to the product rather than the class.

Two things the schema does not tell you, both documented:

• Nothing enforces one provider per class. All five fields are optional and there is no XValidation, so a class setting both oidc and ldap is accepted. Products take the first match in a fixed order and ignore the rest — Trino's order is oidc, static, ldap.
• Product support is a subset of the API. Trino implements oidc, static and ldap. A class whose provider is tls or kerberos yields no authenticator at all, and nothing rejects it at apply time.

Also worth flagging for review: providerHint is a required enum accepting only keycloak, so Keycloak is currently the only OIDC issuer that can be configured.

core-concepts/observability/logging.md

From commons/v1alpha1's logging_types.go and config_types.go, the log path constants in pkg/constant, and pkg/vector for the aggregator discovery contract.

Covers where containers write (/kubedoop/log/<container>/), the containers/loggers/console/file structure under config.logging, the level enum, and the Vector agent.

Explains why level has no CRD default: unset means inherit, so a role group writing an empty console: {} does not silently override a DEBUG set at the role level. A default would be filled in by the API server as soon as the enclosing object existed, and the role's value could never win. Also documents the level mapping for non-Java products, where TRACE and DEBUG collapse together.

For Vector, documents the indirection — vectorAggregatorConfigMapName names a ConfigMap carrying an ADDRESS key, so the aggregator can move without editing every product cluster — and quotes the errors raised when the agent is enabled with no aggregator configured, or with one that cannot be resolved.

Testing

• npm run verify exits 0 — 52 files linted with 0 errors, both locales built
• All four pages render in both locales (spot-checked providerHint and enableVectorAgent in the build output)
• Relative links resolve — onBrokenLinks: 'throw' would have failed the build otherwise
• en/zh trees still mirror 1:1

Remaining stage 2 placeholders

8 left: service-discovery, kubernetes, kubebuilder, develop-guideline, faq, release-notes, spark-k8s-operator, and database (blocked — see #38 for why).

faq and release-notes cannot be derived from source at all: one needs real user questions, the other needs release history. Those likely need input from maintainers rather than research.

🤖 Generated with Claude Code