1_DevOps'ish

Zero-day vulnerability alert! Apple has released security updates to prevent malicious code execution on your devices.

Developer platforms won't eliminate DevOps but will prioritize developer experience.

Beijing defends "legitimate rights" in response to Washington’s semiconductor controls.

If you’re categorizing your incidents by cause, here are some options for causes that I’d love to see used. These are all taken directly from the field of cognitive systems engineering …

iOS 16.2 is bringing some excellent iCloud privacy features, but there are still some security holes to be filled.

Making sense of the SMART indicators for NVMe SSDs, including all recent models fitted by Apple to Macs.

Follow us on Twitter @HackRead - Facebook @ /HackRead

China is working on a more than 1 trillion yuan ($143 billion) support package for its semiconductor industry, three sources said, in a major step towards self sufficiency in chips and to counter U.S. moves aimed at slowing its technological advances.

Ms. Khan, the chair of the Federal Trade Commission, has staked an ambitious trustbusting agenda on a case that may be difficult to win.

Yout.com calls for a pause on the RIAA's request for attorney's fees until the legality of youtube-dl-based software has been heard at appeal.

Google's initial plan to start Manifest V3 experiments in several versions the Chrome web browser have been postponed again by the company.

This session dives deeps into recent enhancements to Amazon EKS, a fully managed Kubernetes service. Learn how these new capabilities make it easy for you to run Kubernetes on AWS and on premises and help ensure the availability and scalability of your mission-critical applications. Learn more about AWS re:Invent at https://go.aws/3ikK4dD. Subscribe: More AWS videos http://bit.ly/2O3zS75 More AWS events videos http://bit.ly/316g9t4 ABOUT AWS Amazon Web Services (AWS) hosts events, both online and in-person, bringing the cloud computing community together to connect, collaborate, and learn from AWS experts. AWS is the world’s most comprehensive and broadly adopted cloud platform, offering over 200 fully featured services from data centers globally. Millions of customers—including the fastest-growing startups, largest enterprises, and leading government agencies—are using AWS to lower costs, become more agile, and innovate faster. #reInvent2022 #AWSreInvent2022 #AWSEvents

On Thursday, the U.S. Patent and Trademark Office published a patent application from Apple that relates to a wearable self-mixing interferometry (SMI) ring that could be used to sense physiological conditions of a user, such as a heart rate, blood oxygen saturation, blood pressure and more.

