You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The refresh command above uses the canonical-livepatch-server-k8s application, but the schema-upgrade action here and restart action below use livepatch. Unless the application was explicitly deployed under that name, those actions will target a different application or fail, leaving the refreshed server without its migration. Use the deployed Juju application name consistently in the refresh and both action commands (as the K8s charm example in docs/server/explanation/architecture/security-lifecycle.md:24-32 does).
The prerequisites mention an Ubuntu Pro token, but these commands never pass it to livepatch-admin or explain how the tool discovers it; they also do not select or authenticate to the hosted endpoint before patch list and patch download. The existing administration-tool setup only shows login to an on-premises server, and the older downloader explicitly enables its token. Add the supported hosted-server endpoint and authentication setup before the first list command (or explain how an attached Pro token is picked up automatically) so readers can complete this step.
OCI's access tier selects a storage class, not bucket visibility. The deployment expects clients to read patch objects publicly, so this step does not configure that access. Set the bucket's public access type to ObjectReadWithoutList for direct delivery, without granting public writes.
The only policy example applies to an instance dynamic group. A server using the configuration-file authentication described above belongs to a user group and will not receive these object permissions. Show the allow group variant as an alternative for that deployment.
The policy shown above grants object access but does not grant the bucket-level PAR_CREATE permission needed to create pre-authenticated requests. An administrator who applies only that policy can upload objects as the server identity but cannot issue uploader credentials. Document the additional, bucket-scoped PAR_CREATE permission for whichever identity (dynamic group or user group) the server uses.
The impersonation method described above requires the source identity to have iam.serviceAccounts.getAccessToken on the target service account, typically through roles/iam.serviceAccountTokenCreator. Bucket access and the stated STS exchange permission do not grant this; without it, deployments using patch-storage.gcs-impersonate-service-account fail to obtain credentials. Add this required grant for the impersonation path.
Policy omits access for config-file user authentication
This policy grants access only to an instance principal in a dynamic group. The same section also recommends a config-file user identity, which needs an allow group ... policy instead; users following the example with that method will not gain object access. Show the two alternative policy statements and tell readers to use the one matching their authentication method.
The 12-hour maximum cited here is only possible when the source credentials are not from an assumed role. With common EC2 instance-role or EKS IRSA credentials, AWS treats the subsequent AssumeRole call as role chaining and limits it to one hour even if the target role's MaxSessionDuration is higher. Add this caveat here and in the S3 setup guide (use-s3-for-patch-storage.md:28), or operators may configure a session duration STS rejects.
This restart target has the same application-name mismatch as the schema migration command: the guide refreshed canonical-livepatch-server-k8s, but livepatch/<desired-unit> is not a unit of that application. The documented command will not address the K8s deployment unless the target is changed or deployment-specific syntax is provided.
Correct Swift credential terminology and document GCS credentials
This lists Swift uploads as using “Pre-Authenticated Requests,” but Swift uses TempURL signatures; Pre-Authenticated Requests are an OCI mechanism, and GCS uses downscoped OAuth tokens. The current list both misidentifies Swift and omits GCS, so readers may select the wrong storage credential model.
This now instructs operators to make the OCI bucket private, but the intended patch-delivery model requires objects to be publicly readable while preventing public writes. Distinguish public read access from write access and document the correct OCI bucket visibility setting instead of calling the access tier private.
Swift uploads in this guide use TempURL credentials, not OCI-style Pre-Authenticated Requests. As written, the storage-backend summary names a mechanism that is not used by any of the listed supported backends and omits the actual Swift mechanism; describe Swift TempURLs (and GCS downscoped tokens) explicitly.
This change switches the cloud-init example from PostgreSQL to Azure Blob Storage, but the guide still states at line 31 that the example uses PostgreSQL for patch storage. Update that description (or keep the configuration consistent) so operators do not follow contradictory storage instructions.
This change configures the deployment to use Azure Blob Storage, but the guide still states above that the deployment uses PostgreSQL for patch storage. That contradiction leaves operators unsure which backend the cloud-init actually configures; update the surrounding description to match the new Azure configuration.
Policy example omits authorization for OCI config users
This policy example only authorizes a dynamic group, but the documented second authentication mechanism is an OCI config file containing user credentials. Users of that mode belong to a user group and will receive authorization failures if they copy this statement; provide the corresponding allow group <group-name> ... form as well.
This says schema migrations run automatically during startup for the Charmed deployment, but the architecture guide documents schema-upgrade as the action to run when migrations are required (docs/server/explanation/architecture/security-lifecycle.md:29-35). Please make the upgrade procedure consistent so operators do not assume a migration has run when the application still requires the action.
Config-file authentication policy incorrectly uses a dynamic group
The paragraph says config-file authentication uses a user group, but this policy is hard-coded to allow dynamic-group. Applying it for the documented config-file path will fail or grant nothing; provide the corresponding allow group <group-name> form (or separate examples) for user credentials.
Updated permissions and authentication instructions for patch storage and Livepatch Server.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Signed-off-by: kunalmohan-work <kunal.mohan@canonical.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
CHANGELOG.mdwith relevant non-documentation file changes?