Suggested Reads

Suggested Reads

54935 bookmarks
Newest
Azure Linux released at Build – where Microsoft revealed why it did not fork Fedora • DEVCLASS
Azure Linux released at Build – where Microsoft revealed why it did not fork Fedora • DEVCLASS
At its Build developer event this week, Microsoft made Azure Linux – its own distribution of the open source operating system – generally available. During a Q&A session the principal program manager lead Jim Perrin also spoke about how the company’s history with Linux – Steve Ballmer, then CEO, said in 2001 that “Linux is […]
·devclass.com·
Azure Linux released at Build – where Microsoft revealed why it did not fork Fedora • DEVCLASS
BastilleBSD
BastilleBSD
Bastille is an open-source system for automating deployment and management of containerized applications on FreeBSD.
·bastillebsd.org·
BastilleBSD
Adidas After Yeezy
Adidas After Yeezy
The partnership with Ye, formerly known as Kanye West, was the stuff of sneakerhead legend—and its demise has the shoe company scrambling to replace nearly half of its profits.
·bloomberg.com·
Adidas After Yeezy
Kelsey Hightower on leadership in open source and the future of Kubernetes | The GitHub Blog
Kelsey Hightower on leadership in open source and the future of Kubernetes | The GitHub Blog
In this special episode of The ReadME Podcast, dedicated to GitHub’s Maintainer Month, Kelsey Hightower joins hosts Martin Woodward and Neha Batra to discuss his philosophy on fostering thriving open source communities and the importance of empathy to a maintainer’s success.
·github.blog·
Kelsey Hightower on leadership in open source and the future of Kubernetes | The GitHub Blog
Amazon EKS now supports Kubernetes version 1.27 | Amazon Web Services
Amazon EKS now supports Kubernetes version 1.27 | Amazon Web Services
Introduction The Amazon Elastic Kubernetes Service (Amazon EKS) team is pleased to announce support for Kubernetes version 1.27 for Amazon EKS and Amazon EKS Distro. Amazon EKS Anywhere (release 0.16.0) also supports Kubernetes 1.27. The theme for this version was chosen to recognize the fact that the release was pretty chill. Hence, the fitting release […]
·aws.amazon.com·
Amazon EKS now supports Kubernetes version 1.27 | Amazon Web Services
Matter gotchas to know about eight months after the standard's launch - Stacey on IoT | Internet of Things news and analysis
Matter gotchas to know about eight months after the standard's launch - Stacey on IoT | Internet of Things news and analysis
We’re nearly eight months into the Matter smart home protocol rollout and there are still some gotchas. I figured we’d have some initial pain points to deal with but I also thought that by now, some or all of them would have been addressed. Unfortunately due to different device makers taking different approaches during the […]
·staceyoniot.com·
Matter gotchas to know about eight months after the standard's launch - Stacey on IoT | Internet of Things news and analysis
What the Supreme Court’s Decision in Warhol Means for Fair Use
What the Supreme Court’s Decision in Warhol Means for Fair Use
The Supreme Court has issued its long-awaited decision in Andy Warhol Foundation v. Goldsmith, a fair use case that raised fundamental questions about rights and obligations of commercial artists. The Court’s opinion did not answer many of those questions, but happily it affirmed both important fair use precedents and the role of fair use as a crucial element of the copyright system. EFF filed an amicus brief in the case. These are the basic facts:
·eff.org·
What the Supreme Court’s Decision in Warhol Means for Fair Use
Blog: Using OCI artifacts to distribute security profiles for seccomp, SELinux and AppArmor
Blog: Using OCI artifacts to distribute security profiles for seccomp, SELinux and AppArmor
Author : Sascha Grunert The Security Profiles Operator (SPO) makes managing seccomp, SELinux and AppArmor profiles within Kubernetes easier than ever. It allows cluster administrators to define the profiles in a predefined custom resource YAML, which then gets distributed by the SPO into the whole cluster. Modification and removal of the security profiles are managed by the operator in the same way, but that’s a small subset of its capabilities. Another core feature of the SPO is being able to stack seccomp profiles. This means that users can define a baseProfileName in the YAML specification, which then gets automatically resolved by the operator and combines the syscall rules. If a base profile has another baseProfileName , then the operator will recursively resolve the profiles up to a certain depth. A common use case is to define base profiles for low level container runtimes (like runc or crun ) which then contain syscalls which are required in any case to run the container. Alternatively, application developers can define seccomp base profiles for their standard distribution containers and stack dedicated profiles for the application logic on top. This way developers can focus on maintaining seccomp profiles which are way simpler and scoped to the application logic, without having a need to take the whole infrastructure setup into account. But how to maintain those base profiles? For example, the amount of required syscalls for a runtime can change over its release cycle in the same way it can change for the main application. Base profiles have to be available in the same cluster, otherwise the main seccomp profile will fail to deploy. This means that they’re tightly coupled to the main application profiles, which acts against the main idea of base profiles. Distributing and managing them as plain files feels like an additional burden to solve. OCI artifacts to the rescue The v0.8.0 release of the Security Profiles Operator supports managing base profiles as OCI artifacts! Imagine OCI artifacts as lightweight container images, storing files in layers in the same way images do, but without a process to be executed. Those artifacts can be used to store security profiles like regular container images in compatible registries. This means they can be versioned, namespaced and annotated similar to regular container images. To see how that works in action, specify a baseProfileName prefixed with oci:// within a seccomp profile CRD, for example: apiVersion : security-profiles-operator.x-k8s.io/v1beta1 kind : SeccompProfile metadata : name : test spec : defaultAction : SCMP_ACT_ERRNO baseProfileName : oci://ghcr.io/security-profiles/runc:v1.1.5 syscalls : - action : SCMP_ACT_ALLOW names : - uname The operator will take care of pulling the content by using oras , as well as verifying the sigstore (cosign) signatures of the artifact. If the artifacts are not signed, then the SPO will reject them. The resulting profile test will then contain all base syscalls from the remote runc profile plus the additional allowed uname one. It is also possible to reference the base profile by its digest (SHA256) making the artifact to be pulled more specific, for example by referencing oci://ghcr.io/security-profiles/runc@sha256:380… . The operator internally caches pulled artifacts up to 24 hours for 1000 profiles, meaning that they will be refreshed after that time period, if the cache is full or the operator daemon gets restarted. Because the overall resulting syscalls are hidden from the user (I only have the baseProfileName listed in the SeccompProfile, and not the syscalls themselves), I'll additionally annotate that SeccompProfile with the final syscalls . Here's how the SeccompProfile looks after I annotate it: kubectl describe seccompprofile test Name: test Namespace: security-profiles-operator Labels: spo.x-k8s.io/profile-id=SeccompProfile-test Annotations: syscalls: [{"names":["arch_prctl","brk","capget","capset","chdir","clone","close",... API Version: security-profiles-operator.x-k8s.io/v1beta1 The SPO maintainers provide all public base profiles as part of the “Security Profiles” GitHub organization . Managing OCI security profiles Alright, now the official SPO provides a bunch of base profiles, but how can I define my own? Well, first of all we have to choose a working registry. There are a bunch of registries that already supports OCI artifacts: CNCF Distribution Azure Container Registry Amazon Elastic Container Registry Google Artifact Registry GitHub Packages container registry Bundle Bar Docker Hub Zot Registry The Security Profiles Operator ships a new command line interface called spoc , which is a little helper tool for managing OCI profiles among doing various other things which are out of scope of this blog post. But, the command spoc push can be used to push a security profile to a registry: export USERNAME=my-user export PASSWORD=my-pass spoc push -f ./examples/baseprofile-crun.yaml ghcr.io/security-profiles/crun:v1.8.3 16:35:43.899886 Pushing profile ./examples/baseprofile-crun.yaml to: ghcr.io/security-profiles/crun:v1.8.3 16:35:43.899939 Creating file store in: /tmp/push-3618165827 16:35:43.899947 Adding profile to store: ./examples/baseprofile-crun.yaml 16:35:43.900061 Packing files 16:35:43.900282 Verifying reference: ghcr.io/security-profiles/crun:v1.8.3 16:35:43.900310 Using tag: v1.8.3 16:35:43.900313 Creating repository for ghcr.io/security-profiles/crun 16:35:43.900319 Using username and password 16:35:43.900321 Copying profile to repository 16:35:46.976108 Signing container image Generating ephemeral keys... Retrieving signed certificate... Note that there may be personally identifiable information associated with this signed artifact. This may include the email address associated with the account with which you authenticate. This information will be used for signing this artifact and will be stored in public transparency logs and cannot be removed later. By typing 'y', you attest that you grant (or have permission to grant) and agree to have this information stored permanently in transparency logs. Your browser will now be opened to: https://oauth2.sigstore.dev/auth/auth?access_type=… Successfully verified SCT... tlog entry created with index: 16520520 Pushing signature to: ghcr.io/security-profiles/crun You can see that the tool automatically signs the artifact and pushes the ./examples/baseprofile-crun.yaml to the registry, which is then directly ready for usage within the SPO. If username and password authentication is required, either use the --username , -u flag or export the USERNAME environment variable. To set the password, export the PASSWORD environment variable. It is possible to add custom annotations to the security profile by using the --annotations / -a flag multiple times in KEY:VALUE format. Those have no effect for now, but at some later point additional features of the operator may rely them. The spoc client is also able to pull security profiles from OCI artifact compatible registries. To do that, just run spoc pull : spoc pull ghcr.io/security-profiles/runc:v1.1.5 16:32:29.795597 Pulling profile from: ghcr.io/security-profiles/runc:v1.1.5 16:32:29.795610 Verifying signature Verification for ghcr.io/security-profiles/runc:v1.1.5 -- The following checks were performed on each of these signatures: - Existence of the claims in the transparency log was verified offline - The code-signing certificate was verified using trusted certificate authority certificates [{"critical":{"identity":{"docker-reference":"ghcr.io/security-profiles/runc"},…}}] 16:32:33.208695 Creating file store in: /tmp/pull-3199397214 16:32:33.208713 Verifying reference: ghcr.io/security-profiles/runc:v1.1.5 16:32:33.208718 Creating repository for ghcr.io/security-profiles/runc 16:32:33.208742 Using tag: v1.1.5 16:32:33.208743 Copying profile from repository 16:32:34.119652 Reading profile 16:32:34.119677 Trying to unmarshal seccomp profile 16:32:34.120114 Got SeccompProfile: runc-v1.1.5 16:32:34.120119 Saving profile in: /tmp/profile.yaml The profile can be now found in /tmp/profile.yaml or the specified output file --output-file / -o . We can specify an username and password in the same way as for spoc push . spoc makes it easy to manage security profiles as OCI artifacts, which can be then consumed directly by the operator itself. That was our compact journey through the latest possibilities of the Security Profiles Operator! If you're interested in more, providing feedback or asking for help, then feel free to get in touch with us directly via Slack (#security-profiles-operator) or the mailing list .
·kubernetes.io·
Blog: Using OCI artifacts to distribute security profiles for seccomp, SELinux and AppArmor