Authors : Brandon Smith (Microsoft) and Mark Rossetti (Microsoft) The long-awaited day has arrived: HostProcess containers, the Windows equivalent to Linux privileged containers, has finally made it to GA in Kubernetes 1.26 ! What are HostProcess containers and why are they useful? Cluster operators are often faced with the need to configure their nodes upon provisioning such as installing Windows services, configuring registry keys, managing TLS certificates, making network configuration changes, or even deploying monitoring tools such as a Prometheus's node-exporter. Previously, performing these actions on Windows nodes was usually done by running PowerShell scripts over SSH or WinRM sessions and/or working with your cloud provider's virtual machine management tooling. HostProcess containers now enable you to do all of this and more with minimal effort using Kubernetes native APIs. With HostProcess containers you can now package any payload into the container image, map volumes into containers at runtime, and manage them like any other Kubernetes workload. You get all the benefits of containerized packaging and deployment methods combined with a reduction in both administrative and development cost. Gone are the days where cluster operators would need to manually log onto Windows nodes to perform administrative duties. HostProcess containers differ quite significantly from regular Windows Server containers. They are run directly as processes on the host with the access policies of a user you specify. HostProcess containers run as either the built-in Windows system accounts or ephemeral users within a user group defined by you. HostProcess containers also share the host's network namespace and access/configure storage mounts visible to the host. On the other hand, Windows Server containers are highly isolated and exist in a separate execution namespace. Direct access to the host from a Windows Server container is explicitly disallowed by default. How does it work? Windows HostProcess containers are implemented with Windows Job Objects , a break from the previous container model which use server silos. Job Objects are components of the Windows OS which offer the ability to manage a group of processes as a group (also known as a job ) and assign resource constraints to the group as a whole. Job objects are specific to the Windows OS and are not associated with the Kubernetes Job API . They have no process or file system isolation, enabling the privileged payload to view and edit the host file system with the desired permissions, among other host resources. The init process, and any processes it launches (including processes explicitly launched by the user) are all assigned to the job object of that container. When the init process exits or is signaled to exit, all the processes in the job will be signaled to exit, the job handle will be closed and the storage will be unmounted. HostProcess and Linux privileged containers enable similar scenarios but differ greatly in their implementation (hence the naming difference). HostProcess containers have their own PodSecurityContext fields. Those used to configure Linux privileged containers do not apply. Enabling privileged access to a Windows host is a fundamentally different process than with Linux so the configuration and capabilities of each differ significantly. Below is a diagram detailing the overall architecture of Windows HostProcess containers: Two major features were added prior to moving to stable: the ability to run as local user accounts, and a simplified method of accessing volume mounts. To learn more, read Create a Windows HostProcess Pod . HostProcess containers in action Kubernetes SIG Windows has been busy putting HostProcess containers to use - even before GA! They've been very excited to use HostProcess containers for a number of important activities that were a pain to perform in the past. Here are just a few of the many use use cases with example deployments: CNI solutions and kube-proxy windows-exporter csi-proxy Windows-debug container ETW event streaming How do I use it? A HostProcess container can be built using any base image of your choosing, however, for convenience we have created a HostProcess container base image . This image is only a few KB in size and does not inherit any of the same compatibility requirements as regular Windows server containers which allows it to run on any Windows server version. To use that Microsoft image, put this in your Dockerfile : FROM mcr.microsoft.com/oss/kubernetes/windows-host-process-containers-base-image:v1.0.0 You can run HostProcess containers from within a HostProcess Pod . To get started with running Windows containers, see the general guidance for deploying Windows nodes . If you have a compatible node (for example: Windows as the operating system with containerd v1.7 or later as the container runtime), you can deploy a Pod with one or more HostProcess containers. See the Create a Windows HostProcess Pod - Prerequisites for more information. Please note that within a Pod, you can't mix HostProcess containers with normal Windows containers. How can I learn more? Work through Create a Windows HostProcess Pod Read about Kubernetes Pod Security Standards and Pod Security Admission Read the enhancement proposal Windows Privileged Containers and Host Networking Mode (KEP-1981) Watch the Windows HostProcess for Configuration and Beyond KubeCon NA 2022 talk How do I get involved? Get involved with SIG Windows to contribute!

Splits between U.S. Department of Justice prosecutors are delaying the conclusion of a long-running criminal investigation into the world's largest cryptocurrency exchange Binance, four people familiar with the matter have told Reuters.

