Try out MicroShift, Kubernetes optimized for small form factor and edge computing, on your local machine.
Read More at Enable Sysadmin
Try out MicroShift, Kubernetes optimized for small form factor and edge computing, on your local machine.
Read More at Enable Sysadmin
As a sysadmin, you spend a lot of time on somebody else’s computer. Choose your remote file-editing tools wisely!
Read More at Enable Sysadmin
SAN FRANCISCO – August 11, 2022 – Today, the ELISA (Enabling Linux in Safety Applications) Project announced that Boeing has joined as a Premier member, marking its commitment to Linux and its effective use in safety critical applications. Hosted by the Linux Foundation, ELISA is an open source initiative that aims to create a shared set of tools and processes to help companies build and certify Linux-based safety-critical applications and systems.
“Boeing is modernizing software to accelerate innovation and provide greater value to our customers,” said Jinnah Hosein, Vice President of Software Engineering at the Boeing Company. “The demand for safe and secure software requires rapid iteration, integration, and validation. Standardizing around open source products enhanced for safety-critical avionics applications is a key aspect of our adoption of state-of-the-art techniques and processes.”
As a leading global aerospace company, Boeing develops, manufactures and services commercial airplanes, defense products, and space systems for customers in more than 150 countries. It’s already using Linux in current avionics systems, including commercial systems certified to DO-178C Design Assurance Level D. Joining the ELISA Project will help pursue the vision for generational change in software development at Boeing. Additionally, Boeing will work with the ELISA Technical Steering Committee (TSC) to launch a new Aerospace Working Group that will work in parallel with the other working groups like automotive, medical devices, and others.
“We want to improve industry-standard tools related to certification and assurance artifacts in order to standardize improvements and contribute new features back to the open source community. We hope to leverage open source tooling (such as a cloud-based DevSecOps software factory) and industry standards to build world class software and provide an environment that attracts industry leaders to drive cultural change at Boeing,” said Hosein.
Linux is used in all major industries because it can enable faster time to market for new features and take advantage of the quality of the code development processes. Launched in February 2019, ELISA works with Linux kernel and safety communities to agree on what should be considered when Linux is used in safety-critical systems. The project has several dedicated working groups that focus on providing resources for system integrators to apply and use to analyze qualitatively and quantitatively on their systems.
“Linux has a history of being a reliable and stable development platform that advances innovation for a wide range of industries,” said Kate Stewart, Vice President of Dependable Embedded Systems at the Linux Foundation. “With Boeing’s membership, ELISA will start a new focus in the aerospace industry, which is already using Linux in selected applications. We look forward to working with Boeing and others in the aerospace sector, to build up best practices for working with Linux in this space.”
Other ELISA Project members include ADIT, AISIN AW CO., Arm, Automotive Grade Linux, Automotive Intelligence and Control of China, Banma, BMW Car IT GmbH, Codethink, Elektrobit, Horizon Robotics, Huawei Technologies, Intel, Lotus Cars, Toyota, Kuka, Linuxtronix. Mentor, NVIDIA, SUSE, Suzuki, Wind River, OTH Regensburg, Toyota and ZTE.
Upcoming ELISA Events
The ELISA Project has several upcoming events for the community to learn more or to get involved including:
ELISA Summit – Hosted virtually for participants around the world on September 7-8, this event will feature overview of the project, the mission and goals for each working group and an opportunity for attendees to ask questions and network with ELISA leaders. The schedule is now live and includes speakers from Aptiv Services Deutschland GmbH, Boeing, CodeThink, The Linux Foundation, Mobileye, Red Hat and Robert Bosch GmbH. Check out the schedule here: https://events.linuxfoundation.org/elisa-summit/program/schedule/. Registration is free and open to the public. https://elisa.tech/event/elisa-summit-virtual/ELISA Forum – Hosted in-person in Dublin, Ireland, on September 12, this event takes place the day before Open Source Summit Europe begins. It will feature an update on all of the working groups, an interactive System-Theoretic Process Analysis (STPA) use case and an Ask Me Anything session. Pre-registration is required. To register for ELISA Forum, add it to your Open Source Summit Europe registration.Open Source Summit Europe – Hosted in-person in Dublin and virtually on September 13-16, ELISA will have two dedicated presentations about enabling safety in safety-critical applications and safety and open source software. Learn more.
For more information about ELISA, visit https://elisa.tech/.
About the Linux Foundation
Founded in 2000, the Linux Foundation and its projects are supported by more than 2,950 members. The Linux Foundation is the world’s leading home for collaboration on open source software, hardware, standards, and data. Linux Foundation projects are critical to the world’s infrastructure including Linux, Kubernetes, Node.js, ONAP, Hyperledger, RISC-V, and more. The Linux Foundation’s methodology focuses on leveraging best practices and addressing the needs of contributors, users, and solution providers to create sustainable models for open collaboration. For more information, please visit us at linuxfoundation.org.
The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see its trademark usage page: www.linuxfoundation.org/trademark-usage. Linux is a registered trademark of Linus Torvalds.
###
The post Boeing joins the ELISA Project as a Premier Member to Strengthen its Commitment to Safety-Critical Applications appeared first on Linux Foundation.
Add Red Hat Single Sign-On (RHSSO) to ADFS to help improve user authentication and management.
Read More at Enable Sysadmin
This post is authored by Hayden Blauzvern and originally appeared on Sigstore’s blog. Sigstore is a new standard for signing, verifying, and protecting software. It is a project of the Linux Foundation.
Developers, package maintainers, and enterprises that would like to adopt Sigstore may already sign published artifacts. Signers may have existing procedures to securely store and use signing keys. Sigstore can be used to sign artifacts with existing self-managed, long-lived signing keys. Sigstore provides a simple user experience for signing, verification, and generating structured signature metadata for artifacts and container signatures. Sigstore also offers a community-operated, free-to-use transparency log for auditing signature generation.
Sigstore additionally has the ability to use code signing certificates with short-lived signing keys bound to OpenID Connect identities. This signing approach offers simplicity due to the lack of key management; however, this may be too drastic of a change for enterprises that have existing infrastructure for signing. This blog post outlines strategies to ease adoption of Sigstore while still using existing signing approaches.
Developers that maintain their own signing keys but want to migrate to Sigstore can first switch to using Cosign to generate a signature over an artifact. Cosign supports importing an existing RSA, ECDSA, or ED25519 PEM-encoded PKCS#1 or PKCS#8 key with cosign import-key-pair –key key.pem, and can sign and verify with cosign sign-blob –key cosign.key artifact-path and cosign verify-blob –key cosign.pub artifact-path.
Developers can get accustomed to Sigstore tooling to sign and verify artifacts.
Sigstore tooling can be integrated into CI/CD pipelines.
For signing containers, signature metadata is published with the OCI image in an OCI registry.
While maintaining their own signing keys, developers can increase auditability of signing events by publishing signatures to the Sigstore transparency log, Rekor. This allows developers to audit when signatures are generated for artifacts they maintain, and also monitor when their signing key is used to create a signature.
Developers can upload a signature to the transparency log during signing with COSIGN_EXPERIMENTAL=1 cosign sign-blob –key cosign.key artifact-path. If developers would like to use their own signing infrastructure while still publishing to a transparency log, developers can use the Rekor CLI or API. To upload an artifact and cryptographically verify its inclusion in the log using the Rekor CLI:
rekor-cli upload –rekor_server https://rekor.sigstore.dev
–signature
–public-key
–artifact <url_to_artifact|local_path></url_to_artifact|local_path>rekor-cli verify –rekor_server https://rekor.sigstore.dev
–signature
–public-key
–artifact <url_to_artifact|local_path></url_to_artifact|local_path>
In addition to PEM-encoded certificates and public keys, Sigstore supports uploading many different key formats, including PGP, Minisign, SSH, PKCS#7, and TUF. When uploading using the Rekor CLI, specify the –pki-format flag. For example, to upload an artifact signed with a PGP key:
gpg –armor -u user@example.com –output signature.asc –detach-sig package.tar.gzgpg –export –armor “user@example.com” > public.keyrekor-cli upload –rekor_server https://rekor.sigstore.dev
–signature signature.asc
–public-key public.key
–pki-format=pgp
–artifact package.tar.gz
Developers begin to publish signing events for auditability.
Artifact consumers can create a verification policy that requires a signature be published to a transparency log.
When requesting a code signing certificate from the Sigstore certificate authority Fulcio, Fulcio binds an OpenID Connect identity to a key, allowing for a verification policy based on identity rather than a key. Developers can request a code signing certificate from Fulcio with a self-managed long-lived key, sign an artifact with Cosign, and upload the artifact signature to the transparency log.
However, artifact consumers can still fail-open with verification (allow the artifact, while logging the failure) if they do not want to take a hard dependency on Sigstore (require that Sigstore services be used for signature generation). A developer can use their self-managed key to generate a signature. A verifier can simply extract the verification key from the certificate without verification of the certificate’s signature. (Note that verification can occur offline, since inclusion in a transparency log can be verified using a persisted signed bundle from Rekor and code signing certificates can be verified with the CA root certificate. See Cosign’s verification code for an example of verifying the Rekor bundle.)
Once a consumer takes a hard dependency on Sigstore, a CI/CD pipeline can move to fail-closed (forbid the artifact if verification fails).
A stronger verification policy that enforces both the presence of the signature in a transparency log and the identity of the signer.
Verification policies can be enforced fail-closed.
This final step is added for completeness. Signing is done using code signing certificates, and signatures must be published to a transparency log for verification. With identity-based signing, fail-closed is the only option, since Sigstore services must be online to retrieve code signing certificates and append entries to the transparency log. Developers will no longer need to maintain signing keys.
The Sigstore tooling and infrastructure can be used as a whole or modularly. Each separate integration can help to improve the security of artifact distribution while allowing for incremental updates and verifying each step of the integration.
The post Adopting Sigstore Incrementally appeared first on Linux Foundation.
By understanding Base64 encoding, you can apply it to Kubernetes secrets, OpenSSL, email applications, and other common situations.
Read More at Enable Sysadmin
This post is authored by Hayden Blauzvern and originally appeared on Sigstore’s blog. Sigstore is a new standard for signing, verifying, and protecting software. It is a project of the Linux Foundation.
Developers, package maintainers, and enterprises that would like to adopt Sigstore may already sign published artifacts. Signers may have existing procedures to securely store and use signing keys. Sigstore can be used to sign artifacts with existing self-managed, long-lived signing keys. Sigstore provides a simple user experience for signing, verification, and generating structured signature metadata for artifacts and container signatures. Sigstore also offers a community-operated, free-to-use transparency log for auditing signature generation.
Sigstore additionally has the ability to use code signing certificates with short-lived signing keys bound to OpenID Connect identities. This signing approach offers simplicity due to the lack of key management; however, this may be too drastic of a change for enterprises that have existing infrastructure for signing. This blog post outlines strategies to ease adoption of Sigstore while still using existing signing approaches.
Developers that maintain their own signing keys but want to migrate to Sigstore can first switch to using Cosign to generate a signature over an artifact. Cosign supports importing an existing RSA, ECDSA, or ED25519 PEM-encoded PKCS#1 or PKCS#8 key with cosign import-key-pair –key key.pem, and can sign and verify with cosign sign-blob –key cosign.key artifact-path and cosign verify-blob –key cosign.pub artifact-path.
Developers can get accustomed to Sigstore tooling to sign and verify artifacts.
Sigstore tooling can be integrated into CI/CD pipelines.
For signing containers, signature metadata is published with the OCI image in an OCI registry.
While maintaining their own signing keys, developers can increase auditability of signing events by publishing signatures to the Sigstore transparency log, Rekor. This allows developers to audit when signatures are generated for artifacts they maintain, and also monitor when their signing key is used to create a signature.
Developers can upload a signature to the transparency log during signing with COSIGN_EXPERIMENTAL=1 cosign sign-blob –key cosign.key artifact-path. If developers would like to use their own signing infrastructure while still publishing to a transparency log, developers can use the Rekor CLI or API. To upload an artifact and cryptographically verify its inclusion in the log using the Rekor CLI:
rekor-cli upload –rekor_server https://rekor.sigstore.dev
–signature <artifact_signature>
–public-key <your_public_key>
–artifact <url_to_artifact|local_path>
rekor-cli verify –rekor_server https://rekor.sigstore.dev
–signature <artifact-signature>
–public-key <your_public_key>
–artifact <url_to_artifact|local_path>
In addition to PEM-encoded certificates and public keys, Sigstore supports uploading many different key formats, including PGP, Minisign, SSH, PKCS#7, and TUF. When uploading using the Rekor CLI, specify the –pki-format flag. For example, to upload an artifact signed with a PGP key:
gpg –armor -u user@example.com –output signature.asc –detach-sig package.tar.gz
gpg –export –armor “user@example.com” > public.key
rekor-cli upload –rekor_server https://rekor.sigstore.dev
–signature signature.asc
–public-key public.key
–pki-format=pgp
–artifact package.tar.gz
Developers begin to publish signing events for auditability.
Artifact consumers can create a verification policy that requires a signature be published to a transparency log.
When requesting a code signing certificate from the Sigstore certificate authority Fulcio, Fulcio binds an OpenID Connect identity to a key, allowing for a verification policy based on identity rather than a key. Developers can request a code signing certificate from Fulcio with a self-managed long-lived key, sign an artifact with Cosign, and upload the artifact signature to the transparency log.
However, artifact consumers can still fail-open with verification (allow the artifact, while logging the failure) if they do not want to take a hard dependency on Sigstore (require that Sigstore services be used for signature generation). A developer can use their self-managed key to generate a signature. A verifier can simply extract the verification key from the certificate without verification of the certificate’s signature. (Note that verification can occur offline, since inclusion in a transparency log can be verified using a persisted signed bundle from Rekor and code signing certificates can be verified with the CA root certificate. See Cosign’s verification code for an example of verifying the Rekor bundle.)
Once a consumer takes a hard dependency on Sigstore, a CI/CD pipeline can move to fail-closed (forbid the artifact if verification fails).
A stronger verification policy that enforces both the presence of the signature in a transparency log and the identity of the signer.
Verification policies can be enforced fail-closed.
This final step is added for completeness. Signing is done using code signing certificates, and signatures must be published to a transparency log for verification. With identity-based signing, fail-closed is the only option, since Sigstore services must be online to retrieve code signing certificates and append entries to the transparency log. Developers will no longer need to maintain signing keys.
The Sigstore tooling and infrastructure can be used as a whole or modularly. Each separate integration can help to improve the security of artifact distribution while allowing for incremental updates and verifying each step of the integration.
Learn how pods communicate with each other when they are on different Kubernetes nodes.
Read More at Enable Sysadmin
The following post originally appeared on Medium. The author, Ruchi Pakhle, participated in our LFX Mentorship program this past spring.
echo “amazing experience”
Hey everyone!
I am Ruchi Pakhle currently pursuing my Bachelor’s in Computer Engineering from MGM’s College of Engineering & Technology. I am a passionate developer and an open-source enthusiast. I recently graduated from LFX Mentorship Program. In this blog post, I will share my experience of contributing to Open Horizon, a platform for deploying container-based workloads and related machine learning models to compute nodes/clusters on edge.
I have been an active contributor to open-source projects via different programs like GirlScript Summer of Code, Script Winter of Code & so on.. through these programs I contributed to different beginner-level open-source projects. After almost doing this for a year, I contributed to different organizations for different projects including documentation and code. On a very random morning applications for LFX were opened up and I saw various posts on LinkedIn among that posts one post was of my very dear friend Unnati Chhabra, she had just graduated from the program and hence I went ahead and checked the organization that was a fit as per my skill set and decided to give it a shot.
I was very interested in DevOps and Cloud Native technologies and I wanted to get started with them but have been procrastinating a lot and did not know how to pave my path ahead. I was constantly looking for opportunities that I can get my hands on. And as Open Horizon works exactly on DevOps and Cloud Native technologies, I straight away applied to their project and they had two slots open for the spring cohort. I joined their element channel and started becoming active by contributing to the project, engaging with the community, and also started to read more about the architecture and tried to understand it well by referring to their youtube videos. You can contribute to Open Horizon here.
Linux Foundation opens LFX mentorship applications thrice a year: one in spring, one in summer, and the winter cohort, each cohort being for a span of 3 months. I applied to the winter cohort for which the applications opened up around February 2022 and I submitted my application on 4th February 2022 for the Open Horizon Project. I remember there were three documents mandatory for submitting the application:
1. Updated Resume/CV
2. Cover Letter
(this is very very important in terms of your selection so cover everything in your cover letter and maybe add links to your projects, achievements, or wherever you think they can add great value)
The cover letter should cover these points primarily
How did you find out about our mentorship program?
Why are you interested in this program?
What experience and knowledge/skills do you have that are applicable to this program?
What do you hope to get out of this mentorship experience?
3. A permission document from your university stating they have no obligation over the entire span of the mentorship was also required (this depends on org to org and may not be asked as well)
The LFX acceptance mail was a major achievement for me as at that period of time I was constantly getting rejections and I had absolutely no idea about how things were gonna work out for me. I was constantly doubting myself and hence this mail not only boosted my confidence but also gave me a ray of hope of achieving things by working hard towards it consistently. A major thanks to my mentor, Joe Pearson, and Troy Fine for believing in me and giving me this opportunity.
Starting off from the day I applied to the LFX until getting selected as an LFX Mentee and working successfully for over 3 months and a half, it felt surreal. I have been contributing to open-source projects and organizations before. But being a part of LFX gave me such a huge learning curve and a sense of credibility and ownership that I got here wouldn’t have gotten anywhere else.
I have been contributing to open-source projects and organizations before. But being a part of LFX gave me such a huge learning curve and a sense of credibility and ownership that I got here wouldn’t have gotten anywhere else.
I still remember setting up the mgmt-hub all-in-one script locally and I thought it was just a cakewalk, well it was not. I literally used to try every single day to run the script but somehow it would end up giving some errors, I used to google them and apply the results but still, it would fail. But one thing which I consistently did was share my progress regularly with my mentor, Troy no matter if the script used to fail but still I used to communicate that with Troy, I would send him logs and he used to give me some probable solutions for the same but still the script used to fail. I then messaged in the open-horizon-examples group and Joe used to help with my doubts, a huge thanks to him and Troy for helping me figure out things patiently. After over a month on April 1st, the script got successfully executed and then I started to work on the issues assigned by Troy.
These three months taught me to be consistent no matter what the circumstances are and work patiently which I wouldn’t have learned in my college. This experience would no doubt make me a better developer and engineer along with the best practices followed. A timeline of my journey has been shared here.
Checkout my contributions here
Checkout open-horizon-services repo
The LFX Mentorship Program was a great great experience and I did get a great learning curve which I wouldn’t have gotten any other way. The program not only encourages developers to kick-start their open-source journey but also provides some great perks like networking, and learning from the best minds. I would like to thank my mentors Joe Pearson, Troy Fine, and Glen Darling because without their support and patience this wouldn’t have been possible. I would be forever grateful for this opportunity.
Special thanks to my mentor Troy for always being patient with me. These kind words would remain with me always although the program would have ended.
The LF Edge Mentorship program is always a great learning experience, and this year was no exception. Because of Ruchi’s work we now have more services following our best practice policies in the open-horizon-services github repository. Despite the time difference she was always flexible when it came to our sync-ups and was never afraid to ask questions or for clarification if something wasn’t clear. I hope Ruchi will continue to provide the meaningful contributions to the Open Horizon project I have seen her demonstrate throughout this mentorship program.
And yes how can I forget to plug in the awesome swags, special thanks, and gratitude to my mentor Joe Pearson for sending me such cool swags and this super cool note
The post LFX’22 Mentorship Experience with Open Horizon appeared first on Linux Foundation.
Kubernetes network stack fundamentals: How containers inside a pod communicate
Image
Photo by Moritz Kindler on Unsplash
Learn how containers communicate within a pod through the same Kubernetes network namespace
Posted:
August 8, 2022
|
%t min read
|
by
Anthony Critelli (Sudoer)
Topics:
Kubernetes
Networking
Read the full article on redhat.com
Read More at Enable Sysadmin