Archive This Repo and Forward Guidance

[JustinGrote]

Summary of the new feature / enhancement

CC @sdwheeler @StevenBucher98 @mgreenegit

With the announcement of PowerShell/Announcements#75 that the dotnet SDK docker is now the official PowerShell image, this repo should be archived so as not to confuse users that this may be under active development.

There are some unanswered questions needed, since the announcements has locked discussion:

Version Alignment and Identification

PowerShell releases do not align neatly with .NET SDK releases, especially recently with PowerShell releases lagging months after new .NET versions. When the PowerShell team does a security release e.g. 7.4.1, how are we to know and track what image that release will be available in? What is going to be the assurance on lead time, is the .NET SDK team willing to rebuild their images the moment those new powershell releases come out, or do they lag to when the .NET SDK revision gets bumped? All of these are concerns about maintaining security and update consistency in an environment. Sure we can always add on a layer to install the newer version ourselves, but if the whole point is for this to be a supported solution, it has to provide the same kind of expected lifecycle support.

I would recommend the team at least maintain a powershell docker tag that ties releases to SDK image hashes. The team will not be doing any building of containers, merely linking the appropriate image hashes so people can still track mcr.microsoft.com/powershell appropriately.

Runtime Images

The SDK image is focused on development, and is heavyweight. It is not a good base environment to run as a runtime powershell container, especially from an attack surface, image size, and supply chain perspective (as good as the SDK supply chain is). The .NET team provides distroless images based on Azure Linux and Dotnet Chiseled that are perfect for this. Ideally the team would provide images similar to what I provide at https://github.com/JustinGrote/PowerShell-Containers/pkgs/container/powershell but I understand with resource constraints if this must remain a community offering.

Again, I think this is a good forward approach and the reasoning makes sense, but I feel there needs to be a bit more done to maintain the branding of the container images, and enable Powershell to continue to thrive in a container world as a competitive offering alongside python, etc.

[theJasonHelmick]

Thanks @JustinGrote for this issue. I appreciate your time in meeting to discuss further. I will post here with further discussion and details.

[the-mentor]

Very well explained.
I myself agree with the attack surface and size of images.

There is no way I will use the .NET SDK images for PowerShell in production.

It will make more sense to build my own images based on something like alpine for a a very minimal attack surface.

[theJasonHelmick]

Thank you @JustinGrote for clarifying the above issue with us. I will write a plan of our future actions here in a few weeks after investigation and discussion.

[floh96]

@theJasonHelmick can you give us an update on the issues mentioned by Justin?
These are important issues which should have been considered before making the breaking change in my opinion.

[theJasonHelmick]

@floh96 - I think Justin has made some very valuable comments. I'm investigating some of these options such as tagging and better guidance around the Chiseled images. I don't have an update as of today. I appreciate the feedback and I'll let you know if there is any change to our official docker image guidance: https://learn.microsoft.com/en-us/powershell/scripting/install/powershell-in-docker?view=powershell-7.5

Use PowerShell in Docker - PowerShell

How to use PowerShell in a Docker image.