Author: Sascha Grunert The Kubernetes Special Interest Group (SIG) Release is proud to announce that we are digitally signing all release artifacts, and that this aspect of Kubernetes has now reached beta . Signing artifacts provides end users a chance to verify the integrity of the downloaded resource. It allows to mitigate man-in-the-middle attacks directly on the client side and therefore ensures the trustfulness of the remote serving the artifacts. The overall goal of out past work was to define the used tooling for signing all Kubernetes related artifacts as well as providing a standard signing process for related projects (for example for those in kubernetes-sigs ). We already signed all officially released container images (from Kubernetes v1.24 onwards). Image signing was alpha for v1.24 and v1.25. For v1.26, we've added all binary artifacts to the signing process as well! This means that now all client, server and source tarballs , binary artifacts , Software Bills of Material (SBOMs) as well as the build provenance will be signed using cosign . Technically speaking, we now ship additional *.sig (signature) and *.cert (certificate) files side by side to the artifacts for verifying their integrity. To verify an artifact, for example kubectl , you can download the signature and certificate alongside with the binary. I use the release candidate rc.1 of v1.26 for demonstration purposes because the final has not been released yet: curl -sSfL https://dl.k8s.io/release/v1.26.0-rc.1/bin/linux/amd64/kubectl -o kubectl curl -sSfL https://dl.k8s.io/release/v1.26.0-rc.1/bin/linux/amd64/kubectl.sig -o kubectl.sig curl -sSfL https://dl.k8s.io/release/v1.26.0-rc.1/bin/linux/amd64/kubectl.cert -o kubectl.cert Then you can verify kubectl using cosign : COSIGN_EXPERIMENTAL = 1 cosign verify-blob kubectl --signature kubectl.sig --certificate kubectl.cert tlog entry verified with uuid: 5d54b39222e3fa9a21bcb0badd8aac939b4b0d1d9085b37f1f10b18a8cd24657 index: 8173886 Verified OK The UUID can be used to query the rekor transparency log: rekor-cli get --uuid 5d54b39222e3fa9a21bcb0badd8aac939b4b0d1d9085b37f1f10b18a8cd24657 LogID: c0d23d6ad406973f9559f3ba2d1ca01f84147d8ffc5b8445c224f98b9591801d Index: 8173886 IntegratedTime: 2022-11-30T18:59:07Z UUID: 24296fb24b8ad77a5d54b39222e3fa9a21bcb0badd8aac939b4b0d1d9085b37f1f10b18a8cd24657 Body: { "HashedRekordObj": { "data": { "hash": { "algorithm": "sha256", "value": "982dfe7eb5c27120de6262d30fa3e8029bc1da9e632ce70570e9c921d2851fc2" } }, "signature": { "content": "MEQCIH0e1/0svxMoLzjeyhAaLFSHy5ZaYy0/2iQl2t3E0Pj4AiBsWmwjfLzrVyp9/v1sy70Q+FHE8miauOOVkAW2lTYVug==", "publicKey": { "content": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUN2akNDQWthZ0F3SUJBZ0lVRldab0pLSUlFWkp3LzdsRkFrSVE2SHBQdi93d0NnWUlLb1pJemowRUF3TXcKTnpFVk1CTUdBMVVFQ2hNTWMybG5jM1J2Y21VdVpHVjJNUjR3SEFZRFZRUURFeFZ6YVdkemRHOXlaUzFwYm5SbApjbTFsWkdsaGRHVXdIaGNOTWpJeE1UTXdNVGcxT1RBMldoY05Nakl4TVRNd01Ua3dPVEEyV2pBQU1Ga3dFd1lICktvWkl6ajBDQVFZSUtvWkl6ajBEQVFjRFFnQUVDT3h5OXBwTFZzcVFPdHJ6RFgveTRtTHZSeU1scW9sTzBrS0EKTlJDM3U3bjMreHorYkhvWVkvMUNNRHpJQjBhRTA3NkR4ZWVaSkhVaWFjUXU4a0dDNktPQ0FXVXdnZ0ZoTUE0RwpBMVVkRHdFQi93UUVBd0lIZ0RBVEJnTlZIU1VFRERBS0JnZ3JCZ0VGQlFjREF6QWRCZ05WSFE0RUZnUVV5SmwxCkNlLzIzNGJmREJZQ2NzbXkreG5qdnpjd0h3WURWUjBqQkJnd0ZvQVUzOVBwejFZa0VaYjVxTmpwS0ZXaXhpNFkKWkQ4d1FnWURWUjBSQVFIL0JEZ3dOb0UwYTNKbGJDMXpkR0ZuYVc1blFHczRjeTF5Wld4bGJtY3RjSEp2WkM1cApZVzB1WjNObGNuWnBZMlZoWTJOdmRXNTBMbU52YlRBcEJnb3JCZ0VFQVlPL01BRUJCQnRvZEhSd2N6b3ZMMkZqClkyOTFiblJ6TG1kdmIyZHNaUzVqYjIwd2dZb0dDaXNHQVFRQjFua0NCQUlFZkFSNkFIZ0FkZ0RkUFRCcXhzY1IKTW1NWkhoeVpaemNDb2twZXVONDhyZitIaW5LQUx5bnVqZ0FBQVlUSjZDdlJBQUFFQXdCSE1FVUNJRXI4T1NIUQp5a25jRFZpNEJySklXMFJHS0pqNkQyTXFGdkFMb0I5SmNycXlBaUVBNW4xZ283cmQ2U3ZVeXNxeldhMUdudGZKCllTQnVTZHF1akVySFlMQTUrZTR3Q2dZSUtvWkl6ajBFQXdNRFpnQXdZd0l2Tlhub3pyS0pWVWFESTFiNUlqa1oKUWJJbDhvcmlMQ1M4MFJhcUlBSlJhRHNCNTFUeU9iYTdWcGVYdThuTHNjVUNNREU4ZmpPZzBBc3ZzSXp2azNRUQo0c3RCTkQrdTRVV1UrcjhYY0VxS0YwNGJjTFQwWEcyOHZGQjRCT2x6R204K093PT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=" } } } } The HashedRekordObj.signature.content should match the content of the file kubectl.sig and HashedRekordObj.signature.publicKey.content should be identical with the contents of kubectl.cert . It is also possible to specify the remote certificate and signature locations without downloading them: COSIGN_EXPERIMENTAL = 1 cosign verify-blob kubectl \ --signature https://dl.k8s.io/release/v1.26.0-rc.1/bin/linux/amd64/kubectl.sig \ --certificate https://dl.k8s.io/release/v1.26.0-rc.1/bin/linux/amd64/kubectl.cert tlog entry verified with uuid: 5d54b39222e3fa9a21bcb0badd8aac939b4b0d1d9085b37f1f10b18a8cd24657 index: 8173886 Verified OK All of the mentioned steps as well as how to verify container images are outlined in the official documentation about how to Verify Signed Kubernetes Artifacts . In one of the next upcoming Kubernetes releases we will working making the global story more mature by ensuring that truly all Kubernetes artifacts are signed. Beside that, we are considering using Kubernetes owned infrastructure for the signing (root trust) and verification (transparency log) process. Getting involved If you're interested in contributing to SIG Release, then consider applying for the upcoming v1.27 shadowing program (watch for the announcement on k-dev ) or join our weekly meeting to say hi . We're looking forward to making even more of those awesome changes for future Kubernetes releases. For example, we're working on the SLSA Level 3 Compliance in the Kubernetes Release Process or the Renaming of the kubernetes/kubernetes default branch name to main . Thank you for reading this blog post! I'd like to use this opportunity to give all involved SIG Release folks a special shout-out for shipping this feature in time! Feel free to reach out to us by using the SIG Release mailing list or the #sig-release Slack channel. Additional resources Signing Release Artifacts Enhancement Proposal

