Adding design doc for supporting publishing recipes to insecure registry #30
Conversation
Signed-off-by: Vishwanath Hiremath <[email protected]>
| #### Recipe List/Show | ||
| Add a new column to recipe list/show output table. | ||
|
|
||
| | NAME | TYPE | TEMPLATE KIND | TEMPLATE VERSION | TEMPLATE | INSECURE-HTTP| |
There was a problem hiding this comment.
I'm worried that we might be scaling too the width of the table too far.
I think we can remove it from rad recipe list for the table format.
And for rad recipe show we may only want to show it on rad recipe show -o json
There was a problem hiding this comment.
👍
I'm not sure there's a need to show this in rad recipe list/show. There's a limit to what what we can do with tables. If users need to see every detail, that's what -o json is for.
| ``` | ||
| rad bicep publish --file ./redis-test.bicep --target br:localhost:5000/myregistry/redis-test:v1 | ||
| ``` | ||
| I would like to see `rad bicep publish` command successfully publish bicep file to locally hosted registry and also I should be able to read it from the registry during recipe deployment. |
There was a problem hiding this comment.
Great feature! Will be very helpful in local testing!
|
|
||
| ## Alternatives considered | ||
|
|
||
| #### Automatically identify the insecure registry. |
There was a problem hiding this comment.
I still want to explore if we can special-case localhost so insecure-http is set to true automatically. The user can still set it to false manually for the edge case where they roll their own SSL certificate locally. And it will allow the publish and register commands to work be default the first time instead of getting an error message.
There was a problem hiding this comment.
Especially because a user won't know there's a problem for Recipe registration until a Recipe deployment is attempted. Having it "just work" without waiting until a deployment to see the error message is a much better user experience.
There was a problem hiding this comment.
For context the oras client special cases localhost to use insecure http.
There was a problem hiding this comment.
I still want to explore if we can special-case
localhostsoinsecure-httpis set to true automatically. The user can still set it to false manually for the edge case where they roll their own SSL certificate locally. And it will allow the publish and register commands to work be default the first time instead of getting an error message.
I want to argue about this 😆 because I don't think it's useful.
For locally-hosted registries the pull and push URLs are asymmetric. rad recipe publish uses localhost, and recipe registration DOES NOT use localhost. Users still deal with the same level of complexity because Kubernetes is involved. I don't think the heuristic helps.
Our usecase is different from ORAS' use case. I'd rather be explict, and I don't think this detail is worth explaining to users, it feels like noob-trap.
There's also no such thing as setting a command-line flag to false, so it requires a different design. Security should be opt-out rather than opt-in.
There was a problem hiding this comment.
Have we also thought about possible security issues insecure registries may bring?
There was a problem hiding this comment.
For the same reason, would it be good to restrict insecure registries to just localhost?
There was a problem hiding this comment.
This is why weaking security is explicit for users. It's not a security issue if it's communicated clearly and the user understands the choice they are making.
To paraphrase one of my security-expert friends:
Good security features are usable. If security features are not usable, then users will find bad alternatives.
The user is able to understand their scenario and whether it's appropriate. Our code is general purpose and can't make assumptions.
| ### Design details | ||
| Since we use ORAS client to communicate with the registry, it provides an option "plain-http" to allow insecure connections to registry without SSL check. `plainHttp` property should be set to `true` when client to the remote repository is created to support using insecure registries. | ||
|
|
||
| #### Introduce "insecure-http" opt-in flag for users. |
There was a problem hiding this comment.
Have we considered alternative parameter names that more explicitly describe the action being taken, such as skipTLSVerification? The term insecure can be somewhat vague and might inadvertently give a negative impression.
There was a problem hiding this comment.
today docker uses "--insecure" flag and ORAS uses "--plain-http" flag to be set if user wants to use insecure registry.
I and @rynowak discussed on this and decided on using --insecure-http to be explicit to the users that they would be using http link i.e insecure but many of us were leaning towards using --plain-http flag to be consistent with ORAS and since we would be setting plainHttp flag in the backend.
@ryanwaite wanted to know your thoughts on this.
cc: @kachawla, @AaronCrawfis , @willtsai
There was a problem hiding this comment.
I had an offline discussion with @ryanwaite and agreed upon using --plain-http flag. Will update it in the doc
Signed-off-by: Vishwanath Hiremath <[email protected]>
Signed-off-by: Vishwanath Hiremath <[email protected]>
Signed-off-by: Vishwanath Hiremath <[email protected]>
…try (radius-project#30) Adding design doc for supporting publishing recipes to insecure registry. Issue: radius-project/radius#6648 Design Doc: https://github.com/radius-project/design-notes/blob/c92de0aeb006c48887388cb1726bb16e9ca37f65/recipe/2023-11-support-insecure-registries.md --------- Signed-off-by: Vishwanath Hiremath <[email protected]> Signed-off-by: sk593 <[email protected]>
Adding design doc for supporting publishing recipes to insecure registry.
Issue: radius-project/radius#6648
Design Doc: https://github.com/radius-project/design-notes/blob/c92de0aeb006c48887388cb1726bb16e9ca37f65/recipe/2023-11-support-insecure-registries.md