-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
azure: don't use managed identity on ARO #4843
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,14 @@ | ||
apiVersion: rbac.authorization.k8s.io/v1 | ||
kind: Role | ||
metadata: | ||
name: system:azure-cloud-provider-secret-getter | ||
namespace: kube-system | ||
rules: | ||
- apiGroups: | ||
- "" | ||
resourceNames: | ||
- azure-cloud-provider | ||
resources: | ||
- secrets | ||
verbs: | ||
- get |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,13 @@ | ||
apiVersion: rbac.authorization.k8s.io/v1 | ||
kind: RoleBinding | ||
metadata: | ||
name: system:azure-cloud-provider-secret-getter | ||
namespace: kube-system | ||
roleRef: | ||
apiGroup: rbac.authorization.k8s.io | ||
kind: Role | ||
name: system:azure-cloud-provider-secret-getter | ||
subjects: | ||
- kind: ServiceAccount | ||
name: azure-cloud-provider | ||
namespace: kube-system |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,8 @@ | ||
apiVersion: v1 | ||
kind: Secret | ||
metadata: | ||
name: azure-cloud-provider | ||
namespace: kube-system | ||
stringData: | ||
cloud-config: | | ||
{{.CloudConfig | indent 4}} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,80 @@ | ||
package openshift | ||
|
||
import ( | ||
"os" | ||
"path/filepath" | ||
|
||
"github.com/openshift/installer/pkg/asset" | ||
"github.com/openshift/installer/pkg/asset/templates/content" | ||
) | ||
|
||
const ( | ||
azureCloudProviderSecretFileName = "99_azure-cloud-provider-secret.yaml.template" | ||
azureCloudProviderSecretGetterRoleBindingFileName = "99_azure-cloud-provider-secret-getter-rolebinding.yaml" | ||
azureCloudProviderSecretGetterRoleFileName = "99_azure-cloud-provider-secret-getter-role.yaml" | ||
) | ||
|
||
var _ asset.WritableAsset = (*AzureCloudProviderSecret)(nil) | ||
|
||
// AzureCloudProviderSecret is the variable to represent contents of corresponding files | ||
type AzureCloudProviderSecret struct { | ||
FileList []*asset.File | ||
} | ||
|
||
// Dependencies returns all of the dependencies directly needed by the asset | ||
func (t *AzureCloudProviderSecret) Dependencies() []asset.Asset { | ||
return []asset.Asset{} | ||
} | ||
|
||
// Name returns the human-friendly name of the asset. | ||
func (t *AzureCloudProviderSecret) Name() string { | ||
return "AzureCloudProviderSecret" | ||
} | ||
|
||
// Generate generates the actual files by this asset | ||
func (t *AzureCloudProviderSecret) Generate(parents asset.Parents) error { | ||
t.FileList = []*asset.File{} | ||
|
||
for _, fileName := range []string{ | ||
azureCloudProviderSecretFileName, | ||
azureCloudProviderSecretGetterRoleBindingFileName, | ||
azureCloudProviderSecretGetterRoleFileName, | ||
} { | ||
data, err := content.GetOpenshiftTemplate(fileName) | ||
if err != nil { | ||
return err | ||
} | ||
t.FileList = append(t.FileList, &asset.File{ | ||
Filename: filepath.Join(content.TemplateDir, fileName), | ||
Data: []byte(data), | ||
}) | ||
} | ||
return nil | ||
} | ||
|
||
// Files returns the files generated by the asset. | ||
func (t *AzureCloudProviderSecret) Files() []*asset.File { | ||
return t.FileList | ||
} | ||
|
||
// Load returns the asset from disk. | ||
func (t *AzureCloudProviderSecret) Load(f asset.FileFetcher) (bool, error) { | ||
t.FileList = []*asset.File{} | ||
|
||
for _, fileName := range []string{ | ||
azureCloudProviderSecretFileName, | ||
azureCloudProviderSecretGetterRoleBindingFileName, | ||
azureCloudProviderSecretGetterRoleFileName, | ||
} { | ||
file, err := f.FetchByName(filepath.Join(content.TemplateDir, fileName)) | ||
if err != nil { | ||
if os.IsNotExist(err) { | ||
return false, nil | ||
} | ||
return false, err | ||
} | ||
t.FileList = append(t.FileList, file) | ||
} | ||
|
||
return true, nil | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,7 @@ | ||
// +build aro | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nit: There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would break these changes in There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Also it mimics the way OKD is planning to gate their code in this PR (see
+1. Will do that. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I decided to split the build tag bit into a separate PR: #4874 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Clarification: I'm happy for the build tag to be merged as part of this PR. But if there is still feedback related to managed identity - I suggest that we merge the build tag as part of #4874 as I have few more things that depend on it. |
||
|
||
package azure | ||
|
||
func init() { | ||
aro = true | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@patrickdillon an issue with the appraoch of using templates is this: we have to declare templates as dependencies and store will call
Generate()
on them even if we don't need them (e.g. non-ARO builds).What do you think? Is it something we should worry about?
We can probably use build tags and create two extra files in this package:
// +build aro
where we include them as dependencies// +build !aro
where we do not include themBut I don't want to rely on build tags too much in this case:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we're going with the template approach, I was thinking to just add them to the existing templates. Here's a simplified example: master...patrickdillon:azure-merge-cloud-config We would need to add a boolean field to
AzureCredsSecretData
to switch this behavior on or off depending on ASH/ARO.Also, not sure if it is valid to have the values of the cloud provider config secret be base64 encoded. I assume for the existing code, the cloud credential operator knows to base64 decode the values, but I assume that is up to the client. I don't see anything in the azure docs about this. If we don't know, we can test and see.
I would like to get @staebler's feedback about whether this is the right direction with templates. To summarize the context: In the case of ARO & ASH we need to create a secret (with the creds) , role, and role binding. I see a few options:
I'm pretty neutral on these options with a slight leaning toward option 1.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@patrickdillon thanks for the feedback. Replied to some of the comments.
I was thinking about reusing
data/data/manifests/openshift/cloud-creds-secret.yaml.template
, but it is already overloaded with logic and I didn't want to make it worse. Happy to do this if you think it is a better appraoch.We must encode values into base64 manually here because:
We add them into
Secret
'sdata
:We use templates. Normaly when marshaling into json/yaml from a go struct it will be done implicitly due to the fact that
data
is defined as follows:And
[]byte
in go marshaled as base64-encoded string.On the receiving end, the cloud provider doesn't have to decode the value explicilty here: go will do it behind the scenes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I look at this more closely I do think this current approach is on the right track. I think the approach should very closely follow the pattern here:
https://github.com/openshift/installer/blob/master/pkg/asset/manifests/openshift.go#L253-L259
So yes this is fine to have a dependency generated even when it is not used. The above example is only for private clusters, but is generated for all clusters. But you should consolidate all of these Azure Cloud Provider dependencies into a single asset, which in the above example would be equivalent to
private-cluster-outbound-service.go
. Note that the one asset could have many templates; so you could either have a separate template for each resource or combine the three resources in a single template.If this is unclear or your have questions let me know. I think this is the right drection!
Also, thanks for the detailed, awesome explanation of why secret values are b64 encoded. I didn't know that!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@patrickdillon I left 3 template files, but consolidated them into one assset. Now the naming is little bit tricky: I called it
AzureCloudProviderSecret
, but it contains the role, the role binding as well as the secret which might be a little bit confusing. Suggestions are welcome :)I'm also happy to put all yamls into one file, if you like. Having in separate templates/manifests is a tiny bit better for visibility, IMO. But I have no strong prefrences.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is looking good. Have you tested this? I hope to test it soon with Azure Stack.
Maybe
AzureMergedCloudConfig
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@patrickdillon
I did
openshift-install create manifests
witharo
build tag and manifests look good. I alos did it with a binary compiled withoutaro
build tag and relevant manifests were not present in the output directory, as expected.And I'm pretty confident that it will work with ARO because I tested it with older version of this PR (we did not change outputs significantly in recent changes). I'll ARO integration tomorrow, but it should not block this PR.
I was wonder if we can better reflect the fact that it is not only secret, but role and role binding as well.
Let's probably keep it as
AzureCloudProviderSecret
as it consists of resource nameazure-cloud-provider
and resource typesecret
. Resource name is forced on us by cloud provider.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Leave it as one file for each resource. The CVO has (or had) issues with multiple resources in a single manifest when there are problems applying some of the resources.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use
stringData
instead ofdata
. Then you don't need to do the base-64 encoding. The API server will do the base-64 encoding for you.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't know that
stringData
merges intodata
.@staebler I updated the PR to use
stringData
. Note that everything else inpkg/asset/manifests/openshift.go
explicitly encodes into base64. I'm happy to revert back to explicit encoding for consistency, if you wish.