Support private container registries for Pods which do not specifying image pull secrets #120
Comments
|
@danielpacak In case you missed it ^^ |
|
Hi @avdhoot ! Thank you for reporting this issue. I'm going to follow up on that and link it to a parent story or epic about configuring scanners. In your case the root cause is that we currently cannot pass TRIVY_USERNAME or TRIVY_PASSWORD envs, but there're more config options that users might want to pass to a scanner. |
|
@avdhoot Actually starboard can use image pull secret attached to the Pod template or the service account. In your case did you set the secret on the Pod template level or at the service account level? |
danielpacak
added
⏳ additional info required
|
Our cluster created using kops. We seeded it with registry secrets using below command. We do not have |
|
Thank you for providing all the details @avdhoot So just to rephrase and confirm my understanding: You neither use image pull Secret set at Pod template not Service Account. You're using a feature1 of kops to store the |
|
Thanks @danielpacak you are understanding is correct. |
danielpacak
added
🚀 enhancement
danielpacak
changed the title
|
@avdhoot I renamed the title of this issue to reflect the specific use case of kops and authorizing Kubernetes nodes to pull images from private registry and repositories. As already mentioned Starboard only supports recommended way of handling private registries with image pull secrets. |
|
I am trying to make use of the above discussed functionality within AKS. I am not finding that the operator pulls the imagePullSecret of the deployment. In my case I am exposing the secret as imagePullSecret on the deployment level. Secret generation command as detailed here: ACR Auth Docs
ACR Cred Secret:
Deployment Spec:
Operator Logs:
Looking forward to your response, as it would save my day. |
Hi @n3rd253 Currently we only support private registries with Starboard CLI. I hasn't been implemented for the operator yet, but we're working on that |
|
Hi guys ! Note 2 : Even if I try it using the CLI, it does not work : Is there any news / ETA on this or is this something you don't consider to add on a short time ? Thank you very much anyway, it's a great job ! |
|
Hi @mathieudebrito Starboard CLI and Starboard Operator v0.9 should read image pull Secret from pod template as explained here. If that's not the case it may be regression. I'll double check on our end. Could you provide more details regarding the private registry used in your setup? Is it Docker Hub or a managed registry such as ECR or GCR? Which authentication method are you using? Basic vs auth token? |
|
Hi @danielpacak Thank you for your quick answer !
If it helps, the secret is created as follow : Thank you again ! |
|
Hey @mathieudebrito I can reproduce this error so it seems to be regression or a corner case that's not handled properly by Starboard (both operator and CLI as they share this functions). I'll track it down and try to fix it in the upcoming bug fix release v0.9.1. Note: For some reason we cannot map registry server to container that refers to private image around these lines https://github.com/aquasecurity/starboard/blob/main/pkg/kube/secrets.go#L49 |
|
I found what was causing this problem. Essentially you can create image pull secret which is actually concatenation of registry server ( This was causing problem in v0.9.0$ kubectl create secret docker-registry regcred \
--docker-server=rg.pl-waw.scw.cloud/private \
--docker-username=nologin \
--docker-password=$SCW_SECRET_TOKEN --dry-run -o yaml | kubectl apply -f -This would work in v0.9.0$ kubectl create secret docker-registry regcred \
--docker-server=rg.pl-waw.scw.cloud \
--docker-username=nologin \
--docker-password=$SCW_SECRET_TOKEN --dry-run -o yaml | kubectl apply -f -This particular problem is fixed in #379. However the original issue was created to support private registries without specifying image pull secrets on a pod. For example, by configuring nodes to authenticate with private registry. |
|
@danielpacak awesome thank you ! Edit : Just tested the 0.9.1, it fixes well the issue I was having. I can now see the vulnerability reports, thank you so much for you so quick fix ! |
|
Hi, any chance to add supporting the private registry to the Helm, please? |
Please create a separate issue for that @maati55 . This issue has nothing to do with Helm charts. We'll never close it if we report this way. |
danielpacak
added
🙏 help wanted
We are running into this same issue. Could it perhaps be as simple as adding a configuration to mount the Docker config file from the host as a volume onto the Starboard pods doing the scanning? |
|
👋 @ryanbrainard I think we have already mentioned somewhere that mounting container runtime sockets is suboptimal for these reasons:
If you want to contribute to designing such functionality we'd appreciate reviewing design docs under the docs/design directory that are related to private and managed registries. You can also submit your own design proposal by following the template from existing docs. |
|
@avdhoot, @maati55, @mathieudebrito, @ryanbrainard, you may have a look at the PR I created: #1103 |
What steps did you take and what happened:
Followed install instructions. Tried to run scan using below on command.
What did you expect to happen:
Scan should completed without error
Anything else you would like to add:
trivysupport gcr. But I am not to able find way to pass customENVtotrivyusing starboard.Environment:
starboard version): Starboard Version: {Version:0.2.6 Commit:d43faefc56021ae55d4574054ce7de13175ca206 Date:2020-07-09T20:30:45Z}kubectl version): client:v1.17.10, server: v1.17.2The text was updated successfully, but these errors were encountered: