[Documentation] gemini-enterprise: access_end_hour is inclusive, so a window documented as 9 AM - 5 PM stays open through 5:59 PM

未关闭 适合新手
  • 哪里不对？
#401 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
2/5
预计耗时
1-3 小时
新手友好度
78/100
Issue 类型
文档
描述清晰度
描述清楚
活跃度
活跃
技术栈
terraform
领域
cloud, documentation

调研方向

阅读 gemini-stage-0/access_policy.tf 中的访问条件，并将其包含结束小时的检查与 gemini-stage-0/variables.tf、gemini-stage-0/terraform.tfvars.sample、deploy.sh 以及指定 README 中的描述进行比较。更新文档中的结束小时、默认值和时区，使其与实际行为及建议措辞一致。完成标准是：示例、提示、README 文本和模块示例都一致地描述符合该条件的时间窗口。

由索引模型根据 Issue 内容生成。

描述

Documentation Gemini - Enterprise Level of Effort - Low Priority - Low Scope - Blueprint Scope - Module

Description of Documentation Need

The gemini-enterprise blueprint's time-based access level compares whole hours, and both ends are inclusive. gemini-stage-0/access_policy.tf:51 generates:

request.time.getHours("<zone>") >= <access_start_hour> && request.time.getHours("<zone>") <= <access_end_hour>

getHours() returns only the hour, so minutes are ignored: access_end_hour = 17 stays true through 17:59:59 and closes access at 18:00. To close at 5:00 PM, the value is 16.

Every place that describes the variable reads as though 17 closes access at 5:00 PM. An operator told to close at 5 PM enters 17, and the access level stays open an hour longer than was approved, with nothing in the plan or the output to show it. A student in one of our classes asked which it was, and our own answer key had made the same mistake.

At main @ 2267b973, under blueprints/gemini-enterprise/:

Location Says Actually
gemini-stage-0/terraform.tfvars.sample:96 access_end_hour = 17 # e.g., 5 PM ET through 5:59 PM
README.md:879, :884 Access only during business hours (Mon-Fri, 9 AM - 5 PM ET). through 5:59 PM with the sample's 17; through 9:59 PM with the default 21
README.md:894 Time of Day (7AM-9PM M-F) through 9:59 PM
gemini-stage-0/variables.tf:104 The hour (0-23) in the configured access_time_zone (default America/New_York) when access ends. does not say the hour itself is included
deploy.sh:1241 Enter End Hour in ${ACCESS_TIME_ZONE} (0-23) [21]: does not say the hour itself is included

Two details in the same README section are also out of date:

  • README.md:903-904 give the defaults as 9 and 17. variables.tf (lines 100 and 106) and deploy.sh (lines 1239 and 1241) default to 7 and 21.
  • The same lines say 0-23 ET, but the hours are evaluated in access_time_zone, which is configurable.

A related example: modules/organization/README.md:470-471, modules/organization-se/README.md:470-471, and modules/project/README.md:893-894 show the condition getHours("Europe/Berlin") <= 9 && getHours("Europe/Berlin") >= 17. No hour satisfies both, so that binding would never apply.

The same wording appears in Google's public documentation, which may be where it came from. A change in this repository cannot fix these pages, so they are listed for whoever owns them:

Neither page says that an hour check includes the minutes of the end hour.

Target Audience

Operators who turn a customer's approved hours into access_start_hour and access_end_hour, through the sample or the deploy.sh prompts, and the assessors who compare the deployed window with what was approved.

Proposed Location

The files in the table above, and the three module READMEs.

Content Outline / Draft

Keeping the <= is the smallest change, and it leaves every deployed window as it is. Suggested text:

  1. variables.tf:104: The last hour (0-23) in the configured access_time_zone (default America/New_York) during which access is allowed. Inclusive: minutes are ignored, so 17 allows access through 17:59 and closes it at 18:00.
  2. terraform.tfvars.sample:96: access_end_hour = 16 # last open hour: access closes at 5 PM ET
  3. README.md:879, :884, :894: state the window the defaults produce, 7 AM through 9:59 PM, or name the variables instead of a clock time.
  4. README.md:903-904:
    • access_start_hour: First hour access is allowed (0-23 in access_time_zone, default: 7)
    • access_end_hour: Last hour access is allowed, inclusive (0-23 in access_time_zone, default: 21, which closes access at 22:00)
  5. deploy.sh:1241: Enter End Hour in ${ACCESS_TIME_ZONE}, the last hour access stays open (0-23) [21]:
  6. The three module READMEs: getHours("Europe/Berlin") >= 9 && getHours("Europe/Berlin") < 17, which is a true 9 AM to 5 PM.

If maintainers would rather make the end hour a closing time, changing the operator to < does that, but it shortens every existing window by an hour on the next apply, and a window that runs to midnight would then need an end hour of 24.

Compliance Context (if applicable)

A time-based access level is a control that an operator documents and an assessor can test. If the approved window ends at 5 PM and the deployed level admits requests until 5:59 PM, access stays open for an hour nobody approved, on every day the window applies.

主要语言
HCL
星标
61
派生
28
平均合并
1 天 17 小时
30 天内合并 PR
74

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

google/stellar-engine 的其他 Issue

查看 google/stellar-engine 的全部 Issue

相似的 Issue

更多 Cloud Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。