Closed aureq closed 3 weeks ago
roothorp
commented
1 year ago I've raised https://github.com/pulumi/pulumi/issues/11545 with regards to making additionalSecretOutputs work with components, which I think is the best way forward with this. Would this be an acceptable resolution for you @aureq?
justinvp
commented
1 year ago pulumi/pulumi#11545 with regards to making
additionalSecretOutputswork with components
We likely can address this inside EKS w/out waiting on pulumi/pulumi#11545. I'd have to try it out, but we should be able to wrap the kubeconfig as a secret when registering the output as well as when returning it as state from Construct.
aureq
commented
1 year ago @justinvp @roothorp Yes, I think addressing this inside pulumi-eks is probably the better way. For such sensitive information like kubeconfig, clusterCertificateAuthority.data and certificateAuthorities[].data, our users shouldn't have to second guess (like looking into the stack state) what is a secret and what is not.
I think https://github.com/pulumi/pulumi/issues/11545 would partly answer the problem because if a resource is private to the component resource, then additionalSecretOutputs may not be able to reach that property (though may not be the case for pulumi-eks).
pawelprazak
commented
8 months ago I've stumbled upon this issue as well, for the record, this affects multiple places in the schema:
resources eks:index:Cluster properties kubeconfig AND kubeconfigJsonfunctions eks:index:Cluster/getKubeconfig outputs properties resultpawelprazak
commented
8 months ago After looking into this a bit further, the CA data looks non-sensitive/public: https://stackoverflow.com/questions/71444145/should-the-k8s-cluster-certificate-authority-be-kept-secret
Also, the AWS provider does not mark the CA as secret in the schema (and if it were it should propagate through outputs):
"certificateAuthority": {
"$ref": "#/types/aws:eks%2FClusterCertificateAuthority:ClusterCertificateAuthority",
"description": "Attribute block containing `certificate-authority-data` for your cluster. Detailed below.\n"
},IIUC, the secret / token is fetched just-in-time at runtime, using this command:
{
- name: "aws"
- user: {
- exec: {
- apiVersion: "client.authentication.k8s.io/v1beta1"
- args : [
- [0]: "eks"
- [1]: "get-token"
- [2]: "--cluster-name"
- [3]: "my-cluster-eksCluster-1528258"
]
- command : "aws"
- env : [
- [0]: {
- name : "KUBERNETES_EXEC_INFO"
- value: (json) {
- apiVersion: "client.authentication.k8s.io/v1beta1"
}
}
]
}
}If the above is true, then the kubeconfig generated by the current implementation should not contain any secrets.
Looking at the kubeconfig documentation, what looks like secrets are:
client-key/client-key-data - the private part of mTLStoken / tokenFile - bearer token for authenticationpassword - for basic authentication
and I don't see any of then use in the current implementation of the generateKubeconfig function.I hope this gives some important context to this conversation.
flostadler
commented
3 weeks ago @pawelprazak is right here, neither kubeconfig nor the CA data is sensitive so it doesn't need to be stored safely.
aws eks get-token ... via an exec-based plugin.
What happened?
When using this eks provider, I noticed that
cluster.kubeconfigis not set as a secret. This is a problem, because the value is stored in plain text in the stack state file. Unfortunately, the value cannot be protected from the outside of the component usingAdditionalSecretOutputssince it's a component resource.Additionally, the provider should secret
clusterCertificateAuthority.data,certificateAuthorities[].dataas well.I think this is the block of code that would need the change. https://github.com/pulumi/pulumi-eks/blob/master/nodejs/eks/cluster.ts#L522-L525
Steps to reproduce
pulumi stack exportExpected Behavior
Actual Behavior
Output of
pulumi aboutAdditional context
No response
Contributing
Vote on this issue by adding a 👍 reaction. To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).