Authors: Chris Short , Frederico Muñoz In my work in the Kubernetes world, I look up a label or Prow command often. The systems behind the scenes (Prow and Tide ) are here to help Kubernetes Contributors get stuff done. Labeling which SIG, WG, or subproject is as important as the issue or PR having someone assigned. To quote the docs , “Tide is a Prow component for managing a pool of GitHub PRs that match a given set of criteria. It will automatically retest PRs that meet the criteria (‘tide comes in’) and automatically merge them when they have up-to-date passing test results (‘tide goes out’).” What actually prompted this article is the awesomely amazing folks on the Contributor Comms team saying, “I need to squash my commits and push that.” Which immediately made me remember the wonder of the Tide label: tide/merge-method-squash . Why is this helpful Contributing to Kubernetes will, most of the time, involve some kind of git-based action, specifically on the Kubernetes GitHub. This can be an obstacle to those less exposed to git and/or GitHub, and is especially noticeable when we’re dealing with non-code contributions (documentation, blog posts, etc.). When a contributor submits something, it will generally be through a pull request . When it comes to how the change will go from request to approval, there are a number of considerations that must be made, such as: How should we request reviews? How do we assign the request to a specific SIG? How do we approve things while making it public and easily traceable? How to merge a contribution without carrying all the commit messages that were created during the review? These are some of the main tasks in which Tide will help, allowing us to use the GitHub interface for these tasks (and more), making the actions more visible to the community (since they are visible as plain comments in the GitHub discussion), and allowing us to manage contributions without necessarily having to clone git repositories or having to manually issue git commands. Back to squashing One of the most common examples, and getting back to my initial one, is squashing commits: if someone makes a change in a PR, there will likely be reviews and changes, and each one of them will add a new commit message. If left like this, the PR will add to the main branch all the commit messages created during the review process, which will make the history of the main branch less readable: instead of a single informative description about a specific unit of work , it will contain multiple commit messages that, out of the original context of the PR, will not be very helpful. To avoid this, we can squash the commit messages to keep just one of them (usually, the first one): the changes will still be visible for anyone reading the PR, but they will appear as a single commit to the main branch. This can be done through git , and a cursory read of how it’s done will not be obvious to someone relatively new to git! Is there a way to avoid cloning the repository (or PR), issuing git commands locally, and pushing the changes? There is, with Tide. Squashing your commits is a label away and the tooling will do the rest. To do this on your PR you’ll need to comment with the following: /label tide/merge-method-squash This will: Trigger Tide to squash the messages prior to merging. As a secondary effect, make your action clearly visible in the discussion section of the PR. This use of Tide is one of the most useful when submitting changes that undergo changes during the PR discussion, since it automates something to do The Right Thing (TM). There’s often nothing better than an example, so let’s take a look at this proposed change to the Kubernetes website , on the topic of the dockershim removal FAQ. The initial commit is followed by several others , a result of the conversation and proposed reviews. The result of all those changes is merged as a single commit, with the commit message retaining the title of the very first commit done, and the commit description being the aggregate of all the commits done in the PR. This was achieved by using /label tide/merge-method-squash in a comment , and did away with the need to manually rebase and/or squash using git : everything was possible through the GitHub interface. Assignment, review, approval. Another area in which Prow and Tide are very useful is in dealing with assignments, reviews, and approvals. Starting with assignment , the need to assign a PR to someone is very common. There are ways to do it through the GitHub interface, but using Prow commands, as mentioned before, makes the actions more visible and explicitly trigger the automation mechanism. Using /assign in a comment will assign the PR to yourself, or reassign it to someone else. Asking for reviews is another very common task: with Prow it’s just a /cc @foo @bar @baz away, and this can be directly added in the initial PR description, or in any subsequent comment. Approving a PR is one area in which making the process easily visible is very important, and, unsurprisingly, we can use /lgtm (looks good to me ) to publicly state our agreement, and at the same time trigger the automated processes that will, hopefully, result in the merging of the contribution. Using lgtm adds (or, if using /lgtm cancel , removes) the lgtm label, while using /approve will approve the PR for merging (and can only be used by those with the necessary authorization). To summarize, /assign makes it public that an assignment as been made (I use it often when I need to assign an issue to myself), and by who; /lgtm makes it clear from the comments that a review was made and, automatically, adds the lgtm label which is required for approval, and /approve approves the PR for merging. An example of many of these is this update to the Kubernetes Community site : we can see how additional reviewers were added with /cc , and following the discussion and changes, both the /lgtm and /approve commands are used to trigger the merging. More information on the review and approval cycle can be found in the documentation , which also explains in more detail when should certain commands be used, and by who. More about Prow and Tide The previous examples are some of the most commonly used, but Prow and Tide provide a lot more. These two pages document all the functionality available to Kubernetes contributors (either through labels or Prow): Prow Command Help test-infra/label_sync/labels.md Labels are most commonly applied by using an associated command (e.g. /lgtm , instead of /label lgtm ): only when no such command exists are labels applied directly with the label command; some of my more often used commands and labels: /assign (using it without adding a name assigns yourself) /honk /(woof|bark|this-is-{fine|not-fine|unbearable}) /remove-lifecycle stale (when issues aren’t touched for a period of time they’re marked stale) /shrug /area contributor-comms (You can use this to flag down the contributor communications team for reviews, comments on any issue, feedback, etc.) /label size/X (Sizes are assigned automatically based on the number of lines changed in the PR) /hold (This one is used for many things; if your PR is a work in progress, needs to be held to a certain date, etc.) /lgtm (Adds or removes the ‘lgtm’ label which is typically used to gate merging) /approve (Approves a pull request; must be done by someone in the repo’s OWNERS file) More advanced usage What if you need a label that isn’t available on a certain GitHub repository? I’m glad you asked! This PR demonstrates how to add labels to a repo: https://github.com/kubernetes/test-infra/pull/24315 . You’ll need to update the labels.yaml file (the configuration) and the labels.md file (documentation). This is why the label_sync tool, along with the logic Prow and Tide, simplify GitHub-based processes: they allow the automation of common actions without necessarily having to leave the web-based GitHub interface. label_sync ensures that labels are applied uniformly across repositories. I’ve done this once in five years of contributing. But, it’s good to write it down as it’s something that isn’t as trivial as you think because of the importance of the label_sync tooling. These are a handful of the commands and labels I enjoy. I’m sure there are many others that are helpful to folks. With that in mind, see if there’s something you can benefit from in these resources. They are there to make working on Kubernetes a better experience. If you think there’s some functionality missing, I’d invite you to drop a Slack message in SIG ContribEx or SIG Testing to discuss. Huge shoutout : To the folks that keep these systems humming along for the Kubernetes community. Couldn’t do it without y’all.